Software Process

 A software process is a set of related activities that

leads to the production of a software product.
◦ Software specification The functionality of
the software and constraints on its operation
must be defined.
◦ Software design and implementation The
software to meet the specification must be
produced.
◦ Software validation The software must be
validated to ensure that it does what the
customer wants.
◦ Software Evolution The software must
evolve to meet changing customer needs.
Software Process Continue
 Software processes are complex and and
creative processes, rely on people making
decisions and judgments.
 There is no ideal process and most
organizations have developed their own
software development processes.
 Processes have evolved to take advantage
of the capabilities of the people in an
organization and the specific characteristics
of the systems that are being developed.
Software Process Continue
 Software processes are categorized as
either plan-driven or agile processes.
 Plan-driven processes are processes where all
of the process activities are planned in advance
and progress is measured against this plan.
 In agile processes, planning is incremental and
it is easier to change the process to reflect
changing customer requirements.
 Software processes can be improved by
process standardization where the diversity in
software processes across an organization is
reduced.
The Process Model
 A software process model is a simplified
representation of a software process. Each
process model represents a process from a
particular perspective, and thus provides only
partial information about that process
Some Process models:
◦ The Waterfall Model
◦ Incremental Development
◦ Reuse oriented software Engineering
The Waterfall Model
 The waterfall model is a plan-driven process in
principle, in which plan and schedule of all of
the process activities before starting work on
them.
The Waterfall Model Continue
 The software process is not a simple linear model
but involves feedback from one phase to another.
 Because of the costs of producing and approving
documents, iterations can be costly and involve
significant rework.
 In Final phase, Program and design errors
emerge and the need for new functionality is
identified.
 The waterfall model is consistent with other
engineering process models and documentation is
produced at each phase.
 This model should only be used when the
requirements are well understood and unlikely to
change radically during system development.
The Incremental Model
 This model 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.
The Incremental Model
 Incremental software development, which is a
fundamental part of agile approaches, is better
than a waterfall approach for most business, e-
commerce, and personal systems.
 The cost of accommodating changing customer
requirements is reduced.
 It is easier to get customer feedback on the
development work that has been done.
 Customers are able to use and gain value from the
software earlier than is possible with a waterfall.
 This approach can be either plan-driven, agile,
or, more usually, a mixture of these approaches.
Problems in incremental approach Management
Perspective
 Managers need regular deliverables to measure
progress.
 It is not cost-effective to produce documents
that reflect every version of the system.
 Incorporating further software changes
becomes increasingly difficult and costly.
Reuse Oriented Software Engineering
 This often happens informally when people
working on the project know of designs or code
that are similar to what is required.
Reuse Oriented Software Engineering
 Component Analysis
 Based on requirements specification, components
are search to implement that specification. Usually,
there is no exact match and the components that
may be used only provide some of the functionality
required.
 Requirement Modification.
 During this stage, the requirements are analyzed
using information about the components that have
been discovered. They are then modified to reflect
the available components.
Reuse Oriented Software Engineering
 System Design with Reuse
 During this phase, the framework of the system
is designed or an existing framework is reused.
New software may have to be designed if
reusable components are not available.
 .Development and Integration
Software that cannot be externally procured is
developed, and the components and COTS
systems are integrated to create the new system.
Process Activities
 Software Specification
 Software specification or requirements engineering
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.
◦ Feasibility Study
(proposed system will be cost-effective from a business point of view)
◦ Requirements elicitation and analysis
( deriving the system requirements through observation of existing
systems, discussions with potential users and procurers, and so on.)
◦ Requirement specification
(User requirements and System requirements are properly defined)
 Requirement Validation
(It checks the requirements for realism, consistency,and completeness.)
Process Activities
 Software Design and Implementation
 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 implementation stage of software
development is the process of converting a
system specification into an executable system.
Process Activities
 Software Design
Different Design in Reuse System
 Architectural Design
 It shows the structure of the system, the principal
components/modules their relationships, and how
they are distributed.
 Interface Design
 It defines the interfaces between system
components. This interface specification must be
unambiguous.
 Component Design
 This may be a simple statement of the expected
functionality to be implemented, with the specific
design left to the programmer.
 Database Design
Different Design in Reuse System
 For critical systems, detailed design documents
setting out precise and accurate descriptions of
the system must be produced.
 Model-driven development (MDD) engineering
where models of the software are created at
different levels of abstraction, is an evolution of
structured methods.
 The models are developed in sufficient detail so
that the executable system can be generated
from them.
 Programming is a personal activity and there is
no general process that is usually followed.
Software Validation
 Software validation is intended to show that a
system conforms to its specification and that it
meets the expectations of the system customer.
 Validation involve inspections and reviews, at
each stage of the software process from user
requirements definition to program development.
 Because of the predominance of testing, the
majority of validation costs are incurred during
and after implementation.
Stages in testing process
 Development Testing
 In this stage, Each component is tested
independently, without other system components. It
may be entities such as functions or object classes,
or may be groupings of these entities.
 System Testing
 This test finds the errors that result from unanticipated
interactions between components and its interface
problems. It also concerned with showing that system
meets functional and non-functional requirements.
 Acceptance Testing
 This is final stage of 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.
