ADP Slide

Application Development
Practices
TRAN KIM SANH
Instructor of DTU
Email: trankimsanh@duytan.edu.vn
Tel: 0987 409 464
Introduction to Teamwork
© 2019, Tran Kim Sanh

Referenced from Prof.Redley of CMU
Content
 Working Individually
 Working as a Team
 Characteristics of High Performance
Teams?
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 2

Team is build in trust

Working Individually
 When you are the only one working on
a project:
 No need to gain consensus
 No one to coordinate with
 Don’t have to explain the rationale for
your decisions

Working Individually
 When you are the only one working on
a project:
 Your decisions aren’t challenged
 Don’t need to work with people you don’t
get along with
 Don’t need to trust anyone else to get the
work done
 Easier to hide what you are doing

Working as a Team
 You and your teammates will need to
agree
 You will need to coordinate with your
team
 You will need to get along with everyone
on the team
 The team will need to build trust
 Your teammates may give you feedback
on your performance
 You will need to develop processes,
standards and conventions
Team fail

Team fail

Good things of team

Why Work in Teams?
 Today’s projects are too large for
individual developers to accomplish
 Software projects require a diverse set
of skills and roles
 Team with synergy can produce much
more than a group of individuals

Characteristics of High-Performance
Teams
 A clear, elevating goal
 A results-driven structure
 Competent team members
 Unified commitment
Larson and LaFasto, Teamwork

Characteristics of High-Performance
Teams
 Collaborative climate
 Standards of excellence
 Principled leadership
 External support and recognition

Clear, Elevating Goal
 High performance teams:
 Have a clear understanding of the goal they are trying
to achieve
 Believe the goal is significant, elevating or compelling
 Sometimes known as “A sense of mission”

Team goal
 It is critical that the goal
is clear to all and has
specific performance
objectives, so it is easy
for all to know, without
question, whether the
goal has been met
 Personal goals can hinder
team goals

Results Driven Structure
 General characteristics of effective team
structure:
 Clear roles & accountabilities
 Effective communications
 Key information is easily available
 The information is credible
 The team must have opportunities to raise any issues
 Issues raised & decisions made must be documented
 Monitoring individual performance &
providing feedback
 Fact based judgments

Competent Team Members
 Who on the team is critical to team success
 Decisions about who is on the team must be
made in terms of who can best help the team
achieve its goals
 Team member competencies:
 Technical
 Personal
 You want people who are committed to, and
confident in, team success
 “Nice person, wrong job”

Competent Team Members

Personal vs Technical

Unified Commitment
 A sense of dedication and loyalty to
the team
 A sense of excitement and enthusiasm
about the team
 A willingness to sacrifice individual
objectives to help the team accomplish
its goals

Unified Commitment

Collaborative Climate
 A feeling or climate of trust among
and between the team members:
 Honesty
 Openness
 Consistency
 Respect
 Trust is EXTREMELY fragile

Standards of Excellence
 Pressure to achieve a required or expected level
of performance can come from:
 Individual standards
 Team pressure
 Consequences
 External sources
 The team leader
 Standards make a difference

 Standards are hard work
 Individuals need to hold each other accountable
to the team’s standards
Without Standards

Basic standard

External Support & Recognition
 The team is:
 Given the resources it needs to get the job
done
 Supported by those outside of the team who
are capable of aiding team success
 Sufficiently recognized for its
accomplishments
 Perceived as being rewarded and incentivized
appropriately by the team members
 Absence of external support & recognition is
noticed more than its presence
 Rewards are important, but may not lead
directly to team success
Larson and
© 2019, Tran KimLaFasto,
Sanh Teamwork25
Principled Leadership
 A consistent message
 Unleashing talent
 A decision making climate
 Ego suppression
 Leaders create leaders

Group discussion?
 Discuss in groups of 4 students about
the best team that you know
 Time: 10 minutes

Best and Bad

Are You a Problem?
 Covering up ignorance rather than being
open to learning
 Excessive desire for privacy or territory
 Constant grumbling about old discussions
and decisions
 Don’t pitch in to help on team activities
 Bullying behavior
 Sarcastic jokes, insults and teasing
 e-mail wars
 Rudeness, threats and intimidation

Giving and Receiving Feedback
 What is Feedback?
 Communication that lets us know how
effective we are being professionally or
personally with what we are trying to
accomplish or how we are affecting others
It helps us know how others perceive us

Tips for Giving Feedback
 Give positive feedback as close to
the event as possible
 Praise in public, criticize in private
 Praise regularly, however make sure
your praise is sincere
 Make sure the praise fits

Tips for Giving Feedback
 No favorites
 Be positive, sincere and specific
 Catch people doing things right
 Cool down if things have gone poorly

Negative Styles when Giving Feedback
 Attacking: hard hitting and aggressive, focusing
on the weaknesses of the other person.
 Indirect: feedback is vague and issues hinted at
rather than addressed directly.
 Insensitive: little concern for the needs of the
other person.
 Disrespectful: feedback is demeaning, bordering
on insulting.
 Judgmental: feedback is evaluative, judging
personality rather than behavior.
From: http://www.selfhelpmagazine.com/articles/growth/feedback.html

Negative Styles when Giving Feedback
 Attacking: hard hitting and aggressive, focusing
on the weaknesses of the General: aimed at
broad issues which cannot be easily defined.
 Poor timing: given long after the event, or at the
worst possibletime.
 Impulsive: given thoughtlessly, with little regard
for the consequences.
 Selfish: feedback meets the giver's needs, rather
than the needs of the other person.
 How would you react as the receiver if this is how
the speakergives feedback?

Positive Styles when Giving
Feedback
 Supportive: delivered in a non-threatening and
encouraging manner.
 Direct: the focus of the feedback is clearly
stated.
 Sensitive: delivered with sensitivity to the needs
of the other person.
 Considerate: feedback is intended to not insult
or demean.
 Descriptive: focuses on behavior that can be
changed, rather than personality.

Positive vs Negative

Positive Styles when Giving
Feedback
 Specific: feedback is focused on specific
behaviors or events.
 Healthy timing: given as close to the prompting
event as possible and at an opportune time.
 Thoughtful: well considered rather than
impulsive.
 Helpful: feedback is intended to be of value to
the other person.
 How would you react as the receiver if this is
how the speaker gives feedback?

Receiving Feedback
 How do you respond to feedback?
 Some of us don’t respond well unless all
feedback is positive.
 Some of us will react negatively (get angry,
for example)
 Some of us seek out feedback because we
know it helps us grow
 Do you always accept all feedback?
 Only friends will tell you that you have a
problem
 “Enemies” want you to fail, and will be happy
to watch you make mistakes

Tips for Receiving Feedback
 Thank whoever gave you the feedback.
After all, you do want them to continue to
give you feedback in the future, right?
 Consider the feedback
 You don’t need to act on everything
 You may want to prioritize feedback
 You may want to monitor your behavior to
confirm the feedback
 Over time, you may want to let whoever
gave you the feedback know how
valuable it was

Tips for Receiving Feedback

Negative Styles when Receiving
Feedback
 Defensive: defends personal actions, frequently
objects to feedback given.
 Attacking: verbally attacks the feedback giver,
and turns the table.
 Denies: refutes the accuracy or fairness of the
feedback.
 Disrespectful: devalues the speaker, what the
speaker is saying, or the speaker's right to give
feedback.
 Closed: ignores the feedback, listening blankly
without interest.

Negative Styles when Receiving
Feedback
 Inactive listening: makes no attempt to "hear"
or understand the meaning of the feedback.
 Rationalizing: finds explanations for the
feedback that dissolve any personal
responsibility.
 Patronizing: listens, but shows little interest.
 Superficial: listens and agrees, but gives the
impression that the feedback will have little
actual effect.
 How would you react as the speaker if this is
how the receiver reacts?

Positive Styles when Receiving
Feedback
 Open: listens without frequent interruption or
objections.
 Responsive: willing to hear what's being said
without turning thetable.
 Accepting: accepts the feedback, without denial.
 Respectful: recognizes the value of what is being
said and the speaker's right to say it.
 Engaged: interacts appropriately with the
speaker, asking for clarification when needed.

Positive Styles when Receiving
Feedback
 Active listening: listens carefully and tries to
understand the meaning of the feedback.
 Thoughtful: tries to understand the personal
behavior that has led to the feedback.
 Interested: is genuinely interested in getting
feedback.
 Sincere: genuinely wants to make personal
changes if appropriate.
 How would you react as the speaker if this is
how the receiver reacts?

Personal Responsibility

Values
 How do you know what someone’s
values are?
 From their behavior
What does your behavior say about you?

Video link
 https://www.youtube.com/watch?v=xt
_ukyhXBKI
 https://www.youtube.com/watch?v=Jl
6M6G1FjRs

References
 Ian Sommerville. Software engineering
update 10th edition. Wesley Computer
Publishing 2018 Page: 656 - 666
 http://www.differencebetween.net/scie
nce/difference-between-positive-
feedback-and-negative-feedback/

Summary
 Being on a successful team is worth
the effort
 Everyone is a leader, whether you
think you are or not
 What does your behavior say about
you?

03/03/2021
Practices
TRAN KIM SANH
Instructor of DTU
Tel: 0987 409 464
Using Processes
© 2019, Tran Kim Sanh 1
Contents
1. Why Process is Important
2. What is a Process?
3. What Processes Will I Need?
1
03/03/2021
Previous lesson question

 The team is build in…?
 TRUST
 What is “A results-driven structure”

characteristic?
 Roles & Accountabilities
 Communication
 Monitoring individual performance
& providing feedback

 Two ways of team member?
competencies are?
 Technical
 Personal
 Characteristics of good team leader?
 A consistent message
 Unleashing talent
 A decision making climate
 Ego suppression
 Leaders create leaders
2
03/03/2021

 What are team member’s competitions?
A. Technical
B. Personal
C. Salary
D. A and B are correct

 Why do we need to build the teamwork?
A. The software projects are too large and those
a diverse set of skills and roles
B. Experienced programmers who will teach
those less experienced
C. To do inspection
D. To prevent defects
3
03/03/2021
Why Process is Important

 What has the biggest impact on
project success and quality?
 What processes, standards &

conventions will your team need to be
successful?
What is a Process?
 A process is a set of practices
performed to achieve a given purpose;
it may include tools, methods,
materials, and/or people
 While process is often described as a
leg of the process-people-technology
triad, it may also be considered the
“glue” that unifies the other aspects
4
03/03/2021
Why Focus on Process?

 Everyone realizes
the importance of
having a
motivated, quality
work force, but
even our finest
people can’t
perform at their
best when the
process is not
understood or
operating “at its
best”
Example 1
5
03/03/2021
Example 2
 http://vhr.vn/quy-trinh-giao-dich-vinhomes-riverside-hoa-anh-dao.html
Example 3
6
03/03/2021
Process Improvement Premise

 “The quality of a product is largely
determined by the quality of the process
that is used to develop and maintain it.”
- Based on Total Quality Management
principles as taught by Shewhart, Juran,
Deming and Humphrey
How Do We Define a Process?

 Processes do or transform something
 Two Examples in Readings:

 ETVX
 Swim Lane
7
03/03/2021
Process Measures
 You can specify where the process
measurements should be taken
Black & White Box

 Black Box: You can’t see into the process
 White Box: You can see into the process
8
03/03/2021
Entry, Tasks, Validation, eXit
9
03/03/2021
10
03/03/2021
Controls and Constraints
Controls and Constraints

 Controls
 Designed into the process to produce
adesirable outcome. Examples:
 Policies
 Error detection and correction processes
 Constraints
 A limitation to the process (or
environment) that may impact process
effectiveness and/or efficiency. Examples:
 Technical capabilities of team
 Available time or resources
 Transmission speeds
11
03/03/2021
Swim Lane Diagram
Development Processes
 Product requirements
 Top level architecture, technical
approach, and system design
 Component and unit specifications and
design
 Implementing
 Coding
 Unit and integration testing
 Implementing product changes
 Development metrics definition, collection
& analysis
12
03/03/2021
Infrastructure Processes
 Source control
 Configuration management
 Continuous integration
 Change control
 Infrastructure metrics definition,
collection & analysis
 Defect tracking
Project Management Processes

 You’ll also need to consider processes
for:
 Project charter and business case
 Project planning
 Project scheduling
 Project budgeting
 Project and Program metrics definition,
collection and analysis
 Project tracking
 Project reporting
 Project control
13
03/03/2021
Quality Processes
 Quality planning
 Quality assurance (Defect Prevention)
 Quality metrics definition, collection
and analysis
 System testing
 Usability testing
 Performance testing
Quality Processes
 Regression testing
 Inspections
14
03/03/2021
Support Processes
 System packaging and delivery
 User documentation & training
 User support, Product returns
 Problem logging and initial triage
 System upgrades and routine software
maintenance
 Support metrics definition, collection
and analysis
Along with Process ...

 Deliverables (Artifacts): The output of each
process. Some deliverables are for internal use
only, while others are packaged with the product
 Standards: The rules by which a process is
implemented. Standard electrical plug in
countries, for example
 Policies: An order, typically from senior
management, describing expected behavior by
employees
 Roles & Responsibilities: Who is responsible for
