Chapter 2: Software Process

1
 The Software Process
 A structured set of activities required to develop a software
system
 Many different software processes but all involve:
Specification :defining what the system should do;
Design and implementation : defining the organization of the
system and implementing the system;
Validation : checking that it does what the customer wants;
Evolution : changing the system in response to changing
customer needs.
 A software process model is an abstract representation of a
process. It presents a description of a process from some particular
perspective.
 There is no ideal process and many organizations have developed
their own approach to software development. There are many
software processes
2
Generic software process models
1. Water fall model

Fig: Water fall model

3
 In the waterfall model, the fundamental process activity: specification,
development, validation, and evolution are represented as a separate process
phases such as requirement specification, software design, coding ,and testing,
integration and system testing, implementation and evolution.
Requirements analysis and definition
• The system services, constraint and goals are established by consultation
with the system user.
• This phase consist two activities: requirement gathering and analysis and
requirement specification.
• Collect all relevant information from the user regarding the product to be
developed.
• The user’s requirements are systematically organized into a software
requirement specification document.
4
 System and software design
• Software design phase is to transform the requirement
specification into a structure that is suitable for implementation in
some programming language
• In other word The systems design process allocates the
requirements to either hardware or software systems by establishing
an overall system architecture.
• Software design involves identifying and describing the
fundamental software system abstractions and their relationships.
• During this phase, the algorithm and flow chart for each
component of software are designed.

5
 Implementation and unit testing
• The software design is realized as a set of programs or program units.
• Each component of the design is implemented as a program module.
The end product of this phase is s set of program that has been tested
individually.
• End module is tested to determine the current functioning of the
individual module and remove error is any
• Unit testing involves verifying that each unit meets its specification.

6
 Integration and system testing
• During the integration and system testing phase, the modules are
integrated in a planned manner.
• The individual program units or programs are integrated and tested as
a complete system to ensure that the software requirements have been
met.
• The system test plan document identifies all testing related activities
that must be performed, specify the schedule of testing and allocated
required resources.
• After testing, the software system is delivered to the customer.

7
 Operation and maintenance
• The system is installed in a suitable machine environment and put into practical
use.
• After a reasonable period of time, the system is evaluated to improve its
efficiency and performance. the system is changed or modified to adopt the
changing requirement of user and organization.
Advantages of Waterfall model
• The documentation is produced at each phase and that is fit with other
engineering process models.
• Works well for smaller projects where requirements are very well understood.
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• In this model phases are processed and completed one at a time. Phases do not
overlap 8
Disadvantages of waterfall model
• Once an application is in the testing stage, it is very difficult to go
back and change something that was not well- documented or thought
upon in the concept stage.
• Not a good model for complex and object-oriented projects.
• High amounts of risk and uncertainty.
• The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.
• Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.

9
2. Incremental development

Fig: Incremental Development Model

10
 Incremental development/exploratory Development Model
 Incremental development is based on the idea of developing an initial
implementation, exposing this to user comment and evolving it through several
versions until an adequate system has been developed.
 Specification, development, and validation activities are interleaved rather than
separate, with rapid feedback across activities.
Two fundamental evolutionary development models:
Throw-away prototyping:

The prototype concentrates on experimenting with the user requirement that are
poorly understood.
 This is a valuable mechanism for gaining better understanding of costumers.
 Another reason for developing prototype is that it is impossible to get a perfect
product in the first attempt. Many researchers and engineering advice that if we
want to develop a good product. 11
Exploratory development :
The objectives of this model are to work with the customers to explore their
requirement and deliver a final system.
Advantages:
 During life cycle the software is produced early which facilitates customer
evaluation or feedback.
 Risk analysis is better, Initial operating time is less.
 Better suited for large and mission-critical projects(an online banking system,
railway/aircraft operating and control systems, electric power systems etc)
 Disadvantages:
 Management complexity is more. End of project may not be known which is a
risk. Can be costly to use.
 Highly skilled resources are required.
 The client may have the impression the first version is very close to the final
12
product and thus be less patient.
 3. Integration and configuration

 This approach is based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf) systems.
 Reused elements may be configured to adapt their behavior and functionality
