CH Two Software Process Model

Download as pdf or txt
Download as pdf or txt
You are on page 1of 52

CHAPTER-TWO

Software Processes Model


software process
A software process is a set of related activities that leads to the
production of a software product
 Four basic activities of any software process
o Software specification
o Software design and implementation
o Software testing
o Software evolution

Cont’d

Software specification
Define a set of services required from the system
Identify constraints on the systems operation and development
Four basic activities of a software specification
oFeasibility study(achievable? Cost effective?)
oRequirements gathering(through observation and discussion)
oRequirement specification
oRequirement validation( checks the requirements for consistency, and
completeness)
Cont’d

Software design and implementation


The process of converting the system specification into an
executable system
The software to meet the specification must be produced.
Design : describing structure of the system to be
implemented
Implementation: converting the design in to executable
code
Cont’d

Major activities of design process


oArchitectural design
*Identify overall structure of the system: principal components (sub systems )
and their relationships
oComponent design :
*designing each principal component
oInterface design :
*define the interface between system components
*This interface specification must be unambiguous.
oDatabase design
*Design a database that stores data of the system
 Software testing
❖ Intended to show if the system meets expectation of the
customer
❖ Three stages in testing process
oDevelopment testing(Component or unit testing)
*Each component is tested independently(the components can be classes
or functions or other group of entities)
*Test automation tools are used
oSystem testing
*System components are integrated to create a complete system
*The whole system will be tested to find errors due to interaction
*It is also concerned with showing that the system meets its functional and
non-functional requirements
oAcceptance testing
*The system is tested with a real data in the real environment(not simulated
test data)
Software evolution
 The software must evolve to meet changing customer needs
❖ Checking for flexibility
❖ Is making changes to the software after it is developed once
possible
❖ This is needed to satisfy new requirements
Ad hoc Software Development

 Developing software without planning for each phase, and without specifying
tasks, deliverables, or time constraints.

 Relies entirely on the skills and experience of the individuals performing the work.

 The software process may change as work progresses.


How can we overcome problems with ad hoc
software development?
 Problems: (include but not limited to)
 Difficult to distinguish between tasks → important tasks may be ignored.
 Inconsistent schedules, budgets, functionality and product quality.
 Delayed problem discovery → more costly to fix.

Solution? Software Process Model


“an abstract representation of a process. It presents a description of a
process from some particular perspective.”

Software Process Models provide guidelines to organize how


software process activities should be performed and in what
order.
Software process models

General process models


oWaterfall
oEvolutionary
oComponent-Based Models CBSE
oIterative Models
oRational unified process
1)Waterfall process model

The first published model of the software development process


The waterfall model is an example of a plan-driven process
Known as linear sequential model
Principle
oyou must plan and schedule all of the process activities
before starting work on them
o software development is split up into a number of independent
activities
o These activities are carried out in sequence one after the other.
o Each stage produces a product which is the input to the next
stage
Cont’d
Cont’d

Requirements Analysis and Definition


The system's services, constraints and goals are established
by consultation with system users. They are then defined in
a manner that is understandable by both users and
development staff.
This phase can be divided into:
• Feasibility study (often carried out separately)
• Requirements analysis
• Requirements definition
• Requirements specification
Cont’d

System and Software Design


 System design: Partition the requirements to hardware or software
systems. Establishes an overall system architecture
 Software design: Represent the software system functions in a form
that can be transformed into one or more executable programs
Implementation and Unit Testing
• The software design is realized as a set of programs or program units.
(Written specifically, acquired from elsewhere, or modified.)
• Individual components are tested against specifications.
Integration and System Testing
 The individual program units are:
• integrated and tested as a complete system
• tested against the requirements as specified
• delivered to the client
Operation and maintenance

Operation: The system is put into practical use.


Maintenance: Errors and problems are identified and
fixed.
 Evolution: The system evolves over time as requirements
change, to add new functions or adapt the
technical environment.
Advantages

Simple to implement and mange