what and when
 Measurement definition, collection and analysis
15
03/03/2021
How Much Process Is Right?

 Whatever works for your team!
 Optimal, yet minimal
 More process is not necessarily better
 Each process must be an enabler for
the team
 If it isn’t, change the process until it is
 Each team member must buy in to
each process
 If they don’t, find out why and fix it
How Much Process When?

 Start with:
 Basic Planning
 Change Management
 Quality
 Better:
 Add Continuous Integration
 Best:
 Use methodology pieces that work for you
16
03/03/2021
Tools
 Most of the software development
processes can be automated
 Many of the available software
development tools are free (open
source)
 Make sure that any tools you acquire
integrate well with existing or planned
processes
Methodologies
 The documented collection of policies and
processes used by a development team
or organization to practice software
engineering is called its software
development methodology (SDM) or
system development life cycle (SDLC)
 You can use a defined methodology to
avoid having to define your own
processes
 Traditional
 Agile
17
03/03/2021
Group discussion
 What are the differences from
Waterfall process compare to Scrum
process (4 students – 10 minutes)
Example Change Request Process
18
03/03/2021
Example Process
 Change Request (CR) State Diagram
Summary
 You will need some amount of process
as soon as you are no longer working
alone
 Methodologies can reduce the time
needed to build an agreed upon set of
processes for the team to use
 Change a process if it isn’t working for
your team
19
03/03/2021
Video link
 https://www.youtube.com/watch?v=la
SrDtYtkXU&list=PLCku-
ULHIQvlLC2gFqeoX-JtbEvmeoDhl
 https://www.youtube.com/watch?v=5
A5XCuWMG4o&list=PLCku-
ULHIQvlLC2gFqeoX-
JtbEvmeoDhl&index=2
References
 Ian Sommerville. Software engineering
 https://en.wikipedia.org/wiki/Software
_development_process
20
03/03/2021
Practices
TRAN KIM SANH
Instructor of DTU
Email: trankimsanh@dtu.edu.vn
Tel: 0987 409 464
Defining a Technical Review Process
Contents
1. Types of Technical Reviews
2. What is an Inspection Process?
3. What to Consider When Building Your
Inspection Process
1
03/03/2021
Question
 How do we define a Process?
A. Input - Process – Output
B. Process - Input- Output
C. Output - Input – Process
D. Process - Output – Input
 The best period of time for one
Sprint Backlogs in Scrum process is?
A. 2->4 weeks
B. 3->5 weeks
C. one week
D. one month
Question
 It is better to use process in a (an)…
A. Individual
B. Small team
C. Large Team
D. Other solution
 What are the fundamentals of Software
Development Process?
A. The requirement, Analysis, Code
B. User documentation, User supports
C. Review, Testing...
D. All above
2
03/03/2021
Question
 The process you can see insight is…
A. White Box
B. Black Box
C. A and B are correct
D. A and B are not correct
 What is the correct stage order?
A. Task, Entry, Validation, Exit
B. Entry, Validation, Task, Exit
C. Exit, Validation, Task, Entry
D. Entry, Task, Validation, Exit
Types of Technical Reviews

 Walkthroughs
 Code Reading
 Pair Programming
 Inspections
3
03/03/2021
Walkthroughs
 Informal (any meeting where developers
review work to improve its quality)
Pair Programming
 Reviews are built in
4
03/03/2021
Code Reading
 More formal, but only applies to code
 Reviewers read code and provide feedback
Inspections
 Very formal
 Specific roles
 Checklists, Inspection Report, etc.
5
03/03/2021
What is An Inspection Process?

 Multiple names: software inspection, code
inspection, Fagan inspection.
 “…a formal evaluation technique in which
software requirements, design, or code are
examined in detail by a person or group other
than the author to detect faults, violations of the
development standards, and other problems…”
 To detect and identify software element
defects early
 Correcting defects early has a direct impact
on quality
 ANSI/IEEE Std. 729-1983 Standard Glossary of
Software Engineering
Process Steps
 For Inspection:
6
03/03/2021
Who Is Involved
 For Inspection:
 Roles:
 Author
 Moderator
 Inspector (reviewer)
 Recorder
 Reader / Timekeeper
 When:
 Before the inspection meeting
 During the inspection meeting
 After the inspection meeting
Inspections Differ From Reviews

 Inspection checklists focus the reviewers
attention on areas that have been problems in
the past
 Inspections focus on defect detection, and not
correction
 Reviewers prepare for the inspection meeting
beforehand and arrive with a list of the problems
that they’ve discovered
 Distinct roles are assigned to all participants
 The inspection moderator isn’t the author of the
work product under inspection
7
03/03/2021
Inspections Differ From Reviews

 The inspection moderator has received specific
training in moderating inspections
 The inspection meeting is only held if all
participants have adequately prepared
 Data is collected during each inspection meeting
and is fed into future inspections
 General management doesn’t attend inspection
meetings unless the artifact being inspected is a
plan or other management material
What to Consider ...

1. What are the goals of your process?
2. How will you know if it is valuable?
3. What steps will your process require?
4. Who will need to be involved?
5. What is the process timing?
6. What are the process inputs and
outputs?
7. What will prevent your process from
being successful?
8
03/03/2021
Process Goals
 What benefits will the process bring?
 For an Inspection Process:
 Defects removed
 Team cross-training
 Others ...
Process Value
 Cost versus Benefit Analysis
 For an Inspection Process:
 Benefit:
 $ Saved from defects removed early
 Value of team cross-training
 Others ...
 Cost:
 Time and $ (overhead) of process
 Others ...
 Be sure to define the metrics needed
to validate process value
9
03/03/2021
Process Timing
 What is the task sequence?
 Are there any task
dependencies?
 Can there be parallel
tasks?
 Are there any special
timing issues associated
with the process?
Process Inputs and Outputs

 Example inspection process input:
 Artifact being inspected
 Standard(s) against which the artifact is
being judged
 Example inspection process output:
 Defect list
 There are more ...
10
03/03/2021
Group discussion?
 Create a checklist for java code
 Find a review report on internet
 (4 students – 10 minutes)
Process Inputs and Outputs

 Checklist
 Defect list
11
03/03/2021
Barriers to Inspection Process Success

 Culture Clash
 You define a great process, that doesn’t mean
that software engineers will follow it
 The role players and the process may need to
be flexible if the process isn’t working well
 Lack of Management Support
 Managers must demonstrate that they value
inspections
 Managers must respond positively and quickly
to issues found in inspections
 They are perceived as taking too much
time and effort

 Defect Data Used Inappropriately
 Use inspection data to measure effectiveness,
improve inspections, and measure ROI
 Don’t use inspection data for performance
reviews
 Poor Timing
 Avoid scheduling inspections during crunch
mode
 Lack of Training
 Lack of a Champion
 A champion raises the awareness and sells
inspections
12
03/03/2021

 Lack of Automation
 Use tools to help data collection
 First Impressions do matter
 Don’t half-heartedly do an inspection
 Don’t become over zealous with inspections
 Inspection Meetings are used for problem
solving or other discussions
 Should just be for problem identification
 Participants exhibit unprofessional behavior
when giving or receiving feedback
Process Variation
 Formal Inspections versus Less Formal
Walkthroughs
 Both have strengths and weaknesses
 Don’t blindly adhere to a process
 Be flexible, try new things
 Use data, and the team, to guide you in
knowing if your process is working
13
03/03/2021
Summary
 Formal inspections are a specific type
of technical review
 Technical reviews have been shown to
be extremely effective in detecting
defects, and economical compared to
finding the defects later in the life
cycle
 Be sure to consider the issue
associated with deploying more or less
formal processes
Video link
 https://www.youtube.com/watch?v=y
KBfRzhIofs
 https://www.youtube.com/watch?v=
nNkTJgasN_Y
14
03/03/2021
References
 Ian Sommerville. Software
engineering update 10th edition.
Wesley Computer Publishing 2018 pp.
515- 530 verification and validation
 https://en.wikipedia.org/wiki/Softwar
e_review
 https://en.wikipedia.org/wiki/Softwar
e_inspection
15
03/03/2021
Practices
TRAN KIM SANH
Instructor of DTU
Tel: 0987 409 464
Reviewing the Review Process
Contents
1. Why Do Technical Reviews?
2. Benefits of Technical Reviews
3. Technical Review Costs
4. Addressing Hurt Feelings
5. What Data Should We Collect?
6. Why Don’t More Software Teams use
7. Technical Reviews?
1
03/03/2021
Question
 All studies of Inspection have
common results, the meeting will
find very few errors compared to the
reading code. Why are many
companies still inspecting the code
by meeting?
A. They use inspection for training
B. Inspection can find the defect that the
individual couldn’t found
C. Meetings create a schedule that people
must work towards
D. All above
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh
2
Question
 What is the maximum time to peer
code review?
A. 30 minutes
B. 60 minutes
C. 90 minutes
D. 120 minutes
 What is the most successful type of
Object Oriented's review?
A. Checklist review
B. Systematic review
C. Use-case review
D. No solution is true
2
2
03/03/2021
Why Do Technical Reviews?

 Software Development Goal:
 To Remove Software Defects at a Reduced
Cost
 Technical Reviews remove defects
early in the Life Cycle, and it is always
cheaper to remove defects earlier than
later
 Note that Technical Reviews help remove
defects, and prevent future defects
Cost to fix a bug
3
03/03/2021
Technical Review Theory

 Software Defect Removal Without
Reviews
Technical Review Theory

 Software Defect Removal With Reviews
4
03/03/2021
Technical Review Benefits

 Early removal of defects
 Teams find faults that no individual reviewer
would be able to find
 Less experienced developers and reviewers learn
from their more experienced peers
 Meetings create a schedule that people must
work towards
 Personal incentive to contribute & improve
 Significant knowledge sharing
Ex. 1
 Three-month, 10KLOC project with 10
developers. How much $ would the
company have saved if they had used
technical reviews?
 The result:
 Code review would have saved half the cost
of fixing the bugs
 Plus they would have found 162 additional
bugs
Jason Cohen. Best Kept Secrets of Peer Code Reviews
5
03/03/2021
Ex. 2 - Before
 Before Code Reviews
Ex. 2 - After
 After Code Reviews
6
03/03/2021
Benefits from Other Studies

 Design & Code Inspections usually
remove 70 – 85% of product defects
 Capers Jones. Software Defect Removal
Efficiency, IEEE Computer. April 1996
 Inspections increase productivity ~
20%
 Multiple citings
Technical Review Costs

 ~ 10-15% of project budget
 If designs and code are inspected
 Vary Widely Depending on review type
 Effort associated with preparing, doing and
documenting the review
 Cost of training
 Cost of tools
 Hurt Feelings
 Any criticism is an opportunity both for
growth and for embarrassment
 Criticism can feel like a personal attack
 Will review data affect annual reviews?
7
03/03/2021
Addressing Hurt Feelings

 Be consistent in pointing out that:
 Finding defects is good, not evil
 Defect density is not correlated with
developer ability
 We want to find defects so we can honestly
evaluate our own behavior and productivity
 Reviewers are doing a good job if they find
lots of defects
 Defect density will never be used for
performance evaluations
 Negative attitudes will not be tolerated
What Review Data Should We

Collect?
 Depends on what our goals are
 Goal: Cost to find defects using reviews
 # defects found
 Effort (hours) to find each defect
 Other review costs
 Goal: # defects found by reviews that unit
test won’t find (should we do unit test &
reviews?)
 # defects found
 For each defect found, indicator as to
whether it would be found by unit test
(author’s assessment)
8
03/03/2021
What is a Defect?
 When a reviewer or consensus of
reviewers determines that code must be
changed before it is acceptable, it is a
“defect”
 If the algorithm is wrong, it’s a defect
 If the code is right but unintelligible due to
poor documentation, it’s a defect
 If the code is right but there’s a better way to
do it, it’s a defect
 For the purposes of reviews:
 A defect is an improvement to the code that
would not have occurred without review
Group discussion
 Compare defect, error, bug
 (2 students – 5 minutes)
9
03/03/2021
Why Are Technical Reviews Not

More Widely Used?
 Significant data supporting the
effectiveness of technical reviews (for
the past 30 years), so why aren’t
technical reviews more widely used?

More Widely Used?
 Perception that there is just one way
to do reviews (inspections), and that
they are not easy to do
 Multiple types of reviews
 Viewed as an added cost
 True, but if done correctly they will save $
 Viewed as taking too long
 True, but if done correctly they will save
time
Ron Radice. Software Inspections. Methods & Tools. Summer, 2002
10
03/03/2021

More Widely Used?
 Not needed with modern languages and
development techniques
 Modern developers still create defects
 “Tried it and it doesn’t work”
 Don’t confuse a good idea with a poor
implementation
 The process is often not well implemented or
is changed without supporting data
 Developers don’t like to do them
 They can become tedious, but they can also
be fun

More Widely Used?
 Our developers are very good
 Even very good developers create defects
 Most developers want to learn from their
mistakes
 Developers don’t take the feedback well
 Most developers want to learn from their
mistakes
 Unit testing is just as effective
 Unit testing doesn’t catch everything
 Unit testing can give a false sense of quality
