Unit 1

Software Processes
 Software Processes: Process and Project
 Process: Sequence of steps performed to achieve goal

 A software project: One instance, and use development process to

achieve it

 Development process takes the project from user and develops

software needed by user

 Other goals: cost schedule and quality, besides delivering software

 Software Processes: Process and Project
 Software Process: The sequence of steps performed to produce
software with high quality, within budget and schedule

 Process: Covers actions performed

Actual process, Planned process

 Process specification: A description of the process which

presumably can be followed in some project to achieve the goal
for which the process is designed.

 Process model: A general process, optimum

 Use it as project’s process to develop s/w with high Q&P

 Process: A means to reach goals of high quality, low cost, low

cycle time
 Component Software Processes
 Software Process: Deal with technical and management issues of
software development
 Two components in a software process:
 Development process – focuses on development activities needed to
engineer the software
 Project management process – focuses on planning and controlling
the development process to meet cost, schedule, quality, etc.

 Software configuration control process – Deal with managing change

 Product engineering process: above mentioned three processes

 Process management process – Required to improve the s/w process

 Deals with the whole process of understanding the current process,
analyzing its properties, determining how to improve, and then
affecting the improvement
 Component Software Processes
 Development process – Programmers, designers, testers, etc.
 Project management process – Project management
 Software configuration control process – Group- Configuration
controller
 Process management process – Software engineering process group
(SEPG)
Software process

Product engineering Process management

process process

Development Project management Software

process process configuration
management process
 Software Development Process Models

 Goal to produce high quality s/w product

 Development process – core of s/w process
 Management process – decided based on development process
 Development process – Defines the tasks of the project that should be
performed
- Order in which they should be performed
 Process model – Specifies a general process
As set of stages in which project is divided
Order in which stages should be executed
Conditions and constraints required for execution
 Basic premise – situation for which it is applicable, use it to lead to
low cost, high quality and reduced cycle time
 1) Waterfall Model

 Simplest process model, phases organized in linear order

 Proposed by Royce – variations evolved during activities
 Procedure:
1) Project begins with Feasibility Analysis.
2) After successful demonstration of feasibility, Requirement Analysis
& Project Planning begins.
3) Design starts after requirement analysis is complete.
4) Coding begins after design is complete.
5) Once coding is complete, code is Integrated and Testing is done.
6) Upon successful completion of testing, system is Installed.
7) After this, regular Operation and Maintenance of system takes place.
 Sofware Process 25
Waterfall Model
 Waterfall Model

 Basic idea behind phases – separation of concerns

Each phase deals with a distinct and separate set of concerns.
So, task of building complex problem divided into smaller tasks

 Linear ordering of activities has important consequence

Identify end of phase and beginning of next phase
Employ some certification mechanism at the end of each phase
Done by some verification and validation means, that ensure output of
phase is consistent with its input

 After completion of activities of a phase – some product to be generated

 Output of earlier phases – work products
Present in the form of document
 Waterfall Model
 Advantages:
1) Simplicity
2) Straightforward – Divides large task into series of phases
3) Easy to administer – Work product produced after each phase
Some amount of money obtained by developing organization
 Disadvantages:
1) Requirements of system can be frozen
All requirements to be known upfront
2) Freezing requirements requires choosing the hardware
3) Follows big bang approach – entire s/w delivered at the end
all or nothing delivery
4) Encourages requirements bloating
All requirements to be specified at the start, even if not used later
5) Is document driven process – requires formal documents at the end
of each phase
 2) Prototyping Model

 Goal- To counter first limitation of waterfall model

 Basic idea-
Instead of freezing requirements before design or coding proceed,
build throwaway prototype to help understand the requirements

 Develop prototype based on currently known requirements

 Development undergoes design, coding, testing, but each of these

phases not done formally or thoroughly
 Using prototype, client get actual feel of system, enabling to better
understand the requirements of desired system

 Results in more stable requirements that change less frequently

 Act as an attractive idea for complicated and large systems, where

no manual process or existing system present to help determine the
requirements

Prototyping Model
Sofware Process 25
 Prototyping
 Procedure:
1) Development starts when preliminary version of requirement
specification document is developed.

2) At this stage, there is reasonable understanding of system and its needs

and which needs are unclear.

3) After prototype is developed, end users and clients are given opportunity
to use and explore the prototype, specifying what is correct, what needs to
be modified, what is missing, what is not needed.

4) Based on feedback, prototype is modified to incorporate suggested

changes, then users are again allowed to use the system.

5) Cycle repeats until, judgment of prototype developers and analysts

benefit from further changing the system and obtaining feedback outweigh
cost and time.
 Prototyping