to a user’s requirements
 Reuse is now the standard approach for building many types of business
system.
 Process stages include:
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration

13
14
Types of reusable software
 Stand-alone application systems (sometimes called COTS) that are
configured for use in a particular environment.
 Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
 Web services that are developed according to service standards and which
are available for remote invocation.
Advantages and disadvantages
• Reduced costs and risks as less software is developed from scratch
• Faster delivery and deployment of system
• But requirements compromises are inevitable so system may not meet
real needs of users
• Loss of control over evolution of reused system elements 15
 Process activities
The four basic process activities of specification, development, validation,
and evolution are organized differently in different development processes.
1. Software specification
 Software specification is the process of understanding and defining what
services are required from the system and identifying the constraints on the
system’s operation and development.
 The requirements engineering process aims to produce an agreed
requirements document that specifies a system satisfying stakeholder
requirements.
 The requirement documents that is the specification for the software
requirements are usually presented at two levels user requirements and
system requirements.
16
There are four main activities in the requirements engineering process:
Feasibility study
• An estimate is made of whether the identified user needs may be satisfied
using current software and hardware technologies.
• The study considers whether the proposed system will be cost-effective
from a business point of view and if it can be developed within existing
budgetary constraints.
• A feasibility study should be relatively cheap and quick.
 Requirements elicitation and analysis
• Requirements elicitation is the practice of researching and discovering the
requirements of a system from users, customers, and other stakeholders. The
practice is also sometimes referred to as "requirement gathering"

17
• This is the process of deriving the system requirements through observation of
existing systems, discussions with potential users and procurers, task analysis,
and so on.
• This may involve the development of one or more system models and
prototypes. These help you understand the system to be specified
•It may also involve a different kinds of stockholders; end-users, managers,
system engineers, test engineers, maintenance engineers, etc

 Requirement Specification
• The activity of translating the information gathered during the requirement
determination and analyze into the documents that defines the set of
requirements.
• In requirement specification, two types of requirement may be included in the
18
document: user requirement and system requirement.
 Requirements validation
• The activity checks the requirement for realism, consistency and
completeness.
• During this phase, errors in the requirement document are discovered and
modified to correct those errors.

19
2. Software Design and Implementation:
 The implementation stage of software development is the process of
converting a system specification into an executable system.
 A software design is a description of the structure of the software to
be implemented, the data models and structures used by the system, the
interfaces between system components and, sometimes, the algorithms
used.
 The design process may involve developing several models of the
software at different level of abstraction. As the design is decomposed,
errors in earlier stage are discovered.

20
Fig: general model of design process

21
 “software platform”, the environment in which the software will
execute.
The requirements specification is a description of the functionality the
software must provide and its performance and dependability
requirements.
 the description of that data may be included in the platform
specification; otherwise, the data description must be an input to the
design process
Architectural design
• where you identify the overall structure of the system, the principal
components (sometimes called sub-systems or modules), their
relationships, and how they are distributed and documented.

22
Interface design
• For each sub system its interface with other sub system is design and
documented. The interface specification must allow the sub system to be
used without knowledge of the sub system operation.
Component design
• Services are allocated to components and the interfaces of these
components are designed.
Database design
• System data structures is designed and how these are to be represented
in a database. Again, the work here depends on whether an existing
database is to be reused or a new database is to be created.

23
3. Software validation

Fig: Testing phases in a plan-driven software process

24
 System validation is the process of checking the software to ensure that
it works exactly according to the requirement specification.
 During software validation process, the software is tested with different
types of users on actual working data.
 The majority of validation costs are incurred after implementation,
when the operational system is tested. System should not be tested as a
single unit. It should be performed in different stage.
Component or unit test
• Individual components are tested to ensure that they operate correctly.
Each component is tested independently without other system
component.
• Components may be simple entities such as functions, object, and
25
classes or may be coherent grouping of these entities.
System testing
• The components are integrated to make up the system. This process is
concerned with finding errors between two components and interface.
• It is also concerned with showing that the system meets its functional and
non-functional requirements, and testing the emergent system properties.
• For large systems, this may be a multi-stage process where components are
integrated to form subsystems that are individually tested before these sub-
systems are themselves integrated to form the final system.
Acceptance testing
• This is the final stage in the testing process before the system is accepted for
operational use. The system is tested with data supplied by the system
customer rather than with simulated test data.