11
03/03/2021

More Widely Used?
 They are a competitive advantage!
 No one wants to give away the secret of how
to release fewer defects efficiently
Jason Cohen. Best Kept Secrets of Peer Code Reviews
Summary
 If implemented properly, reviews are a proven
method for:
 Significantly reducing the number of delivered bugs
 Keeping code maintainable
 Getting new hires productive quickly and safely
 Methods and tools can be misapplied, treated as a
failure, and then dismissed as a bad experience by
users who were not enabled for success
 Quality techniques such as reviews and testing are
not mutually exclusive
 Cost, benefit and category data must be collected to
verify and improve your review process!
12
03/03/2021
Video link
 https://www.youtube.com/watch?v=F
TN_93Px-Qc
 https://www.youtube.com/watch?v=5
KB5KAak6tM
References
 Capers Jones. Software Defect Removal
Efficiency, IEEE Computer.
 Jason Cohen, Steven Teleki, Eric Brown. Best
Kept Secrets of Peer Code Review
13
03/03/2021
Agenda
 Insights from Studies
Practices
TRAN KIM SANH
Instructor of DTU
Tel: 0987 409 464
Technical Review of Code
© 2019, Tran Kim Sanh 1 Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 2
1
03/03/2021
Contents: Insights from Studies Question

1. Individual vs Group Meeting Reviews  What are the types of technical review?
2. Reviews vs Testing A. Walkthroughs, Code Reading, Pair Programming,

Inspections
3. Are OO Reviews Different?
B. Code Reading, Pair Programming, Inspections
4. Is There an Optimal Review C. Walkthroughs, Code Reading, Pair Programming,
Duration? Inspections, Customer Review
5. What Causes us to Find More or Less D. Code Reading, Pair Programming
Defects During a Review?
6. Data from Code Reviews at Cisco
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 3 Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 4
2
03/03/2021
Question Question
 What is the name of inspection  What is Pair Programming?
process? A. A teamwork using Cisco tool to review code
A. Software inspection B. Two coders read and inspection code of each
B. Code inspection other
C. Fagan inspection C. A meeting of project's stakeholder
D. All above D. All above
 What is the result of the review?  Who are involved in the inspection
A. Checklist meeting?
B. Inspection Report. A. Author, Inspector
C. Code Defect B. Moderator, Recorder
D. All above C. Reader / Timekeeper
D. All above
3
03/03/2021
Question Question
 According to Capers Jones in  All studies of Inspection have common
“Software Defect Removal Efficiency, results, the meeting will find very few
Design and Code Inspections” errors compared to the reading code. Why
are many companies still inspecting the
usually remove ... of product defects
code by meeting?
A. 40% A. They use inspection for training
B. 50 - 60% B. Inspection can find the defect that the
C. 60 - 70% individual couldn’t found
D. 70 - 85% C. Meetings create a schedule that people must
work towards
D. All above
4
03/03/2021
Individual vs Group Reviews Votta

 Are review meetings really better than individuals  Inspection meetings contribute only an
at detecting defects? additional 4% to the number of defects
 Three studies: already found by private code-readings
 (Design Reviews) Lawrence G. Votta, Jr., Does
every inspection need a meeting?, Proceedings
of the 1st ACM SIGSOFT symposium on
Foundations of Software Engineering
 (Code Reviews) Diane Kelly and Terry Shepard
(2003) at the Royal Military College of Canada
 (Architecture Reviews) Joint effort led by
Reidar Conradi between Ericsson Norway and
two Norwegian colleges, NTNU and Agder
University (2003)
5
03/03/2021
Kelly & Shepard Kelly & Shepard

 Set up an experiment comparing reviewers in  Not only did the
isolation versus group meetings meeting phases not
 Groups of developers read code individually
contribute significantly
to detect as many defects as possible
to overall defect
 Then each group got together in an
inspection meeting
counts, the
contribution was
 Results:
generally of a surface
 In total, 147 defects were found during the
reading phases. Of these, 39 (26%) were level nature rather
discarded during meetings than logic-level or
 The meeting phases added only 20 new algorithmic-level
defects to the existing 147. Furthermore, of
those 20, two-thirds were relatively trivial in
nature
6
03/03/2021
Conradi Individual vs Group Reviews Analysis

 In 38 experimentally-controlled inspections they  In addition to the # of defects found by
found that: your review process, consider the time
 25% of the time was spent reading
consumed
 75% of the time in meetings
 Votta found that inspection meetings
 yet 80% of the defects were found during
contribute only an additional 4% to the
reading!
number of defects already found by
 They were 12 times more efficient at finding private code-readings
defects by reading than by meeting
 Kelly found that about 2/3 of total person-
 They had 5-7 people in each meeting – several hours were spent in reading and 1/3 in
more than Kelly or Votta or even Fagan meetings, a discovery rate of 1.7 defects
recommends – so the number of defects found per hour for reading and 1.2 for meetings.
per man-hour was vanishingly small
Reading is 50% more efficient in finding
defects than are meetings
7
03/03/2021
Individual vs Group Reviews Analysis Reviews vs Testing

 In addition to the # of defects found by  Are reviews just duplicating what test will
your review process, consider the time catch anyway?
consumed  Study:
 …
 • HP (1988)
 Conradi found that they were 12 times
more efficient at finding defects by
reading than by meeting
 Are there some types of defects that are
better found in meetings?
8
03/03/2021
HP Study Are OO Reviews Different?

 This pilot study involved a single project with 30  Given that object-oriented (OO) code has
development hours and 20 review hours – 13 different structural and execution
hours in pre-meeting inspection and 7 hours in
patterns than procedural code, what
meetings
review types work best?
 They collected enough information on each defect
 Study done by Dunsmore, A., Roper, M.,
to determine “Is there any test that QA could
have reasonably performed that would have
Wood, M. Object-Oriented Inspection in
uncovered this defect?” the Face of Delocalisation, Proceedings of
 Only 4 of the 21 defects could conceivably
the 22nd International Conference on
been caught during a test/QA phase Software Engineering (ICSE) 2000, pp.
 They further postulate that it would have
467-476, June 2000
taken more total engineering hours to find and
fix those 4 in QA rather than in inspection
9
03/03/2021
Are OO Reviews Different? Are OO Reviews Different?

 Given that object-oriented (OO) code has  Three types of reviews used:
different structural and execution  The “checklist review” gives the reviewers
patterns than procedural code, what a specific list of things to check for at the
review types work best? class, method, and class- hierarchy levels
 The “systematic review” gives the
reviewers a a reading plan that directed
their attention to the code in a certain
order and supplied additional information
according to a systematic set of rules
 The “use-case review” gives the reviewers
a set of ways in which we expect the code
to be used by other code in the system.
10
03/03/2021
OO Review Results Optimal Review Duration?

 The checklist method was most  During the 3rd experiment in the OO
successful Study the exact time that each of the
 The defects found in each of the three defects were found during the inspection
techniques didn’t overlap completely was logged
 Are most defects found quickly?
 Is there a drop-off point after which
defects are no longer found?
 Is there a difference between the three
types of review?
Inspection time is in minutes. Defect rate is in defects per hour
11
03/03/2021
What Causes us to Find More or

Optimal Review Duration? Less defects During a Review?
 Defect rate is constant for 1 hour, then  Causal model for the two largest
levels off factors that determine the number of
 No defects found after 90 mins defects found during review
 Arrows indicate a causal link
 The “E” values represent external
factors not accounted for by the
model
12
03/03/2021
What Causes us to Find More or Less defects

During a Review? Implications
 Reading time is twice as influential as  If you want to find more defects, spend
code size more time reviewing
 “External factors” are more important  You could reduce the amount of code under
than other factors inspection, but that’s less important
 Even though various external factors are
collectively more influential, the individual
reviewer often cannot control those factors;
reading time is something that can be
controlled directly
Numbers represent  You can’t average all your metrics and say
% of total influence “We should find X defects per 1000 lines of
code”
13
03/03/2021
Code Collaborator Code Review Process at Cisco

 10-month case study of peer code review  Authors invite 1 or more reviewers
in the Cisco MeetingPlace product  Defects are logged like comments
 2500 reviews of 3.2 million LOC written  Author fixes defects and posts fixes
by 50 developers
 Once all reviewers agree no defects are
 Used “lightweight” code review process still open, the review is complete and the
 No peer review meetings author can check in their changes
 Individual reviews using Smart Bear
Software’s Code Collaborator system for
 Tool automatically tracks metrics
tool-assisted peer review
 Every code change was reviewed before
it was checked in to source control library
14
03/03/2021
Code Review Process at Cisco Cisco Reviews - Results

 Code Collaborator screenshot  Review average = 32 defects per KLOC
15
03/03/2021
Cisco Reviews - Results Cisco Reviews - Results

 LOC under review should be under 200, not to  Total review time should be between
exceed 400
60 and 90 minutes
 More LOC overwhelms reviewers and
defects are not uncovered  Expect defect rates around 15 per
 Reviewing < 300 LOC/hour result in best defect hour.
detection  Can be higher only with less than 175 LOC
 Expect to miss significant % of defects if under review
> 400 LOC /hr
 Authors who prepare the review with
annotations and explanations have far fewer
defects than those that do not
 Probably because authors are forced to
self- review their code Jason Cohen. Best Kept Secrets of Peer Code Reviews
16
03/03/2021
Summary Group discussion

 Any review will find defects. The question is, What are the functions of Cisco Collaborate
how do we optimize our time spent in finding
(4 students – 10 minutes)
defects?
 Take the time to understand the review process
for the artifacts you are reviewing
 Keep your reviews to 60 minutes
 If you want to find more defects, spend more
time reviewing
 Inspection meetings need not be in person
 Be wary of “average defect rates”
17
03/03/2021
Video link References

https://www.youtube.com/watch?v=qMusrHLNfUU  Dunsmore, A., Roper, M., Wood, M. Object-
Oriented Inspection in the Face of
Delocalisation, Proceedings of the 22nd
International Conference on Software
Engineering (ICSE) 2000, pp. 467-476, June
2000
 Diane Kelly and Terry Shepard. Code Reviews
at the Royal Military College of Canada (2003)
 Joint effort led by Reidar Conradi. Architecture
Reviews, between Ericsson Norway, NTNU and
Agder University (2003)
24
18
03/03/2021
References
 https://smartbear.com/product/collaborato
r/overview/

24
19
03/03/2021
Contents
Application Development  What is Configuration Management?
Practices  Why use Configuration Management?

 Where does Configuration
TRAN KIM SANH
Instructor of DTU Management fit?
Email: trankimsanh@dtu.edu.vn  How does Configuration Management
Tel: 0987 409 464
work?
Defining a Configuration  Terminology
Management Process
1
03/03/2021
What is Configuration Management? Why Use SCM?

 Configuration Management (CM) is the  Consider this scenario:
process of controlling and documenting  Software Engineer1 opens foo.cpp
change to a continually evolving  Software Engineer2 opens foo.cpp
Software Engineer1 makes a change to foo.cpp
system 
 Software Engineer2 makes a change to foo.cpp
 It is part of change management  Software Engineer1 saves foo.cpp
 Software Configuration Management  Software Engineer2 saves foo.cpp, wiping out
Software Engineer1’s changes
(SCM) is Configuration Management
specifically designed to meet the  Or this one:
A serious defect is reported for a previous
needs of software development and 
release of our product. How do we fix that
maintenance projects defect only and generate a new release?
2
03/03/2021
Where Does SCM Fit? Why Use SCM?

 So we will always know:
New Development Change Requests  Where all revisions of all files necessary to
create any product version can be found
 Which source files revisions were used in
each build
Change Control
 What changed in each revision of our
source files, and why
Approved
Changes  How to recreate previous product releases
 How to work as a team to make changes
SCM (defects and/or new features) in future
Repository
builds and releases
3
03/03/2021
Why Use SCM? What Goes Under SCM Control?

 So it is easy for developers to make changes,  Everything!
test their changes and integrate the results into
 Product source code
the product
 Scripts to build source code
 So developers don’t waste a lot of time tracking
 Tools used to build product
down bugs in other people’s code that prevent
them from testing  3rd party products used to create product
 Data files
 So the QA team has a stable product to work
with
 So the project team can easily release updated
versions of their product in a repeatable manner
 If done right, significantly reduces Development
& Test time
4
03/03/2021
What Goes Under SCM Control? How Does SCM Work?

 Everything!  Generic Model Master SCM Repository
 Scripts to build or populate database
 Specifications
 User documentation
foo.cpp
 Test scripts
 Plans
 Etc. •Checks out foo.cpp
•Makes change to foo.cpp
•Builds product on local laptop
Software •Tests product change on local laptop
Engineer1 •Rebuilds & retests product using
latest source code
•Checks in updated foo.cpp
5
03/03/2021
How Does SCM Work? How Does SCM Work?

 Generic Model  Generic Model
Master SCM Repository Master SCM Repository
• Checks out foo.cpp Software