Based on feedback, initial requirements are modified to get final
requirements specification, then used to develop the quality system.
Features:
 No point in implementing parts of requirements already understood
 Focus on requirements that are not properly understood
 Minimal documentation to be produced, as prototype to be thrown away
 Another cost cutting measure- reduce testing

 Experience of developing prototype will reduce the cost of actual software

development.
 Requirements will be more stable due to feedback from the prototype,
there will be fewer changes in the requirements.
 Quality of final software is likely to be far superior.
 Developing prototype mitigates many risks that exist in a project where
requirements are not well known.
 3) Iterative Development Model
 Counters third and fourth limitation of waterfall model, and
combine benefits of both waterfall and prototyping model

 Basic idea-
Software to be developed in increments, each increment
adding some functional capability to the system until full
system is implemented.

 Iterative enhancement model - one approach

 First step- Simple initial implementation done for a subset of
the overall problem
 Subset- That contains key aspects of the problem, easy to
understand and implement and forms a usable system
 Iterative Development

 Create project control list- Contains, in order, all tasks that

must be performed to obtain the final implementation

 PCL gives an idea of how far long the project is at any given
step from the final system

 Each step consists of:

 Removing the next task from the list
 Designing the implementation for the selected task
 Coding and testing the implementation
 Performing analysis of the partial system obtained after this step
 Updating the list as a result of the analysis
 Three phases- design phase, implementation phase and analysis phase

 Process is iterated until the PCL is empty, at which time the final
implementation of the system will be available

Iterative enhancement Model

Sofware Process 48
 Iterative Development
 Another approach-
Do requirements and architecture design in waterfall or
prototyping model, but deliver the software iteratively

 View- one iteration to deliver requirements and architecture

plan, and further iterations to deliver software in increments.

 At start of each delivery iteration, decide the requirements to be

implemented in this release, then enhance the design and
develop code to implement the requirements.

 Iteration ends with delivery of a working software system

 Selecting of requirements done based on the value the
requirement provides to end users and how critical they are
for supporting other requirements

Iterative delivery approach Sofware Process 48

 Iterative Development
 Advantage of approach-
Requirements are mostly known upfront.
An overall view of the system is available.
A proper architecture can be designed, which can remain
relatively stable.

 Rework in development iterations will diminish.

 Value to the end customer is delivered iteratively so it does not
have all-or-nothing risk.
 Since the delivery is being done incrementally, and planning
and execution of each iteration is done separately, feedback
from an iteration can be incorporated in the next iteration.
 4) Rational Unified Process (RUP)

 Another iterative process model designed by Rational, for

object-oriented development using UML

 RUP proposes that development to be divided into cycles, each

cycle delivering a fully working system.

 Each cycle executed as separate project, goal -to deliver some

additional capability to existing system (built by previous cycle).
 Rational Unified Process (RUP)

 For a project, the process for a cycle forms the overall process.
Each cycle broken into four consecutive phases:
1) Inception phase
2) Elaboration phase
3) Construction phase
4) Transition phase

Each phase has a distinct purpose, and completion of each phase is

a well defined milestone with some clearly defined outputs.
 RUP model
 Inception phase-
Purpose to establish goals and scope of project, and after
completion is the lifecycle objectives milestone.
Milestone specify vision and high -level capability of
eventual system, business benefits, use cases of the system, key
risks , basic plan regarding cost and schedule
Based on output, decision of go/no -go
Milestone represents there’s a shared vision among
stakeholders, agree to project, its vision, benefits, cost, usage,
etc.
Sofware Process 48
 RUP
 Elaboration phase-
Designed system architecture based on detailed requirements
analysis and after completion is the lifecycle architecture
milestone.
Expected to identify and specify most requirements
Prepare high-level project plan, showing remaining phases
and iterations in those, and current perception of risks
By the end, decisions regarding choice of technologies,
architecture, etc. taken, and a detailed understanding of the
project exists
 RUP
 Construction phase-
Software built and tested
Results in the software product to be delivered, along with
associated user and other manuals, and after successful
completion is the initial operational capability milestone

 Transition phase-
Purpose to move software from development environment
to client’s environment, where it is to be hosted
Complex task, require additional testing, conversion of old
data for this software to work, training of personnel, etc.
Successful execution is the milestone product release.
 RUP
In RUP, engineering tasks and phases are separate.
RUP groups the activities into different subprocesses, called
as core process workflows.

Activity level of subprocesses in different phases of RUP.

 RUP
 Key difference of RUP from other models is separation of
phases from the tasks.

 In waterfall-based iterative model, a phase was linked to a

