Unified Process of Software Development

1. The Unified Process of Software
Development
• Software and its marketability factors
• Why is software development a labour-intensive
industry?
• The Unified process and its iterations
• The phases of the Unified Process
• Best Practices in the Unified Process
• Workflows of the Unified Process

2. Software and Software
Engineering
• According to IEEE, software is defined as a
collection of computer programs, procedures,
rules, associated documentation and data.
• “Software Engineering”- A field dedicated to the
proper development of industrial-quality
software.
• Greater stress on methods to develop software.
• Why was the need felt to develop proper
processes?

3. Human-Intensive Nature of
S/w Industry
• Software marketability depends on three factors: Cost,
Quality and Schedule.
• Cost of software is steadily rising.
• Various software development tools have arrived in the
market.
• E.g. Tools to do Requirement-gathering, Designing,
Forward engineering, Testing, Configuration management .
• However,Software still is a labour-intensive industry.
• A large number of Analysts, Designers, Programmers,
Testers, Documentation-experts and Maintainers are
needed to develop industrial-quality software.

4. Late delivery of S/w
• In many cases, the software, which was
developed before the advent of formal
development techniques, was delivered to the
customer way behind schedule.
• It did not do what it was expected to
do.Reasons: Improperly elicited requirements or
improper design that reflected on the developed
code.
• The cost incurred was much greater than the
one decided at the start of the project.

5. The problem of change
• Change is prevalent because of: bugs and
changing customer requirements.
• Bugs, which unfortunately escaped the tester’s
eye, can surface even long after the system is in
use.
• So the maintainer has to adapt the software to
counter the bugs and rectify the problem.
• Law of Software evolution.

6. Various Processes of Software
Development
• Various processes have evolved over the years.
• Examples:
• Sequential Life-cycle process
• Prototyping process
• Rapid Application Development process,
• Iterative Development process and
• Unified Software Development Process.

7. The Unified Process of Software
Development
• The key feature:Software development is done
in a series of fixed periods, for example,
between 2 and 6 weeks. Each period is called as
iteration.
• At the end of each iteration, we have an
executable system.
• Each iteration has its own requirement analysis,
design, coding and testing.
• The software development is incremental.
Implement New features added apart from the
User’s suggested changes.

8. Timeboxing an Iteration
• Each iteration is timeboxed i.e. fixed in length.
• The UP recommends each iteration to be
between 2 and 6 weeks.
• It has no provision for the extension of an
iteration period.
• If developers are unable to complete coding the
given requirements within fixed time, then
decrease the number of requirements to code.

9. Advantages of Timeboxing an
Iteration
• The UP is architecture-centric and risk-driven.
• Team forced to identify core architecture and
high-risk, high-value requirements early.So the
prioritization of requirements automatically
takes place.
• Increase in confidence level of the stakeholders
in the development team and the project.
• Increase in confidence of the team-members in
their own ability leading to team satisfaction.

10. UP Phases
• The Unified Process consists of four phases:
• Inception,
• Elaboration,
• Construction and
• Transition.
• Each phase is completed in a series of iterations.

11. Inception
• A vision of the product is created. Questions discussed are:
• What is the product supposed to do?
• Why should my organization embark on a project to build
this particular product?
• Does my organization have the resources to build this
product?
• Is it feasible to do so?
• How much will this product cost and how much will it bring
in?
• What will be the duration of the project?
• Risk analysis is performed.
• Decision whether to go ahead with the project or not is
taken.

12. Elaboration
• System to be built is analyzed in detail.
• Use cases used to document the requirements.
Main aim: Get the core architecture and as
many use cases as possible.
• The core architecture is coded, verified with user
and baselined.
• Other high-risk requirements are identified and
coded.
• A project plan is drawn in this phase, resources
are allocated and a schedule is planned.
• UML diagrams are used to model the system
under design.

13. Construction
• Remaining use cases are implemented.
• If any new use cases are discovered, they are
implemented.
• Test cases are written, actual tests are carried
out and a test report is prepared.
• Documentation for the system as well as guides
for the users are written.

14. Transition
• System is installed in its environment and beta-
tested.
• Feedback is received and System is refined and
tuned to adapt in response to the feedback.
• It also includes activities like marketing of the
product and training of users.

15. Best Practices in the Unified
Process
• E.g. Building of a website to host an all-India online entrance test to
qualify for post-graduate courses in Physics.
• Suppose over a lakh students are answering at designated testing
centres in the country. The test comprises of 90 objective questions
only which have to be answered in 90 minutes. The candidate has
to log in with an id and password provided to him by the screening
authorities. After he logs in, he will be provide with the first question.
On the top right-hand corner of the page, there will be a clock
showing the time. When he answers the question he will get the
next question and so on. At the end of 90 minutes, the system must
display each candidate’s total score with the necessary details on a
report of which he can take a hard copy.

16. Architecture-centric
• UP is architecture-centric.
• Team has to try and get the correct core architecture in the
early iterations.
• So, in the earliest iterations, the task would be to gather
the highly valued requirements, then analyze, design, code
and test them before showing it to the stakeholders at the
end of each iteration.
• In our example, the core requirements:
• Selecting the physical configuration of the server,
• Handling huge number of connections,
• Validating user-names and passwords and
• Computing scores as each user answers.

