Characteristics of a good process

Process should be precisely defined.

The step must be predictable.
Predictable process should be under statistical
control.
Process should support testing and
maintainability.
SDLC
(Software development life cycle)
Problem definition
Feasibility study
Analysis
System Design
Detailed design
Implementation
Maintenance
Problem Definition
This phase establish problem and define
problem
To answer:
What is the problem
Who faced the problem
Where in the organization
Idea:
Meet user and management and obtain a
solution to their problem
If problem exist it need to be solved and
becomes a project
After this funds and resources are applied


Problem definition Document
Project Title
Problem statement
Objective of project
Possible solutions
Project Scope
Indicate time and cost for feasibility step
Feasibility study
Types of feasibility:-
1. Economical
2. Technical
3. Operational
Feasibility study report
1. Introduction
-state problem
-user environment
-kind of solution you are preparing
-kinds of constraints on the project( cost,
time, etc)
2. Recommendations
3. Alternativesfor final approach
4. System description
5. Cost benefit analysis
6. Evaluation of technical risk
7. Legal Ramification
Waterfall Model
Produces many intermediate deliverable
usually documents- which acts as a baseline
Important for quality assurance and project
management
Widely used when requirement are well
understood

System Engineering
Coding
Design
Analysis and Gathering
Testing
Deployment
Maintenance
System engineering
Understand overall context of problem
Identify the responsibilities to be make

Analysis
Problem domain is analyzed in more detail.
Understand:-
1. What kind of information is involved
2. What kind of data is involved
3. What functions need to be performed
4. What are the performance and interfacing
requirements
5. Purpose is to clearly defined the requirement
which are to be met
6. Also carry out project planning as
part of same step
Purpose is to identify:
1. What are the different steps
2. What are different deliverables
3. What would be the timeframe
4. What would be the resources allocated

Design
Requirements are translated to
1. software architecture
2. Prepare database design

Design is divided into two parts:
1. High level design
2. Low level design or detailed design
Coding

Testing
1. Unit testing
2. Integration testing
3. System testing
Deployment of software
Implemented and Released
User will take control and start using software

Ongoing Maintenance
If errors encountered necessary changes need
to be made
Performance requirement need to review.
Deliverables in waterfall model
1. Project Plan and feasibility report
2. SRS(Software requirement specification) or
requirement document
3. Design document:
- System design document
- Detailed design document
4. Test Plans and Test Reports

5. Source code
6.Software manuals (user manual, Installation
Manual)
7. Review Reports (catalog how development
went through)
When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product

Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost
or schedule




Shortcomings in waterfall model
1. Requirement may not be completely known
2. Requirement changes with time
3. Heavy Documentation
V-Shaped SDLC Model
A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development

V-Shaped Steps
Project and Requirements Planning
allocate resources

Product Requirements and
Specification Analysis complete
specification of the software system

Architecture or High-Level Design
defines how software functions fulfill
the design

Detailed Design develop algorithms
for each architectural component


Production, operation and
maintenance provide for
enhancement and corrections
System and acceptance testing
check the entire software system in
its environment


Integration and Testing check that
modules interconnect correctly

Unit testing check that each
module acts as expected

Coding transform algorithms into
software

V-Shaped Strengths
Emphasize planning for verification and
validation of the product in early stages of
product development
Each deliverable must be testable
Project management can track progress by
milestones
Easy to use
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in
requirements
Does not contain risk analysis activities
When to use the V-Shaped Model
Excellent choice for systems requiring high
reliability hospital patient control
applications
All requirements are known up-front
When it can be modified to handle changing
requirements beyond analysis phase
Solution and technology are known

Structured Evolutionary Prototyping Model
Developers build a prototype during the
requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code
is brought up to the standards needed for a
final product.

Evolutionary Delivery
Rapid Development, Taming Wild Software Schedules, by Steven McConnell, Press 1996
Structured Evolutionary Prototyping Steps
A preliminary project plan is developed
An partial high-level paper model is created
The model is source for a partial requirements specification
A prototype is built with basic and critical attributes
The designer builds
the database
user interface
algorithmic functions
The designer demonstrates the prototype, the user evaluates
for problems and suggests improvements.
This loop continues until the user is satisfied

When to use
Structured Evolutionary Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a waterfall
model
Develop user interfaces
Short-lived demonstrations
New, original development



Limitations
1. Customer may want prototype itself
(not maintainable, bad performance)
2. Developers may continue with
implementation choices(bad quality
performance)
3. Good tools are required for quick
development
4. May increase project cost


Incremental SDLC Model
Construct a partial
implementation of a total system
Then slowly add increased
functionality
The incremental model prioritizes
requirements of the system and
then implements them in groups.
Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has been
implemented.


Incremental Model Strengths
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses divide and conquer breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

Incremental Model Weaknesses
Requires good planning and design
Requires early definition of a complete and
fully functional system to allow for the
definition of increments
Well-defined module interfaces are required
(some will be developed long before others)
Total cost of the complete system is not lower

When to use the Incremental Model
Risk, funding, schedule, program complexity, or need
for early realization of benefits.
Most of the requirements are known up-front but
are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development
schedules
On a project with new technology