Unit3 software review control software

1
Project Monitoring and Control
Software Reviews

Software Reviews
• Introduction
• Types of reviews according to formality
– Desk check
– Peer reviews
– Walkthroughs
– Inspections
– Audits
• Checklists
• Reporting and follow-up
• Other static software analysis techniques

Reviews and testing (Why reviews?)
• A software system is more than the code; it is a set of related
artifacts; these may contain defects or problem areas that should be
reworked or removed; quality-related attributes of these artifacts
should be evaluated
• Reviews allow us to detect and eliminate errors/defects early in the
software life cycle (even before any code is available for testing),
where they are less costly to repair
• Most problems have their origin in requirements and design;
requirements and design artifacts can be reviewed but not executed
and tested
• A code review usually reveals directly the location of a bug, while
testing requires a debugging step to locate the origin of a bug
• Adherence to coding standards cannot be checked by testing

http://www.stellman-greene.com 4
When are reviews needed?
• A review is any activity in which a work product is
distributed to reviewers who examine it and give
feedback.
– Reviews are useful not only for finding and eliminating
defects, but also for gaining consensus among the project
team, securing approval from stakeholders, and aiding in
professional development for team members.
– Reviews help teams find defects soon after they are injected
making them cost less to fix than they would cost if they were
found in test.
– All work products in a software project should be either
reviewed or tested.
• Software requirements specifications, schedules, design
documents, code, test plans, test cases, and defect reports
should all be reviewed.

Technical and management reviews
• Technical Reviews - examine work products of the software
project (code, requirement specifications, software design
documents, test documentation, user documentation,
installation procedures) for V&V and QA purposes
– Multiple forms: Desk checking, Walkthroughs, Inspections, Peer
Reviews, Audits
( Will be discussed as part of the syllabus)
• Management Reviews - determine adequacy of and monitor
progress or inconsistencies against plans and schedules and
requirements
– Includes what Ian Somerville calls Progress Reviews
– May be exercised on plans and reports of many types (risk
management plans, project management plans, software
configuration management plans, audit reports, progress reports,
V&V reports, etc.)

Components of a review plan
• Review goals
• Items being reviewed
• Preconditions for the review
• Roles, team size, participants
• Training requirements
• Review steps and procedures
• Checklists and other related documents to be
distributed to participants
• Time requirements
• Nature of the review log and summary report
• Rework and follow-up
(Source: I. Bursntein)

Desk check
• Also called self check
• Informal review performed by the author of
the artifact

Types of Review: Deskchecks
• A deskcheck is a simple review in which the
author of a work product distributes it to
one or more reviewers.
– The author sends a copy of the work product to
selected project team members. The team
members read it, and then write up defects and
comments to send back to the author.

Types of Review: Deskchecks
• Unlike an inspection, a deskcheck does not
produce written logs which can be archived with
the document for later reference.
• Deskchecks can be used as predecessors to
inspections.
– In many cases, having an author of a work product pass
his work to a peer for an informal review will
significantly reduce the amount of effort involved in the
inspection.

Peer reviews
• “I show you mine and you show me yours”
• The author of the reviewed item does not
participate in the review
• Effective technique that can be applied when there
is a team (with two or more persons) for each role
(analyst, designer, programmer, technical writer,
etc.)
• The peer may be a senior colleague (senior/chief
analyst, senior/chief architect, senior/chief
programmer, senior/chief technical writer, etc.)

Walkthroughs
• Type of technical review where the producer of
the reviewed material serves as the review leader
and actually guides the progression of the review
(as a review reader)
• Traditionally applied to design and code
• In the case of code walkthrough, test inputs may
be selected and review participants then literally
walk through the design or code
• Checklist and preparation steps may be eliminated

Inspections
• 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 development standards, and other problems
• Inspections are moderated meetings in which reviewers list
all issues and defects they have found in the document and
log them so that they can be addressed by the author.
• The goal of the inspection is to repair all of the defects so
that everyone on the inspection team can approve the work
product.
– Commonly inspected work products include software
requirements specifications and test plans.

Inspections
• Running an inspection meeting:
1. A work product is selected for review and a team is gathered
for an inspection meeting to review the work product.
2. A moderator is chosen to moderate the meeting.
3. Each inspector prepares for the meeting by reading the work
product and noting each defect.
4. In an inspection, a defect is any part of the work product that
will keep an inspector from approving it.
5. Discussion is focused on each defect, and coming up with a
specific resolution.
• It’s the job of the inspection team to do more than just identify the
problems; they must also come up with the solutions.
6. The moderator compiles all of the defect resolutions into an
inspection log