Enforces a disciplined software development approach
Waterfall model problems

 Inflexible partitioning of the project into distinct stages makes it


difficult to respond to changing customer requirements.
 Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the design
process.
 Few business systems have stable requirements.
 The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.
Cont’d

It takes too long to see results: nothing is executable or


demonstrable until code is produced.
It depends on stable, correct requirements.
It delays the detection of errors until the end.
It does not promote software reuse.
It does not promote prototyping.
2)Evolutionary Models
Prototyping Model
1/4 1. Requirements gathering.

Listen to 2. Design and build SW prototype.


Customer 3. Evaluate prototype with customer.
4. Refine requirements.

3 2
Customer Build /
Test-Drives Revise
prototypes prototypes
Paper prototyping
Why prototyping?
oGet user feedback early
* Use it to focus the development process
oSave time and money
* Solve key problems before implementation begins
oCommunicate better
* Involve development team members from a variety of disciplines
oBe more creative
* Experiment with many ideas before committing to one
Paper prototyping
Sketches of the interfaces
Limited in details
o Limited color
o Limited graphics
o Limited content
How to create a paper prototype?
o By hand drawing
o Cutting/pasting/glueing/…
o Changes are made easily
* All you need is a pencil and an eraser
3)Component-Based Models CBSE

Requirements Component Requirements System design


specification analysis modification with reuse

Development System
and integration validation

 Systematic reuse: Integrated from existing components or COTS


(Commercial-Off-The-Shelf) systems.

 This approach is becoming increasingly used as component


standards have emerged.
Types of software components:

 Web services that are developed according to service standards and which
are available for remote invocation.
 Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
 Stand-alone software systems (COTS) that are configured for use in a
particular environment.
4) Iterative Models
Incremental development model

principle
oDevelop initial implementation of the software
oGive it to the user for comment
oImprove it through several versions
 Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback across
activities.
Cont’d

 Specification, development, and validation activities are interleaved rather than


separate, with rapid feedback across activities.
Cont’d

customers identify which of the services are most important


and which are least important to them
The allocation of services to increments depends on the
service priority, with the highest-priority services
implemented and delivered first
Customer value can be delivered with each increment so
system functionality is available earlier.
Early increments act as a prototype to help elicit
requirements for later increments.
Advantages

Customers can use the early increments as prototypes and


gain experience that informs their requirements for later
system increments
Customers do not have to wait until the entire system is
delivered before they can gain value from it
The first increment satisfies their most critical requirements
so they can use the software immediately
Cont’d

The process maintains the benefits of incremental


development in that it should be relatively easy to
incorporate changes into the system
the most important system services receive the most testing
customers are less likely to encounter software failures in
the most important parts of the system.
Cont’d

Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may be
required.
 hard to identify common facilities that are needed by all increments.
 Iterative development can also be difficult when a replacement system
is being developed
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
Spiral development

A risk-driven software process framework proposed by Boehm in 1988


Process is represented as a spiral rather than as a sequence of
activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral
are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.
Cont’d
Spiral model sectors

Each loop in the spiral is split into four sectors


Objective setting
Specific objectives for the phase are identified.
Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key risks.
Development and validation
A development model for the system is chosen which can be any of the
generic models.
Planning
The project is reviewed and the next phase of the spiral is planned.
Advantages:

➢ Its spiral structure gives stakeholders a lot of points for review and
making “go” or “no-go” decisions.
➢ It emphasizes risk analysis. If you identify and resolve risks correctly, it
should lead to eventual success.
➢ It can accommodate change reasonably well. Simply make any
necessary changes and then run through a cycle to identify and resolve
any risks they create.
➢ Estimates such as time and effort required become more accurate over
time as cycles are finished and risks are removed from the project.
Disadvantages:
➢ It’s complicated.
➢ Because it’s complicated, it often requires more resources than simpler
approaches.
➢ Risk analysis can be difficult.
➢ The complication isn’t always worth the effort, particularly for low‐risk
projects.
➢ Stakeholders must have the time and skills needed to review the project
periodically to make sure each cycle is completed satisfactorily.
➢ Time and effort estimates become more accurate as cycles are finished, but
initially those estimates may not be good.
➢ It doesn’t work well with small projects. You could end up spending more
time on risk analysis than you’d need to build the entire application with a
simpler approach.
Rational Unified Process(RUP)