Software Validation Continue
 In development, programmers make up their
own test data and incrementally test the code as
it is developed.
 In incremental approach, each increment should
be tested as it is developed, with these tests
based on the requirements for that increment.
 In extreme programming, tests are developed
along with the requirements before
development starts.
 In plan-driven process, testing is driven by a set
of test plans. An independent team of testers
works from these pre-formulated test plans, which
is developed from the system specification and
design.
Software Evolution
 When decision is made to hardware, it is very
expensive to make changes to the hardware
design.
 In software, changes can be made to software at
any time during or after the system development.
 The costs of maintenance are often several
times the initial development cost, maintenance
processes are sometimes considered to be less
challenging than original software development.
 software is continually changed over its lifetime
in response to changing requirements and
customer needs.
Coping with change
 The system requirements change as the
business procuring the system responds to
external pressures and management priorities
change.
 Therefore whatever software process model is
used, it is essential that it can accommodate
changes to the software being developed.
 It may then be necessary to redesign the
system to deliver the new requirements, change
any programs that have been developed, and
re-test the system.
Approach that reduce rework
 Change Avoidance:
 Where software process includes activities that
can anticipate possible changes before
significant rework is required.
 Team can refine their requirements before
committing to high software production costs.
 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.
Prototyping
 A prototype is an initial version of a software
system that is used to demonstrate concepts,
try out design options, and find out more about
the problem and its possible solutions.
 A prototype can help with the elicitation and
validation of system requirements.
 A prototype can be used to explore particular
software solution and to support user interface
design.
 Prototype defines strengths and weakness as
well as reveal errors and omissions of the
system requirements.
Prototyping Continue
 It can be used while the system is being
designed to carry out design experiments to
check the feasibility of the proposed design.
 It is an essential part of the user interface
design process.
 Rapid prototyping with end user involvement is
the only sensible way to develop graphical user
interface for the system.
Prototype Model
Incremental Delivery
Incremental Delivery
 Incremental delivery is an approach where
some of the developed increments are
delivered to the customer and deployed for use
in an operational environment.
 In this process services are defined based on
their importance and number of increments
delivery are defined.
 The allocation of services to increments depends
on the service priority, with the highest-priority
services implemented and delivered first.
 Once an increment is completed and delivered,
customers can put it into service.
Advantages of Incremental Delivery
 Customers do not have to wait until the entire
system is delivered before they can gain value
from it.
 The process maintains the benefits of
incremental development in that it should be
relatively easy to incorporate changes into the
system.
 Most important system services receive the
most testing, this means that customers are
less likely to encounter software failures in the
most important parts of the system.
Problems with Incremental Delivery
 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.
 There is no complete system specification until
the final increment is specified.
 This requires a new form of contract, in which
large customers like government agencies may
find difficult to accommodate.
Boehm’s Spiral Model
 A risk driven process proposed by Bohem is
represented as spiral rather than a sequence
of activities with some backtracking activities
from one activity to another is called spiral
model.
 Innermost loop concerned with feasibility study
where next loop discuss with requirement
definition and so on for SDLC activities.
 It assumes that changes are the result of
project risks and includes to reduce these
risks.
Boehm’s Spiral Model
Four Sectors of each loop in Spiral Model
 Objective Setting
◦ Objective for the phase is defined.
◦ Detail management plan is drawn.
◦ Projects risk are identified.
 Risk assessment and reduction
◦ A detail analysis for the risk is carried out.
◦ For example, if there is a risk that the
requirements are inappropriate, a prototype
system may be developed.
Four Sectors of each loop in Spiral Model
 Development and Validation
◦ A development model for the system is chosen.
◦ For example, throwaway prototyping may be the
best development approach if user interface risks
are dominant.
◦ If the main identified risk is sub-system
integration, the waterfall model may be the best
development model to use.
 Planning
◦ The project is reviewed and a decision made
whether to continue or not in next loop.
◦ If it is decided to continue, plans are drawn up for
the next phase of the project.
The rational Unified Process
 The Rational Unified Process is an example of
a modern process model that has been derived
from work on the UML and the associated
Unified Software Development Process.
 The RUP recognizes that conventional process
models present a single view of the process.
It can be described from three perspective
◦ A dynamic perspective, which shows the phase of the
model over time.
◦ A Static perspective, which shows the process
activities that are enacted.
◦ A practice perspective, which suggests good
practices to be used during the process.
The rational Unified Process
The rational Unified Process
 Inception Phase
 It establishes business case for the system.
 It identify entities that interact with the system
and define these interactions.
 This phase determine whether to develop or
not developing the system.
 Elaboration Phase
◦ This phase establish problem domain and
architectural framework of the system.
◦ At the end of this phase a requirement model
for the system is defined.
The rational Unified Process
 Construction Phase
◦ The construction phase involves system
design, programming, and testing.
◦ It develop and integrate system parallel.
◦ After this model system development team
have working software and its
documentation.
 Transition Phase
◦ It convert the way of system from
development to implementation.
◦ At the end of this phase, you should have a
documented software system that is working
Fundamental RUP Practices
 Develop Software iteratively
 Manage requirements
 Use component base architecture
 Visually Model Software
 Verify Software Quality
 Control Changes to Software