Inspection Log Example

Code Review
• A code review is a special kind of inspection in
which the team examines a sample of code and
fixes any defects in it.
– In a code review, a defect is a block of code which
does not properly implement its requirements, which
does not function as the programmer intended, or
which is not incorrect but could be improved
• For example, it could be made more readable or its
performance could be improved

Code Review
– It’s important to review the code which is most likely
to have defects. This will generally be the most
complex, tricky or involved code.
– Good candidates for code review include:
• A portion of the software that only one person has the
expertise to maintain
• Code that implements a highly abstract or tricky algorithm
• An object, library or API that is particularly difficult to
work with
• Code written by someone who is inexperienced or has not
written that kind of code before, or written in an unfamiliar
language
• Code which employs a new programming technique
• An area of the code that will be especially catastrophic if
there are defects

A sample general checklist for reviewing software documents
• Coverage and completeness
– Are all essential items completed?
– Have all irrelevant items been omitted?
– Is the technical level of each topic addressed properly for this document?
– Is there a clear statement of goals for this document?
(Don't forget: more documentation does not mean better documentation)
• Correctness
– Are there incorrect items?
– Are there any contradictions?
– Are there any ambiguities?
• Clarity and Consistency
– Are the material and statements in the document clear?
– Are the examples clear, useful, relevant and correct?
Contd/-
(Adapted from Ilene Burnstein, Practical Software Testing, page 327)

Sample general checklist (cont.)
 Clarity and Consistency (cont.)
• Are the diagrams, graphs and illustrations clear, correct, use the proper
notation, effective, in the proper place?
• Is the terminology clear and correct?
• Is there a glossary of technical terms that is complete and correct?
• Is the writing style clear (nonambiguous)?
 References and Aids to Document Comprehension
• Is there an abstract or introduction?
• Is there a well placed table of contents?
• Are the topics or items broken down in a manner that is easy to follow
and is understandable?
• Is there a bibliography that is clear, complete and correct?
• Is there an index that is clear, complete and correct?
• Is the page and figure numbering correct and consistent?
(Adapted from Ilene Burnstein, Practical Software Testing, page 327)

A sample specification (or requirements) attributes checklist
Attribute What to consider
Complete
Is anything missing or forgotten? Is it thorough? Does it include everything
necessary to make it stand alone?
Accurate
Is the proposed solution correct? Does it properly define the goal? Are there any
errors?
Precise,
Unambiguous
and Clear
Is the description exact and not vague? Is there a single interpretation? Is it easy
to read and understandable?
Consistent
Is the description of the feature written so that it doesn't conflict with itself or
other items in the specification?
Relevant
Is the statement necessary to specify the feature? Is there extra information
that should be left out? Is the feature traceable to an original customer need?
Feasible
Can the feature be implemented with the available personnel, tools, and
resources within the specified budget and schedule?
Code-free
Does the specification stick with defining the product and not the underlying
software design, architecture, and code?
Testable
Can the feature be tested? Is enough information provided that a tester could
create tests to verify its operation?
(Adapted from: Ron Patton, Software Testing)

A sample supplementary checklist for design reviews
(for high-level architectural design and detailed design)
• Are the high-level and detailed design consistent with requirements?
Do they address all the functional and quality requirements? Is
detailed design consistent with high-level design?
• Are design decisions properly highlighted and justified and traced
back to requirements? Are design alternatives identified and
evaluated?
• Are design notations (ex: UML), methods (ex: OOD, ATAM) and
standards chosen and used adequately?
• Are naming conventions being followed appropriately?
• Is the system structuring (partitioning into sub-systems, modules,
layers, etc.) well defined and explained? Are the responsibilities of
each module and the relationships between modules well defined and
explained? Do modules exhibit strong cohesion and weak coupling?
Contd/-
(Adapted from: Ilene Burnstein, page 328-329)

A sample supplementary checklist for design reviews
(for high-level architectural design and detailed design)
Cont.
• Is there a clear and rigorous description of each module interface,
both at the syntactic and semantic level? Are dependencies
identified?
• Have user interface design issues, including standardization, been
addressed properly?
• Is there a clear description of the interfaces between this system and
other software and hardware systems?
• Have reuse issues been properly addressed, namely the possible reuse
of COTS (commercial off the shelf) components (buy-or-build
decision) and in-house reusable components?
• Is the system designed so that it can be tested at various levels (unit,
integration and system)?
(Adapted from: Ilene Burnstein, page 328-329)

A sample general code review checklist (1)
• Design Issues
– Does each unit implement a single function?
– Are there instances where the unit should he partitioned?
– Is code consistent with detailed design?
– Does the code cover detailed design?
• Data Items
– Is there an input validity check?
– Arrays-check array dimensions, boundaries, indices.
– Variables - are they all defined, initiated? have correct types and scopes been checked?
– Are all variables used?
• Computations
– Are there computations using variables with inconsistent data types?
– Are there mixed-mode computations?
– Is the target value of an assignment smaller than the right-hand expression?
– Is over- or underflow a possibility (division by zero)?
– Are there invalid uses of integers or floating point arithmetic?
– Are there comparisons between floating point numbers?
– Are there assumptions about the evaluation order in Boolean expressions?
– Are the comparison operators correct?

• Control Flow Issues
– Will the program, module or, unit eventually terminate?
– Is there a possibility of an infinite loop, a loop with a premature exit, a loop that never
executes?
• Interface Issues
– Do the number and attributes of the parameters used by a caller match those of the called
routine? Is the order of parameters also correct and consistent in caller and callee?
– Does a function or procedure alter a parameter that is only meant as an input parameter?
– If there are global variables, do they have corresponding definitions and attributes in all
the modules that use them?
• Input/output Issues
– Have all files been opened for use?
– Are all files properly closed at termination?
– If files are declared are their attributes correct?
– Are EOF or I/O errors conditions handed correctly?
– Is I/O buffer size and record size compatible?

• Portability Issues
– Is there an assumed character set, and integer or floating point representation?
– Are their service calls that mar need to be modified?
• Error Messages
– Have all warnings and informational messages been checked and used
appropriately?
• Comments/Code Documentation
– Has the code been properly documented? Are there global, procedure, and line
comments where appropriate?
– Is the documentation clear, and correct, and does it support understanding?
• Code Layout and White Space
– Has white space and indentation been used to support understanding of code
logic and code intent?
• Maintenance
– Does each module have a single exit point?
– Are the modules easy to change (low coupling and high cohesion)?
(Adapted from: Ilene Burnstein, page 331)

A sample code review checklist for C programs (1)
• Data Items
– Are all variables lowercase?
– Are all variables initialized?
– Are variable names consistent, and do they reflect usage?
– Are all declarations documented (except for those that are very
simple to understand)?
– Is each name used for a singe function (except for loop variable
names)?
– Is the scope of the variable as intended?
• Constants
– Are all constants in uppercase?
– Are all constants defined with a "#define"?
– Are all constants used in multiple files defined in an INCLUDE
header file?
• Pointers
– Are pointers declared properly as pointers?
– Are the pointers initialized properly?

A sample code review checklist for C programs (2)
• Control
– Are if/then, else, and switch statements used clearly and properly?
• Strings
– Strings should have proper pointers.
– Strings should end with a NULL.
• Brackets
– All curly brackets should have appropriate indentations and be matched
• Logic Operators
– Do all initializations use an " = " and not an " = ="?
– Check to see that all logic operators are correct, for example, use of = / =
=, and ||
• Computations
– Are parentheses used in complex expressions and are they used properly
for specifying precedences?
– Are shifts used properly?
(Adapted from: Ilene Burnstein, page. 331)

A sample (end-user) documentation review checklist
What to
Check
What to Consider
General Areas
Audience Does the documentation speak to the correct level of audience, not too novice, not too advanced?
Terminology Is the terminology proper for the audience? Are the terms used consistently? If acronyms or abbreviations
are used, are they standard ones or do they need to be defined? Make sure that your company's acronyms
don't accidentally make it through. Are all the terms indexed and cross-referenced correctly?
Content and
subject
matter
Are the appropriate topics covered? Are any topics missing? How about topics that shouldn't be included,
such as a feature that was cut from the product and no one told the manual writer. Is the material covered
in the proper depth?
Correctness
Just the facts Is all the information factually and technically correct? Look for mistakes caused by the writers working
from outdated specs or sales people inflating the truth. Check the table of contents, the index, and
chapter references. Try the Web site URLs. Is the product support phone number correct? Try it.
Step by step Read all the text carefully and slowly. Follow the instructions exactly. Assume nothing! Resist the
temptation to fill in missing steps; your customers won't know what's missing. Compare your results to the
ones shown in the documentation.
Figures and
screen
captures
Check figures for accuracy and precision. Are they of the correct image and is the image correct? Make
sure that any screen captures aren't from prerelease software that has since changed. Are the figure
captions correct?
Samples and
examples
Load and use every sample just as a customer would. If it's code, type or copy it in and run it. There's
nothing more embarrassing than samples that don 't work-and it happens all the time!
Spelling and
grammar
In an ideal world, these types of bugs wouldn't mate it through to you. Spelling and grammar checkers are
too commonplace not to be used. It's possible, though, that someone forgot to perform the check or that a
specialized or technical term slipped through. It's also possible that the checking had to be done manually,
such as in a screen capture or a drawn figure. Don't take it for granted.
(Adapted from: Ron Patton, Software Testing, page 195)

Pair Programming
• Pair programming is a technique in which two
programmers work simultaneously at a single computer
and continuously review each others’ work.
• Although many programmers were introduced to pair
programming as a part of Extreme Programming, it is a
practice that can be valuable in any development
environment.
• Pair programming improves the organization by
ensuring that at least two programmers are able to
maintain any piece of the software.

© Williams/Kessler
2004
Research Findings to Date
• Strong anecdotal evidence from industry
– “We can produce near defect-free code in less
than half the time.”
• Empirical Study
– Pairs produced higher quality code
• 15% less defects (difference statistically significant)
– Pairs completed their tasks in about half the time
• 58% of elapsed time (difference not statistically significant)
– Most programmers reluctantly embark on pair
programming
• Pairs enjoy their work more (92%)
• Pairs feel more confident in their work products (96%)

© Williams/Kessler
2004
Transitioning by Choice - 1
• The transition to pair programming must be
voluntary!!!
• Green and Hevner (SEI Research)
– Developers are more satisfied with using software
development innovations if:
• they have increased choice in when to use that innovation.
• they have decreased process control in how to use that
innovation.
• their manager encouraged them to use the innovative
technique.
• the innovation increases the predictability of their work.

© Williams/Kessler
2004
Transitioning by Choice - 2
• Advice for Managers
– Forcing developers to do it will kill your relationship with
them
– Find a key employee that will try it and gain acceptance
from peers
– Run educational session on pair programming where the
key employee can share their experiences
– Allow employees to freely discuss:
• Who wants to try it
• How to implement, recommend slow for anxiety/risk
reduction
• Discuss whether it will be formal/informal
• Feedback mechanisms
• What would convince them pair programming is beneficial or
not? How long will it take to be convinced?

© Williams/Kessler
2004
Qualitative Observation (by doctoral student in education)
• Pairing is a far superior learning
environment
• Paired labs – students help each other
• Solo labs – students wait 10-30 minutes for
help and often sit idle (and frustrated)
during this time
• Paired students ask “good” questions
• Solo students ask “basic” questions

© Williams/Kessler
2004
Pair Programming: Summary
 Pair programming is an age-old technique
 Many are reluctant to try it; the brave souls that do
like it!
 Expected benefits
 Higher product quality
 Improved cycle time
 Increased programmer satisfaction
 Enhanced learning
 Ease staff training and transition
 Knowledge management
 Reduced product risk
 Enhanced team building
 Distributed pairing a viable alternative

Higher quality code
• Immediate reviews of all code written
• Multiple perspectives on how code should
work
• People from different areas (UI/database,
development/testing) working together – no
(incorrect) assumptions
• Each person learns from the other –
increased skills

Faster cycle time
• Less temptation/ability to get distracted on
non-work things
• Less rework due to bad assumptions
• Fewer defects slip through, so less rework
for defect repair
• Less interruption for pair
• More communication

Enhanced Trust/Teamwork
• People in pairs get to know each other
better than people working solo
• Better understanding of people’s skills
• Shared events = common ground

Knowledge Transfer
• Rotation of pairs means lots of
combinations
• Lots of combinations make knowledge
transfer exponential
• No one person is indispensible
• Fewer assumptions

Enhanced Learning
• Each member of a pair has ongoing
opportunities to learn from their partner

More Fun
• Social interactions while still accomplishing
work
• Shared events
• Studies show high numbers of people trying
pair programming prefer it

Why Pair Programming Works
• Pair Pressure
• Pair Negotiation
• Pair Courage
• Pair Reviews
• Pair Debugging
• Pair Learning
• Pair Trust

Pair Pressure
• Each member doesn’t want to let the other
down
• Improved adherence to procedures and
standards
• Motivation to get a task done in a session
while partner is available

Pair Negotiation
• Working together to get the best solution
• Distributed Cognition
• Each pair member has
– Own set of skills, abilities, outlook.
– Shared goal of accomplishing task
– Suggested means of means of goal
• Brainstorming (building on ideas of others)

Pair Courage
• Having a partner agree with a fix or a
solution adds confidence to the solution
• Two people expressing confusion are more
confident to go get the help they need

Pair Reviews
• Members of pairs are immediately
reviewing code as it is written
• Two heads better than one

Pair Debugging
• Effective debugging technique is to explain
problem to someone else
• Talking about problem in a pair can lead to
a solution becoming obvious

Pair Learning
• Apprenticeship model (beginner acquires
learning from observing expert)
• No two people are at exact same levels of
knowledge on software development
• Exposure to different approaches

Pair Trust
• See enhanced trust/teamwork slide

Problems in Pair Programming
• Unavailability of partners
• Scheduling
• Experts/Skill Imbalances
• Concentration
• Disagreements
• Overconfidence
• Rushing
• Not for everyone

Enabling Pair Programming
• Accessible workspace
• Communication
• Standards
• Knowledge of people’s specialties
• Pair rotation
• Group appraisal
• Smaller groups

Workspace accessible to both
• Display visible to both people
• Side by side, not one in front of the other
• Keyboard/mouse available to either person

Expectation of communication
• Ask to drive
• Ask questions
• Explain actions taken

Standards
• Standard tools reduce learning curve time in
pairs
• Coding standards assist in both members
following the code being written and avoid
disagreements on how to write something

Knowledge of people’s specialties
• Know who to pair with to achieve benefit in
a given situation
• If a task overlaps two areas (e.g., UI and
database) pair one person from each area

Pair Rotation
• No given pair of programmers is the right
pair for every situation
• Rotation enables knowledge transfer

Group Appraisal
• Tasks are now completed by more than one
person
• Recognizing one person generally ignores
contribution from other team members who
paired for part or all of the task

Smaller Groups
• Large groups benefit from pairing, but lose
some of the trust and knowledge transfer
effects

Roles
• Driver
– Actually types or writes down
– Explains actions taken
– Participates in brainstorming/planning
• Navigator
– Watches for tactical and strategic defects
– Questions
– Participates in brainstorming/planning

Navigator Tips
• Delay a little to let driver find and correct their
own mistakes (particularly typo-level)
• If you’re getting bored/falling asleep, ask for the
keyboard
• If the driver is getting frustrated, ask for the
keyboard
• If you couldn’t take over at any point, ask
questions or ask for the keyboard
• Use active listening
• Talk
• Ask questions

Driver Tips
• If navigator bored/falling asleep, give them the
keyboard
• If you’re tired, pass the keyboard
• If you’re frustrated with something, pass the
keyboard
• Acknowledge navigator
• Explain what & why
• Talk
• Answer questions
• Don’t just dictate – brainstorm/design together

Index
• Introduction
– Types of reviews
– Reviews along the software life cycle
– Reviews and testing
– Review planning
– Review roles, responsibilities and attendance
• Types of reviews according to formality
• Checklists
• Reporting and follow-up
• Other static software analysis techniques

Types of reviews
Requirements review
check progress
check adherence to standards
Target / Review Item
(What)
Formality
(How and
Who)
Purpose / Goals
(Why)
check conformity with specification
and fitness for purpose
Design review
Code review
User documentation review
[Proj. Man.| Config. Man.| QA | V&V | Test |..]
[plan | report] review
detect errors and problems
check quality attributes and
detect quality faults
not the focus here
not the focus here
V&V and QA

Software reviews and the extended V-model of
software development
Specify
Require
ments
Design
Code
Unit
test plan &
test cases
review/audit
Execute
unit tests
Execute
integration
tests
Execute
acceptance
tests
System/accept
ance
test plan &
test cases
review/audit
Specify/Design
Code
Unit tests
Execute
system
tests
Integration
test plan &
test cases
review/audit
Specify/Design
Code System/acceptance
tests
Specify/Design
Code Integration tests
Require
ments
review
Design
review
Code
reviews (Source: I. Burnstein, page 15)
revisi
ted

Review roles, responsibilities and attendance
(Source: I. Burnstein)
author(s)
(or moderator)
(may be the
author or an
“advocate”)

Unit3 software review control software

More Related Content

What's hot

What's hot (20)

Similar to Unit3 software review control software

Similar to Unit3 software review control software (20)

More from Reetesh Gupta

More from Reetesh Gupta (16)

Recently uploaded

Recently uploaded (20)

Unit3 software review control software