particular task performed like requirements, design, etc.
 In RUP these tasks are separated from the stages.
 A project may do detailed requirements only for some features
during elaboration phase, and may do detailing of other
requirements while the construction is going on.

 RUP provides a flexible process model, which follows an

iterative approach at a top level through cycles and, during each
of the phases in a cycle. And in phases, it allows different tasks
to be done as per the needs of the project.
 5) Timeboxing Model

 Basic unit time box of fixed duration

 Select requirements or features to be built to fit into time box
 In iterative approaches, select functionality and then determine
time to deliver
 In timeboxing, a high-priority to the schedule
 Divide timebox into sequence of stages, each performs some
clearly defined task and produces a clearly defined output
 Require duration of each stage, time taken to complete task be
same
 Requires a dedicated team for each stage, team for a stage
performs only tasks of that stage
Timeboxing Model

Example- time box of three stages, done in approximately equal

time in an iteration:
requirement specification
build
deployment

•Requirement stage gives a prioritized list of requirements

to be built with a high-level design.
•Build team develops the code, and performs testing.
•Deployment team performs predeployment tests, and then
installs the system for production use.
 Timeboxing Model
Pipelined execution of the timeboxing process

Executing the timeboxing process model

Timeboxing is well suited for projects that require a large

number of features to be developed in a short time around a stable
architecture using stable technologies.
 Timeboxing Model
Three teams working on the project—the requirements team,
the build team, and the deployment team.
Teamwise activity for the 3-stage pipeline

Tasks of different teams

 6) Extreme Programming and Agile Processes
 Agile development approaches evolved in 1990s as a reaction to
documentation and bureaucracy-based processes, particularly the
waterfall approach.

 Agile approaches based on some common principles:

1. Working software- key measure of progress in a project
2. For progress, rapid development and delivery of software in
small increments
3. Entertainment of late changes in the requirements
4. Prefer face-to-face communication over documentation
5. Necessity of continuous feedback and customer involvement in
developing good-quality software
6. Simple design that evolves and improves with time
7. Decision of the delivery dates empowered by teams of talented
individuals
 Extreme Programming (XP)

 Popular, well-known approaches in the family of agile methods

 To accommodate change, development process to be lightweight
and quick
 Iterative software development
 Relies on face-to-face communication, simplicity, and feedback
to ensure desired changes to reflect quickly and correctly

 XP project starts with user stories

 User stories
 Short descriptions of what scenarios customers and users want
the system to support
 Do not contain detailed requirements
 XP
 Each story written on a separate card
 Development team estimates time to implement user story, stated
in weeks
 Release planning- defines which stories are to be built in which
system release, and the dates of these releases

Overall process in XP
 Development done in iterations, each of few weeks
 Iteration starts with iteration planning, in which select stories to
be implemented, higher priority to high value and high risk
stories
 Handling of failed acceptance tests in previous iteration

An iteration in XP
 XP

 Development approach used in iteration:

1) Envisages that development by pairs of programmers
2) To build code, write automated unit tests first and then code to
pass the tests (test-driven development approach)
3) Design devised earlier may become unsuitable for further
development.
Refactoring done to improve design of existing programs
4) Encourages frequent integration of different units.
One pair at a time can release their changes and integrate into
the common code base.
 Project Management Process

 Specify number of resources allocated to each activity for the

project
 Monitoring of progress of different activities
 Specifies all activities to be done to meet cost and quality
objectives
 Basic task to plan detailed implementation of the process for
the particular project and then ensure its proper execution
 Activities grouped into three phases: planning, monitoring and
control, and termination analysis
Temporal relationship between development and management process
 Project Management Process

 Planning phase-
 Develop a plan for software development to meet project
objectives
 Software plan produced before development activity begins,
and updated as development proceeds and progress of the
project becomes available
 Major activities: cost estimation, schedule and milestone
determination, project staffing, quality control plans, and
controlling and monitoring plans
 Forms basis for monitoring and control
 Project Management Process

 Project monitoring and control phase -

 Takes long duration
 Includes all activities while development is in progress, to
ensure objectives are met and development proceeds
according to the developed plan (if required update)
 Activities: monitoring factors as cost, schedule, quality that
affect these. Monitoring potential risks preventing to meet
objectives. Take necessary actions by exerting control.
 Monitoring requires proper information about the project,
obtained from the development process.
 Project Management Process

 Termination analysis phase-

 Called postmortem analysis
 Performed after completion of development process
 To provide information about development process and learn
to improve the process
 In iterative development, done after each iteration to
provide feedback to improve execution of further iterations
Thank You