• Makes change to foo.cpp
Software Engineer2
• Builds product on local laptop Engineer2
• Tests product change on local laptop
•Checks out foo.cpp
foo.cpp
• Checks in updated foo.cpp foo.cpp •Makes change to foo.cpp
•Builds product on local
laptop
•Tests product change on
local laptop
•Checks in updated If Software Engineer2 checks out
Software foo.cpp Software
Engineer1 • Checks out foo.cpp Engineer1 foo.cpp when Software Engineer1 has it
•
•
Makes change to foo.cpp
Builds product on local laptop
checked out, then the SCM system will
Software
•
•
Tests product change on local laptop
Checks in updated foo.cpp
automatically merge the files when
Engineer3 they are checked in
6
03/03/2021
How Does SCM Work? Terminology

 Generic Model  Source File
 Any file required to build the product on a
Master SCM Repository clean machine. Includes build scripts,
DDLs, install scripts, tests, etc.
 Product Build
source files  Classic definition: Source files compiled
and linked into an executable file
 Modern definition: Putting everything
At any time the software product can be associated with a product together in a
Software built from the source files for testing
Engineer1 usable format
7
03/03/2021
Terminology (cont) Revision Control

 Product Release  Changes to source files must be captured
 Providing software files to others for use. using a revision control system so the
Typically this is a build that passed tests team always knows what changed, and
and is considered ‘good’ can revert to previous source file
 Revision revisions if necessary
 A instance of a source file that contains  Example:
specific changes  Source File foo.cpp
 Revision 1.0 (First time checked in)
 Version
 Revision 1.1 (Bug fixed)
 A unique identifier given to a Release,
 Revision 1.2 (Another bug fixed)
typically associated with all source file
 Revision 1.3 (Yet another bug fixed)
revisions that a build is comprised of
8
03/03/2021
Builds Build tools

 When your product is created from all
of the source code in your repository
the product is called a “build”
 Builds are usually given to a QA team
for system testing
 If QA finds defects that must be fixed,
then those defects are fixed and a new
build created for system testing
 If the build passes QA, then that build
becomes a release and made available to
users/customers
9
03/03/2021
Builds and Automation Unique Release Numbering

 Automate the creation of your builds  Each Build/Release must have a unique ID
 Use tools like Make or Ant, along with  Required for developers to determine which
scripts build (& source files) a problem is occurring in
 Embed the build number in your product  Should be meaningful. I.e., XX.YY.ZZZZ,
 Ensure your builds are reproducible. where:
That is, if you provide a build number, the  XX is the Major Release Number
system knows which source file revisions  YY is the Minor (Maintenance) Release
to include in the build Number

 ZZZZ is the Build Number
 Automate the packaging of your
 Example: 1.01.0012
product, For example:  Would be the 12th build of release 1.01
 Creating releases for different platforms
 Populating a master CD
10
03/03/2021
Version Number Database Version Numbering

 If your product has a database you’ll need
to establish a mechanism that ties
database versions to product versions
• Product Version Runs with Database Version

• 1.01.0312 1.0, 1.1, 1.2
• 1.03.0229 1.3, 1.4
• 2.00.0332 1.5
 When your product starts up it checks to

make sure that it is running against a
supported database version
11
03/03/2021
Notification and Logs Continuous Integration

 Build process logs every activity of  Build everything from scratch regularly
every step while it is executing to a log  Constantly (if anything has changed)
file  Based on timer (developers have to get code
in by a certain time)
 Anyone must be able to determine the
 At least nightly
state of any build by inspecting the build’s
log file  If successful, execute test suite
 Automated tests are kept in SCM system too
 Email notifications
 Automatically sent to all developers that  If all steps complete ok you have a
had new code checked in with that build successful build
 Summarizes the status of the build  Label the source files with the build number
(good/bad)  Update logs and send notifications
12
03/03/2021
Group discussion Test Automation

 Discuss in groups of 4 students,  Ability for anyone to be able to run a suite of
unit and/or system tests against the product at
comparing advantage/disadvantage of
any time using simple commands
the following tools(10 minutes):
 Automated system tests are not intended to be
exhaustive or replace system testing. The intent
is to have a fast, repeatable process for ensuring
that:
 Time spent adding new unit and/or system tests