The software development process is divided in to 4 phases


A modern process model derived from the work on the
UML and associated process.
Cont’d

Inception
o Scope of the project is defined :
* What needs to be included? And what needs not?
o Build a business case
* Is it cost effective?
o Obtaining stakeholder agreement
* Are the clients happy? Will they be committed with the project?
Elaboration
o Detail list of complete requirements is prepared
o General architecture of the system will be designed
o Possible risks of the project are assessed
o Project plan is prepared (schedule,…)
Construction :
odeals with the actual construction of the SW
*design
*programming
*Testing
oWorking SW is produced
Transition :
oMoving the SW from development community to user
community
oMaking the software to work on the real environment
oComplete user manual is also prepared
RUP good practice

Develop software iteratively


Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
Rapid Application Dev’t Models(RAD)

RAD methods take iterative ideas to the extreme.


 Instead of using iterations lasting a year or two, their
iterations last a month, a week, or even less. Some RAD
techniques also apply iteration to everything, not just to
programming.
 They apply iteration to requirement gathering,
requirement validation, and design.
Common Techniques used in RAD
➢ Small teams (approximately one‐half a dozen people or
fewer). That leads to projects of limited scope. (Six people
probably can’t write a million‐line application in a year.)
➢ Requirement gathering through focus groups, workshops,
facilitated meetings, prototyping, and brainstorming.
➢ Requirement validation through iterated prototypes, use
cases, and constant customer testing of designs.
➢ Repeated customer testing of designs as they evolve.
➢ Constant integration and testing of new code into the
application.
Cont’d

➢ Informal reviews and communication among team members.


➢ Short iterations lasting between a few months and as little as a week.
➢ Deferring complicated features for later releases.
➢ Time boxing, which is RAD speak for setting a tight delivery schedule

for producing something, usually the next iteration of the application.


Advantages:
➢ More accurate requirements.
➢ The ability to track changing requirements.
➢ Frequent customer feedback and involvement.
➢ Reduced development time.
➢ Encourages code reuse.
➢ Possible early releases with limited functionality
➢ Constant testing promotes high‐quality code and eases integration
issues.
➢ Risk mitigation.
➢ Greater chance of success.
Disadvantages:

➢ Resistance to change.
➢ Doesn’t handle large systems well.
➢ Requires more skilled team members.
➢ Requires access to scarce resources.
➢ Adds extra overhead if the requirements are known completely and correctly in
advance.
➢ Less managerial control.
➢ Sometimes results in a less than optimal design..
➢ Unpredictability.
Four Phases of RAD:
 Requirements planning—
o During this phase, the users, executive champion, management,
team leaders, and other stakeholders agree on the project’s
general goals and requirements.
o The requirements should be specified in a general way so that
they don’t restrict later development unnecessarily.
o When the stakeholders agree on the requirements and the
project receives approval to continue, the user design phase
begins.
 User design—
o The users and team members work together to convert the
requirements into a workable design.
o They use techniques such as focus groups, workshops,
prototyping, and brainstorming to come up with a workable
design.
Cont’d

 Construction—The developers go to work building the application.


The users continue to review the pieces of the application as the
developers build them to make corrections and suggestions for
improvements.
 Cutover—The developers deliver the finished application to the users.
(You can use the usual cutover strategies such as staged delivery,
gradual cutover, or incremental deployment.).
Note: The user design and construction phases overlap with
the users constantly providing adjustments to the developers
in a sort of continuous feedback loop. The project iterates
the user design and construction phases as needed. When
the application has met all the requirements, it is delivered
to the users

You might also like