MES3053 Software Testing and Quality

CHAPTER 2
The Software Development
Process
 Objectives

Product Components
Software Project Staff
Software Development Life Cycle
 Topics covered

What major components go into a

software product.
What different people and skills contribute
to a software product.
How software progresses from an idea to
a final product.
What Effort Goes Into a Software Product

Product Specification
Product Reviews
Design Documents
Schedules
Feedback from previous versions
Competitive Information
Test Plans Final Product
Customer Surveys
Usability Data
Look and Feel Specifications
Software Architecture
Software Code
What Effort Goes Into a Software Product?

Customer Requirements
Software is written to full fill some need that a person or
a group of people has.
Specifications
Result of the Customer requirements just raw data.
Specifications take all this information and define:
What the product will be?
What it will do?
How it will look?
 What Effort Goes Into a Software
Product?
Format of specifications :
Checks and Balances
Result is an extremely detailed and through
specification thats lock down.(It cant change
except under very extreme conditions).
What the product finally becomes isnt known
until its release.
What Effort Goes Into a Software Product?

Schedules
As a project grows in size and complexity, with many
pieces and many people contributing to the product, it
become necessary to have some mechanism to track its
progress.
Range from simple task lists to Gantt charts to detailed
tracking of every minute task with PM Software.
Goal for scheduling are to know which work has been
completed, how much work is still left to do , and when it
all be finished.
 What Effort Goes Into a Software
Product?
Software Design Documents
One common misconception is that when
programmer creates a program, he simply sits
down and starts writing code.
Large skills software there must be a design
process to plan out how the software will be
written.
Purpose is to plan and organize the code that is to
be written.
 What Effort Goes Into a Software
Product?
List of Software design documents:
Architecture
Describes the overall design of the software, Including
descriptions of all major pieces and how they interact
with each other.
Data Flow Diagram
A formalized diagram that shows how data moves
through a program. Sometimes referred to as bubble
chart.(Drawn by using circle s and lines)
 What Effort Goes Into a Software
Product?
List of Software design documents:
State Transition Diagram
Formalized diagram that breaks the software into basic states, or
conditions and shows the means for moving from one state to
another state.
Flow Chart
Pictorially describing a programs logic.
Commented Code
Properly embedding useful comments in the software code itself is
extremely important, so that programmers assigned to maintain
the code can more easily figure out what it does and how.
 What Effort Goes Into a Software
Product?
Test Documents
Programmers must plan and document their work,
software testers must as well.
Heres list of the important test deliverables:
Test plan describes the overall method to be used to verify the
software meets the product specifications and the customers
needs. It Includes:
Quality Objectives
Resource needs
Schedules
Assignments
Methods
 What Effort Goes Into a Software
Product?
Test Documents
Test Case
List of the specific items that will be tested and describe the detailed
steps that will be followed to verify the software.
Bug reports
Describe the problems found as the test cases are followed.These
could be done on paper but are often done in database.
Test tools and automation-Automated Testing and Test
Tools.If your team is using automated to test your software,
the tools you use, either purchased or written in-house ,
must be documented.
Metrics, statistics, and summaries convey the progress being
made as the test work progresses.They take the form of
graphs, charts, and written reports.
 What Parts Make Up a Software
Product
Help File
Samples and examples
Product support info
Error messages
Setup and installation
Users manual
Labels and stickers
Icons and art
Ads and marketing material
Readme file
 Software Project Staff

Project managers, program managers, or producers

drive the project from the beginning to end.
Responsible for writing the product spec, managing the
schedule, and making the critical decisions and trade off.
Architects or system engineers. Work very closely to
the programmers.
Programmers, developers ,coders design and write
software and fix the bugs there are found.
Testers or QA Staff are responsible for finding and
reporting problems in the software product.
 Software Project Staff

Technical writers, user assistance, user education,

manual writers, or illustrator create the paper and
online documentation that comes with a software
product.
Configuration management or builder handles the
process of pulling together all the software written by
the programmers and all the documentation created
by the writers and putting it together into a single
package.
 Software Development Lifecycle
Models

4 frequently used models:

Big-Bang
Codeand-Fix
Waterfall
Spiral
 Big-Bang Model

Assumes that all components are first tested individually

and then tested together as a single system.
- Advantage: no additional test stubs or drivers are
needed.
- Disadvantage: although it sounds simple, it can be very
expensive, because if a test uncovers a failure, it is
difficult to pinpoint the specific component (or
combination of components) responsible for the failure.
In addition, it is impossible to distinguish failures in the
interface from failures within a component.
Code-and-fix
 Waterfall Model

Definition
The waterfall model is a software development model
(a process for the creation of software) in which
development is seen as flowing steadily downwards (like
a waterfall) through the phases of requirements analysis,
design, implementation, testing (validation), integration,
and maintenance
Spiral Model
 Spiral Model

Spiral involves six steps:

Determine objectives, alternatives, and constrains.
Identify and resolve risks
Evaluate alternatives
Develop and test the current level
Plan the next level
Decide on the approach for the next level.