results in significantly shorter test cycles when
trying to release the product
13
03/03/2021
Build & Release Data Collection Rules for Making Code Changes
 Build Log Data  Developers are responsible for:
 Build & Release Process  Keeping their machine in synch with the
 # of builds configuration management system
 Changes (by CR#) in each build  Creating/updating automated unit tests
 Creating/updating automated unit and
 System Test Process
integration tests
 # of product release cycles required to
approve product is ready to ship  Ensuring that all tests run successfully
 Elapsed time of each product release cycle before checking code back into master
 # of defects found during System Test per repository
release cycle  Resolving conflicts when checking code
 Effort required to test each product release back in
 Updating change documentation
14
03/03/2021
Summary Video link

 Software Development Teams MUST HAVE  https://www.youtube.com/watch?v=ce
a Software Configuration Management 73O3pkgbU
system
 Implement Continuous Integration
• Once you have you’ll wonder how you ever got
along without it!
15
03/03/2021
Homework Assigment Homework Assigment

 Software configuration management  Required:
is a project function to increase the  Install SVN Server
efficiency of technical and  Grant Authorization
Create A project in Eclipse or Netbean
managerial activities by developing 
 Checkin your project to SVN server
a configuration team for the whole  Using Tortoise SVN for checkin and
organization or for each individual checkout a document file to SVN
project.
16
03/03/2021
References
 Ian Sommerville. Software engineering
 https://en.wikipedia.org/wiki/Software_c
onfiguration_management
 https://en.wikipedia.org/wiki/Apache_Su
bversion

17
03/03/2021
Contents
Application Development  Java Development Tools:
 Eclipse
Practices  SVN
TRAN KIM SANH  Ant
Instructor of DTU  JUnit
Email: trankimsanh@dtu.edu.vn  CruiseControl (not used in this course)
Tel: 0987 409 464
Using Your Configuration

Management Processes Part 1
1
03/03/2021
Question Question
 The version of the software is  For Eclipse to work with SVN, which tool
1.01.0012. The number 0012 must you add to Eclipse?
A. subversive
means…. ?
B. Ant
A. the Major Release Number C. Maker
B. the Minor (Maintenance) Release D. SVN client
Number
C. the Build Number
D. the revision
2
03/03/2021
How the Tools Work Together How the Tools Work Together
 Eclipse is an interactive development  Ant is a program that automatically builds
environment (IDE) used by your Java project from source files in your
programmers to edit and debug source SVN repository and creates the project
code, initiate build and test processes distribution packages
and display results
 SVN is a software configuration
management system that stores
(keeps revisions of) your project’s
source files as they are updated by
programmers using the Eclipse (or
another) IDE
3
03/03/2021
Eclipse Simple Demo Program

 Eclipse is the most popular open  Tells us how much money is in our account
source development environment for  1 class (account)
 3 Fields
the Java programming language
 Account Number
 www.Eclipse .org
 Balance Account
 Use Eclipse to write, compile and  Name Account Number
debug your source code  4 Methods Balance
Name
 Prerequisite: You must have a current  Get Account Number
Get Account Number()
version of the Java Development Kit  Set Balance
Set Balance()
(JDK) installed on your PC or laptop  Get Balance Get Balance()
 java.sun.com/javase/downloads/index.jsp  Get Name Get Name()
 1 test case
4
03/03/2021
Eclipse – Demo Project Eclipse – Account Class
5
03/03/2021
SVN SVN Working Copy

 Subversion is used to maintain current and  Your working copy is your own private work
historical versions of source code, web area containing a collection of files
pages, documentation and other files  You can edit these files however you wish,
 subversion.tigris.org and if they're source code files, you can

compile them
 SVN integrates with Eclipse through a plug-
 You can have multiple working copies of
in called “subclipse”
the same project
 Populate your working copy with
 checkout: will populate your working copy
with latest code in repository
 update: will populate your working copy
with latest code in repository, but won’t
overwrite your local changes
6
03/03/2021
Eclipse – SVN checkout SVN Working Cycle

 Checkout  Checkout of files from repository into
working copy
 Local edit of file
 Local unit and integration testing
 Update (to get changed files from repository)
 Local unit and integration testing
 Commit file back to repository
 Commit will update the repository with
your changes
7
03/03/2021
Eclipse – SVN update / commit SVN Tree Structure

 Checkin
8
03/03/2021
Building Your Java Product Ant

 Simple Java products  Ant is an open source build tool that is the
 Simply compile source files standard for building, packaging and
 Complex Java-based projects installing Java applications
 Retrieve up-to-date source files from  Ant uses XML based build files (which makes
source control them much easier to read and modify than
 Manage dependencies not automatically “make” files)
handled by the Java compiler  Ant integrates with most Java IDEs
 Clean target folders  Is part of the standard Eclipse download
 Bundle classes and deliver to appropriate  ant.apache.org/
locations (as JAR/WAR files)
 Do you really want to do this manually?
9
03/03/2021
Ant Inside Eclipse Build Your Java Product with Make

 Make used to be the standard, but ...
 Makefiles have their own language syntax,
requiring highly trained authors
 Make lacks platform-independence,
requiring multiple versions of the same
makefile (one for each target platform) to
be maintained and distributed
 The time and maintenance required to use
Make is too high for complex Java-based
projects
10
03/03/2021
Group discussion Summary - 1

 Find 3 revision management tools  Build, compile and debug software
 Eclipse
 Find 3 website support revision
management  Build, compile and debug software where
source code is stored in a shared repository
 (4 students – 10 minutes)  Eclipse
 SVN
 Build, compile and debug software where

source code is stored in a shared repository
and builds are automated
 Eclipse
 SVN
 Ant
11
03/03/2021
Summary - 2 Video link

 Different tools for different environments  https://www.youtube.com/watch?v=5ul6VZ7mP
and development languages 10&list=PLnSIu0V9A1pVqs4IwKJ09jWgR7gxoqm
 Eclipse (NetBeans, ...)
fx
 https://www.youtube.com/watch?v=wu7p-
 SVN (CVS, ...)
wqy2D0&list=PLnSIu0V9A1pVqs4IwKJ09jWgR7g
 Ant (Make, NAnt, Maven, Phing, Rake, ...) xoqmfx&index=5
 Take advantage of the many good open
source tools to increase:
 Your productivity
 The quality of your code
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 20 Referenced from Prof.Redley of CMU
12
03/03/2021
References
 https://subversion.apache.org/docs/
13
03/03/2021
Practices
TRAN KIM SANH
Instructor of DTU
Tel: 0987 409 464
Using Your Configuration Management

Processes Part 2
Contents
 Overview of Java Development Tools
Used in this Course
 eclipse
 svn
 Ant
 CruiseControl (not used in this course)
 JUnit
 What is testing?
 What is Junit?
 How to write testcase?
 What are Junit methods?
 How to use Junit in Eclipse?
1
03/03/2021
Question
 ANT is used to …. ?
A. Build Project
B. Manage the revision of the project
C. Share document and code
D. Review code
Question
 In order to use Eclipse, you must …. ?
A. install the current version of Java
Development Kit on your computer
B. install the current version of Tomcat on your
computer
C. install the current version of SVN on your
computer
D. install the current version of ANT on your
computer
2
03/03/2021
Software Testing
 Software testing is the process of
evaluation a software item to detect
differences between given input and
expected output
 Types
 Unit testing
 Integration testing
 Regression Testing
 System testing
 Acceptance testing
Testing with JUnit

 Junit is a unit test environment for
Java programs developed by Erich
Gamma and Kent Beck.
 Writing test cases
 Executing test cases
 Pass/fail? (expected result = obtained
result?)
3
03/03/2021
Testing with JUnit

 Consists in a framework providing all
the tools for testing.
 framework: set of classes and conventions to
use them.
 It is integrated into Eclipse through
a graphical plug-in.
Design Test Cases

 A test case in software engineering is a set of
conditions or variables under which a tester will
determine whether an application or software
system is working correctly or not.
4
03/03/2021
Assert methods
 assertEquals(Object expected, Object
actual)
 Test that float or double values match. The
tolerance is the number of decimals which
must be the same.
 assertNull([message], object)
 Checks that the object is null.
Assert methods
 assertTrue(Boolean test)
 Will always be true / false. Can be used to
predefine a test result, if the test is not yet
implemented.
 fail([String message])
 Let the method fail. Might be used to check
that a certain part of the code is not reached.
Or to have failing test before the test code is
implemented.
5
03/03/2021
Junit in Eclipse - Setup
 In Eclipse
 Create a new project
 Open project’s property
window (File -> Properties)
 Select: Java build path
 Select: libraries
 Add Library
 Select Junit
 Select the type 3.x or 4.x…
JUnit in Eclipse
 To create a test
class, select File
New Other... 
Java, JUnit,
TestCase and enter
the name of the
class you will test
Fill this in
This will be filled

in automatically
6
03/03/2021
Eclipse - Test Case

Results
Your results are here
7
03/03/2021
Group discussion?
 How to write unit test for the codes below - 4
students – 10 minutes
public class Sort {
int number1;
int number2;
public void sortDesc()
{
if(number1< number2)
{
int temp = number1;
number1 = number2;
number2 = temp;
}
}
}
Can You Afford a Build Machine?

 Can your team afford a machine
dedicated to automatically building
and testing your software on a
regular interval?
 Assume that a ten-person development
team costs your company $500/ hour
 If that team spends two less hours
debugging integration problems over
the life of the project, you’ve paid for a
build machine
8
03/03/2021
Can You Afford a Build Machine?

 Every day your team is fighting
integration and quality problems at
the end of your project is another
day your product is late to market
 You can’t afford not to have a
dedicated build machine
 Is your competition using automated
building & testing?
CruiseControl
 Requires a separate build machine

6
9
03/03/2021
CruiseControl
 Automated Builds
 Push a button
 Scheduled Builds
 Don’t need to push
any buttons
For Continuous Integration ...

 SCM system
 To ensure latest code changes are included
 Automated or (better) scheduled builds
 To detect and resolve build issues early and
often
 Automated unit tests
 To detect and resolve unit and integration
issues early
 (Not really part of Continuous
Integration, but some teams also like to
automate some acceptance tests)
10
03/03/2021
Developer’s Goals
 Deliver working production code
 Measurable quality
 Resulting in happy customers
 Be productive
 Intelligent use of time
 Address issues associated with software
changing over time
 Work smarter, not harder
 Processes
 Tools
Three Types of Code Changes

 Fix defects
 New requirements
 Refactoring
 Refactoring is NOT the same as fixing
defects
 You end up with exactly the same
functionality as before, just (hopefully)
simpler code
11
03/03/2021
Making Code Changes

 If you make even a simple change,
how do you know that you haven’t
broken anything?
Making Code Changes

 You MUST have automated unit tests
 Imagine a large application with many
people changing it
 Adding new features
 Fixing defects
 Refactoring code
 Continuous Integration will help you
address most of your integration
problems early – if you build your
automated test cases correctly
12
03/03/2021
Automated Unit Test Cases

 Create your unit test cases first, then
change the code until the test cases
pass
 Adding new features
 Fixing defects
SCM & Continuous Integration Perceived

Weaknesses
 Too much overhead (time and money)
 Overhead is much less than time and
effort required to fix integration issues
late in the project
 Requires discipline by the project team
 This is a good thing
 Soft measures of project maturity:
 Who does your builds?
 How easy it is for any developer to make a
change, test it and commit the change for
other developers to use
13
03/03/2021
Summary - 1
 Build, compile and debug software
 eclipse
source code is stored in a shared
repository
 eclipse
 svn
repository and builds are automated
 eclipse
 svn
Referenced AntProf.Redley of CMU
 from © 2019, Tran Kim Sanh 27
Summary - 2
 [Continuous Integration] Build,
compile and debug software where
repository and builds and unit testing
are automated
 eclipse
 svn
 Ant
 JUnit
14
03/03/2021
Summary - 3
 [Continuous Integration] Build,
compile and debug software where
repository and builds and unit testing
are scheduled
 eclipse
 svn
 Ant
 JUnit
 CruiseControl
Summary - 4
 Different tools for different
environments and development
languages
 JUnit (CppUnit, ...)
 CruiseControl (Anthill, ...)
 Take advantage of the many good
open source tools to increase:
 Your productivity
 The quality of your code
15
03/03/2021
Video link
 https://www.youtube.com/watch?v=q
Ohfl9gayB8
 https://www.youtube.com/watch?v=S
DwqcFwvwY0
References
 Ian Sommerville (2016). Software
Wesley Computer Publishing. PP
735- 756
16
03/03/2021
Practices
TRAN KIM SANH
Instructor of DTU
Tel: 0987 409 464
Summary and MidExam
Contents
 Introduction to Teamwork
 Using Processes
 Technical Review Process
 Configuration Management Process
1
03/03/2021
 Characteristics of High Performance
Teams
 Are You a Problem?
 Giving and Receiving Feedback
 Personal Responsibility
 Personal Values
2
03/03/2021
Using Processes
 What is a Process?
 Why is Process Important?
 What Processes Will I Need?
Defining a Technical Review Process

 What is a Technical Review?
 What Type of Technical Review is Right
for My Project?
3
03/03/2021
Reviewing the Technical Revie Process

 How Effective Is Our Process?
 Practicing Giving and Receiving Feedback
Technical Review of Code

 Technical Review of Code
 Students are Given a Source File to Inspect
 How Effective Is Our Technical Review
Process on Code?
4
03/03/2021
Defining a CM Process
 What Configuration Management Is?
 Why Configuration Management Might Be
THE Most Important Process for
Developers
Using CM Process 1
 Using Configuration Management – Part 1
 Teams Install and Use a Configuration
 SVN
5
03/03/2021
Using CM Process 2
 Fixing the Build Problems
Summary
 Introduction to Teamwork
 Using Processes
 Technical Review Process
 Configuration Management Process
6
03/03/2021
References
 Ian Sommerville (2016). Software
735- 756, 656 – 666, 43 – 71, 700
– 729
Midterm Assignment
60 MINUTES
7
03/03/2021
Contents
What is a Defect?
Application Development 
Cost of Defects
Practices 
 Defects as Opportunities
TRAN KIM SANH
Instructor of DTU  Tips for Finding Defects
Email: trankimsanh@dtu.edu.vn  Tips for Fixing Defects
Tel: 0987 409 464
 Defect Distribution
Analyzing and Fixing Defects
1
03/03/2021
Characteristics of Software Quality Characteristics of Software Quality
 Correctness  Installability  Accessability  Operational

availability
Defects

 Maintainability*  Auditability  Flexibility*
 Usability Configurability
 Portability* 
 Personalization  Reliability
 Performance Internationalization
 Reusability* 
 Robustness
 Scalability  Efficiency
 Readability*  Safety
 Interoperability
 Extensibility  Security
 Testability*
* Internal software characteristic * Internal software characteristic

2
03/03/2021
What is a Defect? Relative Cost of Fixing a Defect

Code defects are programming errors
70

 Sources of defects: 60
Relative Cost to Correct a Defect

 Poor understanding of requirements 50
 Poor design 40
 Poor coding practices
 Limited or no unit and integration testing 30
 Introduced during defect fixing 20
 Typos
Others ...
10

0
Requirements Design Code Development Acceptance Operation
Testing Testing
Development Phase
3
03/03/2021
Defects & Schedules Defects as Opportunities

 “[IBM] found that products with the  Assuming that the developer does not
lowest defect counts were also the want to have defects ...
products with the shortest schedules”  ... it means that the developer doesn’t fully
understand:
 If you’re finding more than 5% of your
defects after product release:  What the software does
 Vulnerable to low quality problems  How the software works
 Taking more time to develop than necessary
 How to make the software do the right
 If you can prevent defects, or detect and things
remove them early, you can realize a
 What is your choice?
significant schedule benefit
 Intentional development?
 Developing by trial and error?
4
03/03/2021
Defects as Opportunities Defects as Opportunities

 As a developer you can:
 Learn about the program you’re working
on
 Do you fully understand how it all works?
 Learn about the kind of mistakes you
make
 Learn about the quality of your code
(from the perspective of someone who
has to read it)
 Is your code easy to read?
 How could it be better (ask someone)?
5
03/03/2021
Defects as Opportunities Steps for Fixing Problems

 As a developer you can:  Identify how to repeat the problem
 Learn about how you solve problems  Gather data through repeatable experiments
 Does your approach to finding problems  You may need to replicate the user’s
work? machine
 Do you find defects quickly?  Form a hypothesis that accounts for the
 Do you guess at where the problem is? behavior
 Learn about how you fix defects
 Do you make a complete problem
diagnosis and implement systematic
corrections?
6
03/03/2021
Steps for Fixing Problems Tips for Finding Defects

 Design an experiment that  A software problem may result from one
proves/disproves the hypothesis or more defects
 By testing the software or examining  If you are having trouble finding the
the code defects associated with a problem:
 Run the experiment  Use all data available to make your
hypothesis
 Repeat as needed
 Refine the test cases that produce the defect
 Fix the defect  Isolate the problem
 Test the fix
 Look for similar problems
7
03/03/2021
Tips for Finding Defects Tips for Finding Defects

 If you are having trouble finding the  If you are having trouble finding the
defects associated with a problem: defects associated with a problem:
 Isolate the suspicious regions of code
 Use available tools
 Reproduce the problem several  If problem stays, it wasn’t in the part you
different ways removed
 Generate more data to generate more  Be suspicious of classes and methods
hypotheses that have had defects before
 Use the results of negative tests  Keep data on defects found in classes and
methods
 Brainstorm for possible hypotheses
 Make a list of things to try  Check code that has changed recently
 Integrate incrementally
12
8
03/03/2021
Tips for Finding Defects Tips for Finding Defects

 If you are having trouble finding the
defects associated with a problem:
 Check for common defects
 Use code-quality checklists to stimulate
your thinking
 Talk to someone else about the
problem
 Often you will uncover the defect just by
describing what you have done so far to
someone else
 Take a break from the problem
 Go for a walk. Work on something else.
9
03/03/2021
Know Your Available Tools Know Your Available Tools

 Scientific method  Internal trace log
 Isolate the problem and  Logs system events in the
make it repeatable order that they occur,
along with relevant data
 Compilers, memory &
syntax checkers  In-circuit emulator (ICE)
 A hardware device used to
 Interactive Debugger debug the software of an
 Determine the behavior embedded system
of your software as it
executes  Design review
 Breakpoints  Walk through the broken
code with many eyes
 Print statements
10
03/03/2021
Tips for Fixing Defects Tips for Fixing Defects

 Understand the problem before you fix it  Fix the problem, and not the symptom
 Understand the program, not just the  Don’t put in special case fixes. They are
hard to maintain, and probably don’t solve
problem the problem
 Or at least the vicinity of the problem
 Look for similar defects
 Confirm the defect diagnosis
 Run test cases that prove your hypothesis  Don’t change code randomly and hope it
fixes things
 Don’t rush
 Time pressure can lead to rushed judgment,  Fix one problem at a time
incomplete diagnosis and incomplete  Saving up changes and checking them all at
correction the same time just makes it more difficult for
someone else to figure out what fixed what
later
11
03/03/2021
Tips for Fixing Defects Defect Distribution

 Check your work  Defects are not distributed evenly
 Consider asking someone throughout the source code
else to check it as well
 Specific classes will be error prone.
 Add unit tests that verify Look for these
that the problem has been  Highly defective routines are very
thoroughly fixed expensive
 Document the fix
 From studies;
 Enter the bug number and
describe what was fixed  80% of defects are found in 20% of
 Capture root cause data in classes or routines
the change request system  50% of defects are found in 5% of
 Check your tests classes
12
03/03/2021
Estimating Defect Fixes Estimating Defect Fixes

 Most defects are easy to fix  Don’t assign junior programmers to fix
 ~85% can be fixed in a few hours defects
 ~15% can be fixed in 4 hours to a few days  They can unintentionally introduce new
 ~1% take longer than a few days defects
 No matter what management wants to hear, you  If a defect must be fixed quickly, consider
can’t provide an estimate for fixing a problem
assigning 2 or 3 developers to it
until you have diagnosed the problem
 Some take a long time to diagnose and are
easy to fix
 Some are easy to diagnose and are hard to fix
 Pressure to fix defects quickly can easily cause

the insertion of new defects
13
03/03/2021
Rules for Making Code Changes Group discussion?

 Developers responsible for:  Read the paper below and discus with
 Keeping their machine in synch with the any team members about the lession
configuration management system we learn from our bug.
 Fixing one defect per set of source file
revisions  https://itviec.com/blog/bug-la-gi/
 Creating/updating automated unit tests
 Creating/updating automated system and/or
acceptance tests
 Ensuring that all tests run successfully before
integrating code back into master repository
 Resolving conflicts when checking code back
in
 Updating change documentation
14
03/03/2021
Summary Video link

 As a developer YOU are responsible for  https://www.youtube.com/watch?v=
creating high quality code in a timely and 7xeU2vCHQg0
predictable manner
 Learn:
 The software you are working on
 Coding and problem solving techniques
 The development tools available to you
 Share your knowledge, and learn from
your peers
 In most cases, the projects with the
fewest defects have the shortest
schedules
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh Referenced from Prof.Redley of CMU
29 © 2019, Tran Kim Sanh 30
15
03/03/2021
References
 McConnell, Steve Code Complete.
Microsoft Press, 2004. pages 540-
541
 McConnell, Steve Code Complete.
Microsoft Press, 2004. pages 540-
548
16
03/03/2021
Director’s Overview
 What is Refactoring?
 Why Refactor?
Application Development Practices
 Reasons Not to Refactor?
TRAN KIM SANH
Instructor of DTU  How to Refactor
Tel: 0987 409 464
 Refactoring in eclipse
Refactoring
1
03/03/2021
What is Refactoring? What is Refactoring?

 “Refactoring" source code means  Refactoring is a disciplined technique
improving it without changing what it  Each refactor should be small
does  So it is less likely to go wrong
 The system is kept fully working after
 Refactoring does NOT: each small refactoring
 Fix defects  Reducing the chances that a system can
 Add new functionality get seriously broken during the
 The goal of refactoring is to: restructuring
 Increasing the need for automated unit
 Improve the understandability of the code
test
 Improve the structure of the code
 Remove unnecessary code  Refactoring can produce a significant
benefit over time
Martin Fowler, http://www.refactoring.com/
2
03/03/2021
Example Why Refactor?

 Because software evolves over time
 During development
 Original developers involved
 During maintenance
 Different developers likely to be involved
 Original intent of developers has been
forgotten
 Because of “code smells”
 Smells are heuristics that can indicate
when and what to refactor
 Smells are indicators, not causes
Steve McConnell, Code Complete, 2nd Edition. Microsoft Press 2004
Referenced from Prof.Redley of CMU Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 6
3
03/03/2021
Bad smell of code Is Your Software’s Evolution ...

 A planned-for opportunity that is
improving the internal quality of the
software?
 A haphazard activity that is continually
degrading the product’s quality?
Is Quality An Accident?
4
03/03/2021
Some Reasons to Refactor - 1 Some Reasons to Refactor - 2

 Duplicate code  Class interface with an inconsistent
 Must make changes in multiple places level of abstraction
 Routine that is too long  May want to recapture interface integrity
 Routines should do one thing well  Parameter list with too many
 Loops are too long or too deeply parameters
nested  Well-factored programs tend to have
many small, well-defined routines that
 Convert loop content into routines?
don’t require large parameter lists
 Poor cohesion
 Class changes are compartmentalized
 Methods that implement a single function
 A class has too many responsibilities
are described as having high cohesion
Steve McConnell, Code Complete, 2nd Edition. Microsoft Press 2004 Steve McConnell, Code Complete, 2nd Edition. Microsoft Press 2004
2 2
n n
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 9 d Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 10 d
5
03/03/2021
Some Reasons to Refactor - 3 Code smell heuristics

 Parallel modifications to multiple
classes
 Should classes be rearranged so that
changes affect only one class
 Inheritance hierarchies have to be
modified in parallel
 Making a subclass of one class every time
you make a subclass of another class is
another form of parallel modification
 Related data items that are used
together are not organized into classes
2
n
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 11 d Referenced from Prof.Redley of CMU
6
03/03/2021
Ex: Data Level Refactoring Ex: Statement Level Refactoring

 Replace a magic number  Consolidate fragments that are
with a named constant duplicated within different parts of a
 Use a named constant conditional
(e.g. “Pi”) instead of a  If same lines of code are repeated in a
literal (e.g. “3.14”) conditional
 Rename a variable with  Replace conditionals with
a clearer or more polymorphism (especially with
informative name repeated case statements)
 Replace “name” with
 Create and use null objects instead of
“accountname”
testing for null values
Steve McConnell, Code Complete, Edition. Microsoft Press 2004
 Move null checking code awayEdition.
Steve McConnell, Code Complete,
from the
Microsoft Press 2004
2 2
n
d
client and into the© 2019,
Referenced from Prof.Redley of CMU class Tran Kim Sanh 14
n
d
7
03/03/2021
Ex: Routine Level Refactoring Ex: Class Implementation Refactor
 Extract a routine  Extract specialized code into a subclass

 Remove inline code from one routine, and  If a class has code that’s used by only a
turn it into its own routine subset of its instances, move that specialized
code into its own subclass
 Convert a long routine to a class
 If a routine is too long then maybe it should  Combine similar code into a superclass
be its own class  If two subclasses have similar code, combine
that code and move it into the superclass
 Substitute a simple algorithm for a
complex algorithm
 Simplify
 Remove a parameter
 If the parameter is no longer used
2
n
Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 15 Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 16 d
8
03/03/2021
Example Ex: Class Interface Refactoring

 Convert one class to two
 If a class has more than one distinct area
of resonsibility
 Eliminate a class
 If the class isn’t doing much
 Encapsulate an exposed member
variable
 Change the data to private and expose
the data’s value through a routine
instead
Steve McConnell, Code Complete, 2 nd Edition. Microsoft Press 2004

9
03/03/2021
Ex: System Level Refactoring Reasons NOT to Refactor

 Duplicate data you can't control  Refactoring is NOT defect fixing,
 If you have multiple sources that must adding functionality or modifying the
access data, then move the data to its design
own class and have all sources treat that  Do these types of maintenance efforts
class as the definitive source of the data separately
 Sometimes code is so bad it needs to
be rewritten
Steve McConnell, Code Complete, 2 nd Edition. Microsoft Press 2004 Steve McConnell, Code Complete, 2 nd Edition. Microsoft Press 2004
10
03/03/2021
Reasons NOT to Refactor How to Refactor - 1

 Make sure your can get back to where
you started
 SCM system
 Backups
 Keep refactoring as small as you can
 Do one refactoring at a time
 Make a list of refactoring steps you
intend to take
 Log additional refactoring ideas/needs
that you encounter
11
03/03/2021
How to Refactor - 2 Refactoring in eclipse

 Make frequent checkpoints  We have
 Execute existing unit tests a variable
(name) that
 Add new unit tests we want to
 Recognize that different refactoring change to
efforts include different levels of risk something
 Err on the side of caution more
 Peer review your refactoring changes meaningful
(accountow
nername)

12
03/03/2021
Refactoring Menu in eclipse Refactoring Menu in eclipse

 Right  Enter the
click on
the new
variable, name for
select the
Refactor
and then variable,
Rename then
 Note the press
other
refactoring Enter
tools
available
13
03/03/2021
Refactoring Menu in eclipse Summary

 Note that  Refactoring does NOT change the
eclipse has software’s functionality
found  Refactoring is just good programming
everywhere  Be careful and safe when you refactor
that the
 The refactoring lists in this
variable is
presentation are not complete. For
used and complete lists:
changed it  Steve McConnell, Code Complete, 2nd
there for edition. Chapter 24 (cc2e.com)
me  Martin Fowler, Refactoring: Improving the
Design of Existing Code
14
03/03/2021
Group discussion? Video link

 Discuss with all team member about the  https://www.youtube.com/watch?v=dIj
refactoring function on eclipse (10 1W8RKge8
minutes)
15
03/03/2021
References
 McConnell, Steve Code Complete.
Microsoft Press, 2004. pages 563 – 585
 Martin Fowler, Refactoring: Improving
the Design of Existing Code
16
03/03/2021
Contents
 Requirements & Methodology
 Managing Traditional Requirements Change
Application Development Practices  Managing Agile Requirements Change
TRAN KIM SANH
Instructor of DTU
 Estimating Change
 Using Change Management Tools
Tel: 0987 409 464
Analyzing & Estimating Requirements
© 2019, Tran Kim Sanh 1 Referenced from Prof.Redley of CMU © 2019,Tran Kim Sanh 2
1
03/03/2021
Traditional Methodologies Agile Methodologies

 Traditional methodologies assert the need  Agile methodologies use lighter, more adaptive
for strong process discipline and rigorous paradigms
practices  Product built so you always have a working system
and can “release” at any time
 Quality products come from quality  Refactoring is good?
processes
 The Agile manifesto says that we have come to
 Assumes requirements are known at start
value:
 Assumes that a complete schedule & budget  Individuals & interaction over process & tools
can be developed from the requirements  Working software over comprehensive docs
 Build products in stages  Customer collaboration over contract negotiation
 Change is managed formally  Responding to change over following a plan
 Rework = Waste  That is, while there is value in the items on the right,
we value the items on the left more
Referenced from Prof.Redley of CMU © 2019,Tran Kim Sanh 3 Referenced from Prof.Redley of CMU © 2019,Tran Kim Sanh 4
2
03/03/2021
Traditional vs Agile Requirements & Methodology

 Traditional
 Big requirements up front
 (Often) minimal user involvement
 Big plan up front
 Control changes
 Agile
 Lightweight requirements
 Emphasis is on working code
 Must have user involvement
 Minimal long range planning
 Change is embraced
3
03/03/2021
Managing Traditional Change Managing Traditional Change

 Institute an attitude that change management is  Use Tools to Track Changes
necessary  Configuration Management – Manage
 Have a Documented Change Process revisions

 Bug Tracker - Track change orders and their
 Baseline Project Artifacts
status
 Build Rapport with Customer
 Measure the changes
 Work on prioritized change requests (CR) from a  So you can quantify the impact of the
Change Control Board (CCB) changes
 To improve your ability to estimate
Steve McConnell, Rapid Development. page 237 Steve McConnell, Rapid Development. page 237
4
03/03/2021
Change Management tools An Attitude of Change - 1

 Set expectations with all stakeholders:
 Change is inevitable
 Let’s agree on a change process so we all
know how to work together to get the best
results
 Let’s understand what the development
processes are so we know what to expect
 Other groups need to get involved to assess
the change in terms of:
 Test, Technical Publications, Support, etc.
 Don’t make changes until authorized to do
Steve McConnell, Rapid Development. page 237
5
03/03/2021
An Attitude of Change - 2 Build Rapport with Customer

 Set expectations with all stakeholders:  We are doing this project to solve a customer/user
problem or address a need
 Software Engineers will evaluate submitted
Customer involvement and communications can
changes in terms of: 
 Reduce errors, misunderstandings and standoffs
 Scope
 Improve customer’s perception and confidence in you
 Resources and your project
 Schedule
 Work with the customer to:
 Cost
 Explain the software life cycle & its purpose
 Risk  Provide accurate & trustworthy status & progress
 Your estimate may not be what  Describe alternatives and their benefits and costs
 Describe risks
management submits to the customer
 Don’t talk about money
Be Helpful and Supportive. It is their project
 Talk in ranges Steve McConnell, Rapid Development. page 237 Steve McConnell, Rapid Development. page 237
6
03/03/2021
Problems Building Rapport with Customer - 1 Problems Building Rapport with Customer - 2
 Customers often don’t know what they want  Customers sometimes won’t commit to a
 Learn and use requirements-eliciting practices set of written requirements
that help customers figure out what they want  Possibly the requirements are too big,
 Internal (to your company) customers: technical and hard to understand
 Interface prototyping, Evolutionary prototyping,
 Try describing the product in their language
Joint Application Development (JAD), etc.
 Conduct focus groups  Prototypes
 Examples
 External (to your company) customers:
 Videotape people using the software
 Conduct surveys to assess your
relationship with your customers
7
03/03/2021
 Communication with customers can be slow  Customers will not (or can’t) participate in
 Communicate what you need and when with reviews
your customer, and what the impact is if you  Customers may not have the expertise
don’t hear from them on time  Use less technical, detailed or tedious
 If that doesn’t work, then communicate with specifications
your customer that you need to let your  Offer to provide some training
management know that you are stuck with  Offer encouragement
getting information from the customer  Look for another way
 If that doesn’t get your customer to respond,  Customers may not have the time
then escalate the issue to your management  Talk with your management about conveying
 Make sure you really need the customer’s to the customer the risk of project failure if the
time customer doesn’t/can’t participate
 Don’t make a big deal about something trivial Steve McConnell, Rapid Development. page 237
8
03/03/2021
 Customers won’t let people do their jobs  Customers don’t understand the software
 Help the customer focus on what, and not development process
how  Don’t try to teach them about software
 Help the customer understand the lifecycles (unless they are interested)
consequences of their technical  Do explain to them the processes that they
requirements need to participate in, and their role in those
processes
 Keep them informed with what is coming up
so they are aware and informed
9
03/03/2021
 Engineers often over promise and under deliver  Engineers often don’t consult with their
 Agreeing to unrealistic expectations will
customers, especially if there is not a
always damage your credibility
good relationship
 Use estimation techniques and let everyone
know that you will be collecting data to  Don’t let this happen!
improve your ability to estimate accurately  Always treat the customer with respect
 Never make promises about functionality,  Always be professional, courteous and
dates or cost without verifying your promises deferential
first  Try your best, even in difficult situations
10
03/03/2021
 Engineers often think they know better  Engineers build inflexible systems
 Don’t add or modify features on your own  Use good design practices to build systems
(without CCB approval) that can be modified
 Don’t add or modify features without  Consider alternative designs and involve
making sure the customer approves the customer with the final decision
making
11
03/03/2021
Traditional Requirements Change You May See A CR Multiple Times

 Must have baselined requirements  Analyze Change
 Else how will you know the scope of the new  You analyze a change to determine how
or changed requirement? long it will take, who will need to be
 Changes must only come from the CCB involved, how much effort it will take, etc.
 Don’t accept changes directly from end user,  You pass this analysis information back to
customer, senior management, etc. the CCB
 How you can manage this successfully:  If the CCB (including the customer)
 “Of course I will, but the project manager has said
that we can only work on changes sent to us by agrees to implement the change, then
the CCB. Can we run this by the project you may be required to change the
manager?”
 “Of course, but shouldn’t we follow the process?”
source code and coordinate any other
changes with other groups
12
03/03/2021
CR and CCB Avoid Common Problems

 Analyze changes quickly
 Do a few well rather than many poorly
 Involve stakeholders in the change process
 Use discipline when following the change process
 Follow a checklist when analyzing changes
 Who else needs to be involved?
 What work needs to be done for the change to be
completed?
 Collect and analyze change data
 Keep good design notes
 You may not be who implements the change
13
03/03/2021
Agile Change Management - 1 Agile Change Management - 2

 Fourth “value” of the Agile Manifesto  Agile methods enable projects to be responsive
 "Responding to change over following a plan" to change by:
 Change in mindset:  Using short and frequent iterations to minimize the
time between specifying a requirement & seeing it
 Goal isn’t to prevent changes to an agreed to
implemented
baseline
 Requiring developers and customers to communicate
 Goal is to embrace change as a natural part of
and work together daily (co- located together if
development
possible)
 Customers/Users (Product Owner)  Accommodating (even encouraging) changes in scope
 Prioritize the ‘user stories’ on the ‘product and priorities by informing the customer of impact
and risk, & putting the customer in control of the
backlog’ to be implemented at the beginning scope & priorities
of each iteration/sprint (see ‘planning game’)
 Are available to help answer the developer’s Source: http://www.cmcrossroads.com/articles/agileaug03.html
implementation questions
14
03/03/2021
Types of Agile Change Agile Change Management - 3

 Agile methods enable projects to be
responsive to change by:
 Authorizing and empowering team
members to correct problems with the
code’s behavior and structure without
having to suffer delays waiting for formal
change process
 Little or no change tracking or
traceability with Agile methods
 Focus on keeping things as simple as
possible
Source: http://www.cmcrossroads.com/articles/agileaug03.html
15
03/03/2021
1: Product Backlog 2: Sprint Backlog
 The work to be done on a Scrum project is listed on  At the start of each  The Product Owner
a “product backlog” sprint a Sprint Planning prioritizes the
Meeting is held Product Backlog
 A list of all project work,
including requirements  The Scrum Team
selects the tasks
 Prioritized by the product they can complete
owner during the coming
 Reprioritized by the Sprint
product owner during  These tasks are
planning at the start of then moved from
each sprint the Product
Backlog to the
Sprint Backlog
16
03/03/2021
3: During the Sprint Use Change Management Tools

 The Product Owner is  CR Tracking system
available to provide clarity to
developers on what is desired  Fully document the change
in terms of feature look, feel &
implementation  Development is
 Configuration Management
 User stories may be broken
happening  Check in one change at a time
into other stories or sub-  Log other data, as required
stories
 Effort
 The Product Owner can not
add new stories in the middle
of a sprint
17
03/03/2021
Change Estimation ... Summary - Traditional

 Is the same for each methodology as estimating  You need to implement important
original requirements: customer changes, but too many changes
 Traditional: can kill the project
 Use a work breakdown structure (wbs) to
 Your change management process can
consider all work
help filter out ‘non-essential’ changes,
 Use historical data, parametric or wideband
delphi estimation method however you risk losing customer rapport
if your change management system is
 Agile:
perceived as unwieldy and bureaucratic
 Estimate available hours for the iteration
 Repeat until full:  Communicate openly and honestly with
 Pick a story, break into tasks, estimate each task your stakeholders to find the right balance
 Track and use historical data to refine velocity for your project
18
03/03/2021
Summary - Agile Group discussion?

 Change is a natural part of the agile  Discuss with all team member about
development process “How to manage change in waterfall
model” (10 minutes)
 You need to implement important
customer changes, but too many
changes can kill the project
 It is up to the product owner to filter
out ‘non-essential’ changes
 Communicate openly and honestly with
your stakeholders to find the right
balance for your project
Referenced from Prof.Redley of CMU © 2019,Tran Kim Sanh 37 Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 38
19
03/03/2021

 https://www.youtube.com/watch?v=WW  McConnell, Steve Code Complete.
dgFFVkPgA Microsoft Press, 2004. pages 563 – 585
 Martin Fowler, Refactoring: Improving
the Design of Existing Code
 http://www.cmcrossroads.com/articles/a
gileaug03.html
20
03/03/2021
https://bit.ly/2AItZbG
Referenced from Prof.Redley of CMU © 2019,Tran Kim Sanh 41
21
03/03/2021
Contents
 Is Quality an Accident?
 Test Driven Development
Application Development Practices
 Integration Test
TRAN KIM SANH
Instructor of DTU  Acceptance Test
Tel: 0987 409 464
 System Test
Testing and Quality  Test Coverage
1
03/03/2021
Is Quality an Accident? Who Owns Quality?

 Quality is never an accident; it is
always the result of intelligent effort."
- John Ruskin
You Do!
2
03/03/2021
Characteristics of Software Quality Characteristics of Software Quality
 Correctness  Installability  Accessability  Operational

availability
Defects

 Maintainability*  Auditability  Flexibility*
 Usability Configurability
 Portability* 
 Personalization  Reliability
 Performance Internationalization
 Reusability* 
 Robustness
 Scalability  Efficiency
 Readability*  Safety
 Interoperability
 Extensibility  Security
 Testability*
* Internal software characteristic * Internal software characteristic

3
03/03/2021
Quality Approaches Defect Detection Rates - 1

 Find defects Removal Step Lowest Rate Modal Rate Highest Rate
Informal design 25% 35% 40%
 Prevent defects reviews
Formal design 45% 55% 65%
 Do Both inspection
Informal code 20% 25% 35%
reviews
Formal code 45% 60% 70%
“Testing can only prove the presence of features inspections
and defects, not the absence of defects” Modeling or 35% 65% 80%
prototyping
Personal desk 20% 40% 60%
“You can’t test in quality” checking of code
Steve McConnell, Code Complete 2

nd edition. page 470
4
03/03/2021
Defect Detection Rates - 2 Defect Detection Rates - 3

Removal Step Lowest Rate Modal Rate Highest Rate Removal Step Lowest Rate Modal Rate Highest Rate
Unit test 15% 30% 50% Informal design 25% 35% 40%
Integration test 25% 35% 40% reviews
Informal code 20% 25% 35%
Regression test 15% 25% 30%
reviews
System test 25% 40% 55% Personal desk 20% 40% 60%
checking of code
Low-volume beta 25% 35% 40%
test (<10) Unit test 15% 30% 50%
High-volume beta 60% 75% 85% Integration test 25% 35% 40%
test (>10) Regression test 15% 25% 30%
Expected ~74% ~90% ~97%
Cumulative
 Different steps find different defect types defect-removal
efficiency
 Combine steps to find the most defects
nd edition. page 470 Steve McConnell, Code Complete 2
5
03/03/2021
Quality – General Principles Quality Costs

 Defects creep into software at all  Quality is not free, so what does it cost?
stages  Studies have found that defect removal is
 Improving quality reduces the most expensive and time consuming
development time and costs work on software projects
 Up to 50% for poorly run projects
 Most studies have found that inspections
are cheaper than testing
“The best way to improve productivity and quality is
 Finding defects earlier reduces their costs
to reduce the time spent reworking code”

nd edition. page 470 Steve McConnell, Code Complete 2
6
03/03/2021
Quality Plan – What to Do? Quality Plan – What to Do?

 Consider an integrated approach:  Remember that you need to prevent
 Inspections of all requirements, architecture defects as well as detect them:
and designs for critical parts of a system  Inspections help cross-train the team on
 Modeling or prototyping the system, tools, programming style, etc.
 Code inspections (lightweight)
 Techniques such as test driven
 Test driven development
development can help build in more
 Continuous integration
systematic testing
 Automated builds
 Build and test automation used in
 Automated unit test
continuous integration can help ensure
 Integration test
that what was working yesterday still
 Systems test (including performance, etc.)
works today
7
03/03/2021
Quality Plan – What to Do? Quality Plan – What to Do?

 Remember to add other elements, as  Quality costs will also increase if the
necessary: product demands a higher degree of
 Inspections of all requirements, architecture reliability
and designs for critical parts of a system
 Medical systems
 Usability testing
 Airplane guidance systems
 Modeling or prototyping
 Weapons systems
 Code inspections (lightweight)
 Test driven development
 Continuous integration
 Integration test
 Systems test (including performance, etc.)
8
03/03/2021
Testing Test Driven Development

 Testing cannot be expected to catch every error  Testing approach matters
in the program - it is impossible to evaluate all
 Test all at once at the end
execution paths for all but the most trivial
programs  vs
 The goal of unit testing is to isolate each part of  Test continuously and systematically
the program and show that the individual parts
are correct
 We also need to catch integration errors, or
broader system level errors (such as functions
performed across multiple units, or non-
functional test areas such as performance)
9
03/03/2021
Test Driven Development Test Driven Development

 Test-driven development requires  Evolve and expand your test suite over
developers to create automated unit time
tests that define code requirements  Whenever a defect is found
before writing the code itself  When adding new features
 When you look at someone else's code and
 The unit tests contain assertions that see a testing hole
are either true or false  Test all of your code for functionality
 Passing the tests confirms correct  If you miss something a test for it will be
behavior as developers evolve and added eventually
refactor the code  Over time you will have a collection of
tests that will verify functionality at the
unit level
10
03/03/2021
What is Integration Testing? Int. Testing Alternatives

 Verifies that:  Bottom-up
 Components interact correctly  Top-down
 The interaction results are consistent with  Depth-first
the function requirement for those
 Breadth-first
components
 Hybrid
 Emphasizes exercising the interfaces
between components
11
03/03/2021
Int. Testing: Bottom-Up Int. Testing: Bottom-Up

 Start after unit testing
 Identify modules
 Combination of units that work/interface
together
 Focus on the feature being implemented
 Identify how this feature impacts other
areas
 Test each module
 Repeat this process progressively to
higher levels
12
03/03/2021
Integration Testing: Top-Down Integration Testing: Hybrid

 Begin testing at the highest level first  Used in comprehensive software
 Progressively identify next lower level development environment
modules  Bottom up: usually done first
 Run tests at this new level  Takes the component view
 New components interface correctly
 Two basic approaches to successive
level  Top down: usually done last
 Takes the product feature view
 Depth first
 System view of new feature
 Breadth first
13
03/03/2021
Int. Testing: Exit criteria Integration Testing Issues

 All interfaces where components  Tedious and time consuming
interact are successfully tested  How much is enough?
 Negative test cases should also be
covered
14
03/03/2021
Acceptance Testing Acceptance Testing

 Does the system satisfy the user’s/  Traditional acceptance testing
customer’s acceptance criteria?  Alpha testing:
 Be sure to define acceptance criteria at  End user testing in a somewhat controlled
project start test environment
 “Friendly” environment
 Most testing performed by developers
 Beta testing:
& testers
 End user testing at end user's site
 User/customer has acceptance testing  Full range of environments
responsibility  Agile acceptance testing
 Is the user’s/customer’s responsibility  At the end of each sprint
 Many users/customers don’t know how to  Not as thorough as system test
perform acceptance testing and will need help  Verify that product functions as desired
15
03/03/2021
Acceptance Testing - 2 Systems Testing

 End user actively involved in  Follows unit, integration & acceptance
acceptance test plan definition testing
 Identify the criteria which, when met, will  Performs a variety of tests
cause the customer to accept the product
 “black box” functional testing
 Usually a joint effort between
 Nonfunctional
development & user/customer
 Performance
 Acceptance test plan components  Load
 Acceptance criteria and schedule for all  Stress
deliverables  Scalability
 Acceptance activities and who will perform
 ...
16
03/03/2021
Test Coverage Group discussion?

 There is no way today to say: "there  Find defects in Login form
are absolutely no defects”
 Being able to state that "we've
executed every line of code, and all
our tests passed"
 Adds to our comfort level
 Still doesn’t allow us to say “there are
absolutely no defects”
 Defining the tests (and therefore test
coverage) still requires human thought
17
03/03/2021
Summary Video link

 Testing is just one part of a quality plan  Seven Testing Principles: Software
 Be sure to plan for your quality activities: Testing
 Processes/practices  How to write a TEST CASE? Software
 Deliverables Testing Tutorial
 Learning curve
 Time
 Effort
 Resources
 $
 Prevent defects as well as detect them
18
03/03/2021
References
 Ian Sommerville. Software engineering update 10th

edition. Wesley Computer Publishing 2018 Page: 226- 241
19
03/03/2021
Director’s Overview
Application Development  What is Customer Satisfaction?
Practices  Kano Model (for assessing customer
satisfaction)
TRAN KIM SANH
Instructor of DTU  Why is this important to you?
Tel: 0987 409 464  Stakeholders
 Additional customer satisfaction
Customer Satisfaction measures
© 2019, Tran Kim Sanh 1 Referenced from Prof.Redley of CMU ©2019 Tran Kim Sanh 2
1
03/03/2021
What is Customer Satisfaction? Kano Model

 A measure of how products and services
supplied by a company meet or surpass
customer expectation
 Because satisfaction is basically a
psychological state, care should be taken
in the effort of quantitative measurement
 The usual measures of customer
satisfaction involve a survey with a set of
statements using a Likert scale
 May want to consider using the Kano
model
 Invented by Noriaki Kano in the 1980’s
© 2009, Martin R. Radley 3
Referenced from Prof.Redley of CMU ©2019 Tran Kim Sanh 3 Referenced from Prof.Redley of CMU ©2019 Tran Kim Sanh 4
2
03/03/2021
Kano Analysis Technique Exciters

 Focuses on subjective measures  “I recently stayed in one that truly delighted me”
 Separates features into:  After putting my bags in the room, I went

downstairs to exercise
 Exciters
 Built into each treadmill was a small television I
 Linear
could control, which really thrilled me
 Baseline  I didn't have to watch the communal television just
because someone had already tuned to those
stations
 But it did require headphones, which I hadn't
brought. Then I noticed that the hotel gave away
free headphones with disposable foam earpieces.
Can you see why I was delighted?
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405
3
03/03/2021
Exciters Linear
 After working out, I went back to my room. I
was thirsty and noticed, again to my delight,
that the bottle of water the hotel left in my
room was free, not $4 as in most hotels
 An exciter is a feature that a user doesn’t know
he wants until he sees it
 This hotel had done a wonderful job of providing
features called "exciters" or "delighters””
4
03/03/2021
Linear Base line

 “The next category, linear, is for features that we can
describe as "the more of the better"
 An example would be the size of my hotel room. I am
generally more satisfied when a room is 500 square feet
rather than 250 square feet
 The more area there is in my hotel room, the better
 The presence and quantity of a linear feature
correspond directly to a user’s satisfaction with the
product
 Other examples of linear features are battery life on a
cell phone, horsepower in a car, and the number of
chocolate chips in a Chips Ahoy cookie”
9
5
03/03/2021
Baseline Kano Surveys

 “The final category is for features that are  The Kano analysis approach involves
mandatory” asking potential users sets of paired
 If a product does not include all mandatory (or questions
baseline) features, customers will be dissatisfied
and will not buy the product  Each pair includes:
 My hotel provided a bed, a shower, a television,  The functional question, which asks the
and so on user how she would feel if a feature were
present
 It was also reasonably clean and secure
 The dysfunctional question that asks the
 I consider each of these factors to be a baseline user how she’d feel if the feature were not
feature for a hotel
present
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405 http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405
6
03/03/2021
Kano Survey Questions - Example Kano Survey Example

Based on my response, each treadmill
 See next slide for how to interpret
having its own tv is mandatory
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405 http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405
7
03/03/2021
Issues with Kano Approach Group discussion?

 Kano approach focuses on user satisfaction  Watch the video below and give your
 When quality is subjective opinion on the steps to making customers
 Quality can also be objective satisfation
 Conformance to requirements  https://www.youtube.com/watch?v=XK3
cNcuvuMs
Referenced from Prof.Redley of CMU ©2019 Tran Kim Sanh 15 Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 16
8
03/03/2021
Why is this Important? Why is this Important to You?

 “The best products include:  So you understand that customer
 All baseline features (they have to) satisfaction is both subjective and
An appropriate mix of linear features and exciters

objective
 Remember that linear features have a linear  Customers can be annoyingly contradictory and
effect on customer satisfaction complex with their responses. Example:
 The more of them, the better  I won’t drink anything with too much sugar in it
 However, since time is scarce and often insufficient  I love drinking milk (which has lots of sugar in it)
for everything desired in most products, we often
cannot deliver all linear features  When talking with customers you can ask
 Even so, leaving room for some exciters does
questions about features in pairs to
wonders for customer satisfaction understand
 Functional
 Users will often pay a premium for a product  Dysfunctional
with the right mix of delighters”
9
03/03/2021
Why is this Important to You? Who Are Your Customers?

 If you are asked to be part  Customer
of a CCB you can use the  Is paying for the product
Kano analysis technique to  User Community
help determine product  Will be using the product
priorities
 Your Executive Management
 If the customer seems  Are paying you to keep the customer and user
dissatisfied with the community happy
product, you can suggest  The Project Team
using the Kano analysis  Anyone who consumes your deliverables
technique to your  What are you doing to make them successful?
management
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9405  Others ...
10
03/03/2021
Customer Satisfaction Dimensions Customer Satisfaction Dimensions

 Product Features  Value
 Does the customer end up with a good set of  Does the customer perceive
that this project was worth
delighters, linear and baseline features?
the time, money and
 Product Quality aggravation that it cost?
 Are the customer’s quality concerns  Timeliness
understood (see Quality Characteristics in  Did the customer get the
previous sections) and addressed? product or feature on time?
 Do all features work as expected?  Teamwork
 Are the project’s quality processes (see Is  Did the customer feel part of
Quality an Accident in previous sections) the team?
working for everyone?
 If not, change them
11
03/03/2021
Customer Satisfaction Dimensions Customer Satisfaction Dimensions

 Front line Service Behaviors  Innovation
 Was the development team helpful and  Did the development team come up with
responsive to the customer without simply new and innovative ideas to meet the
agreeing to everything? customer’s needs?
 Was the development team effective in  Others ...
communicating with the customer?
 Commitment to the Customer
 Was the development team committed to
doing everything it could to help the
customer be successful with this project?
12
03/03/2021
Communicating with Customers Attitude

 Understand customer expectations  “There is no communication without
Different types and levels of communication and
rapport” – Theresa Blanding

interaction depending on needs and preferences
 What communications would they like to receive?
 What involvement would they like to have
 Set expectations
 The process – how we will work together
 What they should expect from you
 What you expect from them
 What will be communicated, how often, in what
format and to whom
13
03/03/2021
What if There are Problems? What if There are Problems?

 If it’s you:  If it just isn’t working:
 Admit to the problem, learn from it and  Talk with your customer privately
move forward  Be professional and respectful
 Don’t try to hide it, you’ll be perceived as  Don’t do all the talking - Listen to what they
not trustworthy have to say
 Try to come to a resolution that meets the
 If it is the customer: customer’s needs
 Try to come up with a strategy for dealing  You need the customer
with them that will solve your problem more than he needs you
 Ask for help
14
03/03/2021
Summary Video link

 Customer satisfaction has two measures  Kano model
 Objective  5 Steps To Improve Customer
 Subjective Satisfaction
 Subjective measures are subject to bias
 Have a quality process and use it
 If it doesn’t work, change it
 Attitude goes a long way
 If it just isn’t working out, consider what
you would want to have happen if you
were the customer
Referenced from Prof.Redley of CMU ©2019 Tran Kim Sanh 29 Referenced from Prof.Redley of CMU
15
03/03/2021
References
 Ian Sommerville (2016). Software
735- 756
16
03/03/2021
Contents
Application Development  Technical Review
Practices  Software Configuration Management
 Finding, fixing defects and Refactoring
TRAN KIM SANH
Instructor of DTU code
Email: trankimsanh@duytan.edu.vn  Other
Tel: 0987 409 464
 Teamwork
 Software Process
Closure and Reflection  Testing overview
 Analyzing & Estimating Requirements
 Customer Satisfaction
What is programmer? Teams Involve People

 People have egos
 People are not consistent
 People make mistakes
 People are sometimes not professional
This Course ...

 Takes a “hands on” approach to
demonstrate how a team can work
together to make changes to:
 Software Product
 􀂃 Defects
 􀂃 Enhancements (Requirements)
 Processes
 Introduces the Concept of “Technical
Debt”
 Decisions we make today affect the
quality of the product tomorrow
1
03/03/2021
This Course ... Processes Help Us Work Together

 Does describe some agile concepts,  What does a good process look like?
but is mostly focused on traditional  How much process is too much?
software development
 Big requirements up front
 Do we have to write each process from
 Big architecture up front scratch?
 Process = Good  What are the key processes, and what
 Rework = Bad tools are there to help us automate
them?
Basic Premise
We can develop better software faster,

cheaper and with less effort if we
understand the basic processes that help
us work together effectively as a team
Three Key Processes Course Topics

 From a Software Developer’s  Introduction to Teamwork
Perspective:  Characteristics of High Performance
 Technical Reviews Teams
 Configuration Management  Are You a Problem?
 Change Management  Giving and Receiving Feedback
 Personal Responsibility
 Personal Values
 Using Processes
 What is a Process?
 Why is Process Important?
 What Processes Will I Need?
2
03/03/2021
Course Topics
 Defining a Technical Review Process
 What is a Technical Review?
 What Type of Technical Review is Right for My
Project?
 Reviewing the Technical Review Process
 How Effective Is Our Process?
 Practicing Giving and Receiving Feedback
 Technical Review of Code
 Students are Given a Source File to Inspect
 How Effective Is Our Technical Review
Process on Code?
Course Topics Course Topics

 Defining a Configuration Management  Analyzing & Estimating Defects
Process  How To Find Defects
 What Configuration Management Is  What To Look For
 Why Configuration Management Might Be THE  Fixing Defects
Most Important Process for Developers  Root Causes
 Using Configuration Management – Part 1  Defect Prevention
 Teams Install and Use a Configuration  Working With Configuration Management
 Management Tool (svn)  How Accurate Were the Estimates?
 Problems
 Fixing the Build Problems
Course Topics
 Analyzing & Estimating Requirements
Changes
 How To Define The Change
 What To Look For
 Implementing Requirements Changes –
Parts 1 & 2
 Coding the Requirements Changes
 Working With Configuration Management
 How Accurate Were the Estimates?
3
03/03/2021
Course Topics
 Testing & Quality
 Defining Unit Test Cases
 Automating Unit Test as Part of the Build
Process
 Customer Satisfaction
 What is Customer Satisfaction and How Do
We Achieve It as Software Engineers?
Course Approach Course Approach

 The focus is on active problem solving to  Simulation
promote the acquisition of usable knowledge  You are a Software Engineer at ABC Systems
rather than the collection of memorized facts  You report to the Director of Software
 You are expected to apply the knowledge you Development
have gained to solve the real world, simulated
issues that your ABC Systems Director will  Your Deliverables
assign to you  You will have team based work
 You will have individual work
 You will learn to express your ideas clearly and
persuasively, and be able to negotiate  You can help each other
effectively and with authority  Don’t copy work!
 The learning experience encourages the  Don’t plagiarize!
fundamental skill of self-directed learning
4
03/03/2021
Expectations of Students Is Quality an Accident? - 1

 Continue to leverage what you’ve learned  If no, then what, specifically are you
 Work with your team to get organized doing to ensure a quality product in
 Take ownership of your own success a timely manner?
“… no university exists that can provide an

education; what a university can provide is an
outline, to give the learner a direction and
guidance. The rest one has to do for oneself.”
- Education of a Wandering Man, Louis L’Amour
Is Quality an Accident? - 2 Is Quality an Accident? - 3

 Teamwork  Processes
 Characteristics of high  Why process and
performance teams process measurement
 Giving and receiving are important
feedback  The processes we use
 Personal responsibility to develop software
 Values  How to document a
 What does your behavior process
say about you?  How much process is
enough

 Inspection Process  Configuration Management
 Heavy versus lightweight processes to Processes and tools
accomplish the same goals  Source control
 Built an inspection process and inspected  Automated build
it  Automated unit test
 What does the data say?  Scheduled build and unit test
 Worked with change management tools
5
03/03/2021

 Fixing Defects  Refactoring
 Defects as  Is your software’s evolution:
opportunities  A planned-for opportunity that is improving
 Tips for finding the internal quality of the software?
defects  A haphazard activity that is continually
degrading the product’s quality?
 Tips for fixing defects
 Refactoring does NOT change the
 Finding defects
software’s functionality
versus preventing
defects  Complete one refactoring at a time
 Worked with change  Worked with change management tools
management tools

 Analyzing and Estimating  Testing and Quality
Requirements  Is quality an accident?
 Managing change to traditional  Who owns quality?
requirements  Characteristics of software quality
 Managing change to agile requirements  Quality approaches
 Worked with change management tools  Find defects
 Change estimation  Prevent defects
 Do Both
 Testing approaches
 Unit
 Integration
 Acceptance
 System
Is Quality an Accident? - 10 Summary

 Customer Satisfaction  Your decisions and behavior every day
 What is Customer define who you are as:
Satisfaction?  An individual on a team
 Kano Model  A team leader
 What if there are  A team
problems?  It is up to you to use quality processes,
or not
 It is up to you whether the product you
are working on, or the project’s
infrastructure, incurs too much technical
debt
© 2009, Martin R.
© 2017, Tran Kim Sanh 35 Radley 36
Referenced from Prof.Redley of CMU Referenced from Prof.Redley of CMU
6
03/03/2021

 https://www.youtube.com/watch?v=y  Ian Sommerville. Software engineering update 10th
KBfRzhIofs
edition. Wesley Computer Publishing 2018 Page: 730 -
 https://www.youtube.com/watch?v=ce 749
73O3pkgbU

Group discussion?
 Teamwork presentation

ADP Slide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADP Slide

Uploaded by

Copyright:

Available Formats

Application Development

© 2019, Tran Kim Sanh

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 2

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 3

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 4

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 5

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 7

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 8

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 9

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 10

Larson and LaFasto, Teamwork

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 11

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 12

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 13

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 14

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 15

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 16

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 17

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 18

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 19

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 20

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 21

 Standards make a difference

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 23

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 24

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 26

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 27

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 28

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 29

It helps us know how others perceive us

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 30

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 31

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 32

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 33

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 34

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 35

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 36

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 37

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 38

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 39

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 40

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 41

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 42

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 43

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 44

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 45

What does your behavior say about you?

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 46

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 47

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 48

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 49

© 2019, Tran Kim Sanh 1

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 2

Previous lesson question

 What is “A results-driven structure”

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 3

Previous lesson question

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 4

Previous lesson question

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 5

Previous lesson question

Referenced from Prof.Redley of CMU © 2019, Tran Kim Sanh 6

Why Process is Important