17. Architecture-centric contd..
• The requirements, that are important but not
core:
• Web-page layout,
• Visibility of the web pages through a variety of
browsers etc.
• The core requirements have to be handled first.

18. Tackles riskiest issues first
• The UP tackles the riskiest issues first.
• In our example:
• Handling huge number of connections,
• Validating user ids and passwords and
• Computing correct scores as each user answers.
• So these issues have to be tackled early.

19. User feedback at every step
• UP stresses on continuous dialogue with the
users and receives their feedback at every
stage.
• Unlike traditional Waterfall process model where
the entire system is shown to the users only
after the testing phase is over.
• IN UP, customers can suggest changes at the
end of every iteration and the cost of
implementing these changes early is minimal.
• Actual users are automatically familiarized with
the software and unwittingly get trained with its
use.

20. Repeated verification of quality
• The UP stresses on the repeated verification of
quality.
• Here, quality refers to both, the quality of the
software to be developed as well as the quality
of the process itself.
• At the end of each iteration the team must
produce executable software.
• This achievement indicates the success of the
iteration.
• The software is tested and verified right from
the start unlike the traditional SDLC where
Quality Analysis is done basically at the end.

21. Use of Use Cases
• The UP recommends the use of use cases.
• It also advises the use of the UML to model
software visually.

22. Careful Management of
requirements
• In the UP, requirements are carefully managed.
• Managing implies elicitation,prioritizing of the requirements
and their tracking with the support of tools.
• The request for the change is carefully analyzed, the impact
of the change is studied and only if the request is accepted
then further decisions are taken.
• There is a formal procedure to submit request for change
and to decide to make the change or not.
• The lifecycle of accepted change requests is tracked.
• The UP supports the Configuration Management and
version Control of all artifacts.

23. Workflows of the UP
• A process describes who is doing what, how and
when.
• Four modeling elements:
• Workers,
• Activities,
• Artifacts and
• Workflows
• Workers perform activities and the results of
performing the activities are artifacts.
• Define behaviour of an individual or a team.

24. Workflows of the UP contd..
• Activity-Unit of work that an individual in a particular role may be
asked to perform.
• An artifact is a piece of information that is produced, modified or
used by a process.
• They are products, which are formed in course of a process.
• An artifact can be treated as an input by a worker to perform an
activity.
• E.g. A class diagram drawn using a tool, like ArgoUML, is an
artifact.
• It can be used as an input to generate code using ArgoUML's
code-generating facility.
• Artifact is also the output of an activity produced by a worker.
• E.g. The source code produced in the above example is an
artifact that is an output of the code generating activity.

25. Workflows of the UP contd..
• A workflow is a sequence of activities that produces a result
of discernible value. In the UP, there are nine core process
workflows. They are:
• Business Modeling Workflow
• Requirements Workflow
• Design Workflow
• Implementation Workflow
• Test Workflow
• Deployment Workflow
• Project Management Workflow
• Configuration and Change management Workflow
• Environment Workflow

26. Business Modeling Workflow
• Main aim: Evolve a common understanding
among various stakeholders about what the
project will deliver.
• Unified Process provides a common language
and process for various stakeholders.

27. Requirements Workflow
• Before building a product, the developers must
have an idea of what the product is expected to
do.
• The aim:To achieve the above task by eliciting
the functional requirements as well as the
constraints.
• A document describing the vision and scope of
the project is created.
• Actors and use cases are identified and
described in detail.
• The constraints are also documented.

28. Design Workflow
• The main aim:Deliver the design model.
• The identification and validation of core
architecture is done in an iterative manner.
• Initially, only the core architectural design is
done without paying much attention to details.
• This is followed by detailed design of the core
architecture.
• Other facets of the design like the databases,
networking etc. are also designed.

29. Implementation Workflow
• Main aim:To program and build the system.
• Unit tests are also carried out and the unit-
tested units are integrated into a complete
system.

30. Test Workflow
• Actually, testing is done throughout the project
in an iterative manner.
• Testing includes
• the verification whether software has been
developed according to the user requirements
and
• whether the components of the software are
properly integrated and defects addressed prior
to the deployment of the software.

31. Deployment Workflow
• Main aim: To release the software and deliver it
to the end users.
• The software is installed at the user's site, beta
testing is done and the software is adjusted to
suit the customer.
• This workflow also includes assistance to the
user in the use of the software.

32. Project Management Workflow
• To manage a software project, it is necessary for the
project manager to
• Manage risks,
• Overcome difficulties in course of the project,
• Balance the objectives of different people and
• Ultimately deliver a product to the customer of high quality,
reasonable cost and within the estimated schedule.
• The aim:To simplify these tasks by providing a framework
for managing the overall project, managing risks and
providing guidelines for formulating a project plan,
allocating staff and monitoring the course of the project.

33. Configuration and Change
Management Workflow
• Gives guidelines on how to manage the various
problems that are inherent when teamwork is
performed.
• Guidelines can be in regard to:
• Maintaining different variants of software,
• Enforcing organizational development policies,
• Managing change requests,
• Tracking changes and
• Keeping an audit of the changes made.

34. Environment Workflow
• Main aim:To provide the software development
organization the processes and the tools that
are needed to support the development team.
• A detailed guide is provided to implement a
customized process for a particular project in
the organization.