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