26
• Acceptance testing is sometimes called ‘alpha testing’. Custom
systems are developed for a single client. The alpha testing process
continues until the system developer and the client agree that the
delivered system is an acceptable implementation of the requirements.

Fig : The stages of testing

27
4. Software Evolution
 Once a decision has been made to manufacture hardware, it is very expensive
to make changes to the hardware design. However, changes can be made to
software at any time during or after the system development.
 Software systems was a system while software evolution process starts from
existing system and make some changes to existing system or replace existing
system

Fig: System evolution

28
Coping with change
 Change is inevitable in all large software projects.
• Business changes lead to new and changed system
requirements
• New technologies open up new possibilities for improving
implementations
• Changing platforms require application changes
 Change leads to rework so the costs of change include both rework
(e.g. re-analysing requirements) as well as the costs of
implementing new functionality

29
Two strategies to reduce the costs of rework
 Change avoidance, where the software process includes activities that
can anticipate possible changes before significant rework is required.
• For example, a prototype system may be developed to show some
key features of the system to customers.
 Change tolerance, where the process is designed so that changes can be
accommodated at relatively low cost.
• This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have not
yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change.
30
Software prototyping
 A prototype is an initial version of a system used to demonstrate concepts
and try out design options. A prototype can be used in:
• The requirements engineering process to help with requirements
elicitation and validation;
• In design processes to explore options and develop a UI design;
• In the testing process to run back-to-back tests.
Benefits of prototyping:
• Improved system usability.
• A closer match to users' real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
31
32
Establish objectives: The objectives of the prototype should be made explicit
from the start of the process. Is it to validate system requirements, or
demonstrate feasibility, etc.
Define prototype functionality: Decide what are the inputs and the expected
output from a prototype. To reduce the prototyping costs and accelerate the
delivery schedule, you may ignore some functionality, such as response time
and memory utilization unless they are relevant to the objective of the
prototype.
Develop the prototype: The initial prototype is developed that includes only
user interfaces.
Evaluate the prototype: Once the users are trained to use the prototype, they
then discover requirements errors. Using the feedback both the specifications
and the prototype can be improved. If changes are introduced, then a repeat of
steps 3 and 4 may be needed. 33
• May be based on rapid prototyping languages or tools
• May involve leaving out functionality
• Prototype should focus on areas of the product that are not well
understood;
• Error checking and recovery may not be included in the prototype;
• Focus on functional rather than non-functional requirements such as
reliability and security
Throw-away prototypes
• Prototypes should be discarded after development as they are not a good basis
for a production system:
• It may be impossible to tune the system to meet non-functional requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through rapid change;
• The prototype probably will not meet normal organizational quality standards.
34
Incremental delivery

35
• The software specification, design and implementation are
broken down into a series of increments that are developed.
• In an incremental delivery process, customers identify, in outline,
the services to be provided by the system. They identify which of
the services are most important and which are least important to
them.
• A number of increments are defined with each increment
providing a subset of the system functionally. The allocation of
the services priority service delivered First.

36
• One the system increments have been identified the requirements
for the service to be delivered to the first increment that increment is
developed.
• During development further requirement analysis for later
increment can take place, but requirement changes for the current
increments are not accepted.
• Once an increment is completed and delivered costumers can put it
in to service. This means that they take early part of the system that
helps them clear their requirements for the later functionality
expands with each in increments.

37
Advantage of incremental delivery
• Costumers do not have to wait until the entire system is delivered.
Costumer gains valuable information from the increments satisfies
their most critical requirements so they can use the software
immediately.
• Customers can use the early increments as prototypes and gain
experience that informs their requirements for later system
increments.
• There is lower risk of overall project failure.
• As the high priority service are delivered first and the later
increments are integrated with them.

38
Disadvantage:
• Requirements are not defined in detail until an increment is to be
implemented, it can be hard to identify common facilities that are needed by
all increments.
• Iterative development can also be difficult when a replacement system is
being developed.

39
Spiral Model

40
• Spiral model handle large number of risk.
• The exact number of loops of the spiral is unknown and can vary from
project to project, Each loop of the spiral is called a Phase of the software
development process. 
• The main difference between the spiral model and other software
process models is its explicit recognition of risk.
• Each phase of Spiral Model is divided into four ,The functions of these
four quadrants are as:
1. Requirement determination and object setting : 
• Requirements are gathered from the customers and the objectives are
identified, elaborated and analyzed at the start of every phase.
• Constraint on the process and products are identified and a detailed
management plan is drawn up.
41
• The alternative solutions are specified and analyzed in this quadrant.
2. Identify and resolve Risks: 
• All the possible solutions are evaluated to select the best possible
solution.
• Then the risks associated with that solution is identified and the
risks are resolved using the best possible strategy. At the end,
Prototype is built for the best possible solution.
3. Development and Validation:
• Identified features are developed and verified through testing.
• A development model for the system is chosen which can be any of
the generic models.
• At the end, the next version of the software is available.

42
4. Planning
• The project is reviewed and a decision made whether to continue with
a further loop of the spiral.
• If it is decided to continue, plans are drawn up for the next phase of
the project.
This model is rarely used as published for practical software
development.
Advantages of Spiral Model: 
• The best development model to follow due to the risk analysis and
risk handling at every phase.
• Good for large projects.
• Additional Functionality can be added at a later date. 43
• It is suitable for high risk projects, where business needs may be
unstable.
• Customer can see the development of the product at the early phase of
the software development
• A highly customized product can be developed using this.
Disadvantages of Spiral Model:
• The Spiral Model is much more complex than other SDLC models.
• Spiral Model is not suitable for small projects as it is expensive.
• Project’s success is highly dependent on the risk analysis phase.
• As the number of phases is unknown at the start of the project, so time
estimation is very difficult.
• This model is rarely used as published for practical software
44
development.
 Process improvement
 Many software companies have turned to software process improvement
as a way of enhancing the quality of their software, reducing costs or
accelerating their development processes.
 Process improvement means understanding existing processes and
changing these processes to increase product quality and/or reduce costs
and development time.
Approaches to improvement
 The process maturity approach, which focuses on improving process
and project management and introducing good software engineering
practice.
 The level of process maturity reflects the extent to which good technical
and management practice has been adopted in organizational software
development processes. 45
 The agile approach, which focuses on iterative development and the
reduction of overheads in the software process.
 The primary characteristics of agile methods are rapid delivery of
functionality and responsiveness to changing customer requirements.

Process improvement activities form a continuous cycle with a feedback

loop:
• Measure one or more attributes of the software process or product. These
measurements forms a baseline that help decide if process improvements have
been effective.
• Analyze The current process is assessed, and process weaknesses and
bottlenecks are identified. Process models (sometimes called process maps)
that describe the process may be developed 46
• Change the process to address some of the identified process weaknesses.
These are introduced and the cycle resumes to collect data about the
effectiveness of the changes.
Process measurement
 Wherever possible, quantitative process data should be collected
• where organizations do not have clearly defined process standards this
is very difficult as you don’t know what to measure. A process may
have to be defined before any measurement is possible.
 Process measurements should be used to assess process improvements
• But this does not mean that measurements should drive the
improvements. The improvement driver should be the organizational
objectives.

47
Capability Maturity Model (CMM)

Figure : The Five Levels of Software Process Maturity 

48
The Software Engineering Institute (SEI) capability maturity model, measure the
maturity of an organization's software process.
 Initial
• The company does not use effective management procedures and plans.
There is no assurance of consistency, and quality is unpredictable
 Repeatable
• Product management procedures defined and used. The company does
not have formal process models defined
 Defined
• Process management procedures and strategies defined and used
 Managed
• Quality management strategies defined and used
 Optimizing
• Process improvement strategies defined and used 49
Thank you

50