This document provides an overview of the Unified Process, Agile process, and process assessment. It defines the Unified Process as an iterative framework derived from UML that includes inception, elaboration, construction, and transition phases. Agile processes like Extreme Programming emphasize iterative development, collaboration, and responding to change. Process assessment involves objectively evaluating an organization's ability to meet process goals through stages of initiation, preparation, assessment, analysis and reporting, and closure.

1. P R E S E N T E D B Y :
S H W E T A G H A T E
T R U P T I D I W A N
P R A T I M A J A D H A V
S A P N A V A S A V E
M I T C O L L E G E O F
E N G I N E E R I N G , P U N E .
Unified Process, Agile process,
Process Assessment

2. Agenda
 Unified Process
 Agile Process
 Process Assessment

3. What is Process ???
 SEP i.e. Software Engineering Process
 Defines who, what, when and how of developing
software.
Software Engineering
Process
New or Changed
requirements
New or Changed
system

4. What is Unified Process ??
 Unified process (UP) is an architecture-centric, use-case
driven, iterative and incremental development process
that leverages unified modeling language and is
compliant with the system process engineering
metamodel.
 A popular iterative modern process model (framework)
derived from the work on the UML and associated
process.

5. Unified Process
 The leading object-oriented methodology for the
development of large-scale software
 Maps out when and how to use the various UML
techniques
 Develop high-risk elements in early iterations
 Deliver value to customer

6. Creating the Unified Process
Rational Unified Process 5.0
1998
Rational Objectory Process 4.1
1996-1997
Objectory Process 1.0-3.8
1987-1995
Ericsson Approach
Rational Approach
IBM Approach
Unified Process
1998
OO Approach

7. The Unified Process
 The Unified Process is an adaptable
methodology.
 The Unified Process is a modeling technique.
UML stands for unified modeling language.
• The object-oriented paradigm is iterative and
incremental in nature

8. Unified Process Phases
 Inception
 Establish the business case for the system, define risks, obtain
10% of the requirements, estimate next phase effort.
 Elaboration
 Develop an understanding of the problem domain and the
system architecture, risk significant portions may be
coded/tested, 80% major requirements identified.
 Construction
 System design, programming and testing. Building the
remaining system in short iterations.
 Transition
 Starts when beta testing is completed, Deploy the system in its
operating environment. Deliver releases for feedback and
deployment

9. The Phases/Workflows Of Unified Process
Phase is Business context of a step
Workflow is
Technical
context of a
step

10. The Phases/Workflows Of Unified Process
 NOTE:
Most of the
requirements
work or
workflow is
done in the
inception
phase.
 However
some is done
later.

11. The Phases/Workflows Of Unified Process
 NOTE:
Most of the
implementati
on work or
workflow is
done in
construction
 However
some is done
earlier and
some later.

12. Example roles in UP
 Stake Holder: customer, product manager, etc.
 Software Architect: established and maintains
architectural vision
 Process Engineer: leads definition and refinement
of Development Case
 Graphic Artist: assists in user interface design, etc.

13. Agile Process

14. Agenda
 Manifesto for Agile Software Development
 What is Agility?
 Agile Teams
 Agility and the Cost of Change
 An Agile Process
 The principles of agile methods
 Human Factors
 Agile Process Models
 Agile Modeling
 Conclusion

15. Manifesto for Agile Software Development
 “We are uncovering better ways of developing software by
doing it and helping others do it.
 Agile values:
1. Individuals and interactions- in agile development, self
organization & motivation are important
2. Working software- working software will be more useful and
welcome than just presenting documents to clients in
meetings
3. Customer collaboration-requirements cant be fully collected
at the beginning of the software development cycle, therefore
continuous customer involvement is important
4. Responding to change- agile development is focused on
quick responses to change and continuous development

16. Agility
 Effective response to change
 Effective communication among all stakeholders
 Drawing the customer into the team.
 Organizing a team so that it is in control of the
work performed
In order to yield rapid, incremental delivery of
software

17. Agile Teams
 Responsive to changes during project
development
 Recognize that project plans must be flexible
 Eliminates the separation between customers and
developers

18. Agility and the Cost of Change
 Conventional wisdom is that the cost of
change increases nonlinearly as a project
progresses. It is relatively easy to
accommodate a change when a team is
gathering requirements early in a project.

19. Agility and the Cost of Change

20. An Agile Process
 Is driven by customer descriptions of what is required
(scenarios). Some assumptions:
 Recognizes that plans are short-lived (some requirements will
persist, some will change. Customer priorities will change)
 Develops software iteratively with a heavy emphasis on
construction activities (design and construction are interleaved,
hard to say how much design is necessary before construction.
Design models are proven as they are created. )
 Analysis, design, construction and testing are not predictable.
 Thus has to Adapt as changes occur due to unpredictability
 Delivers multiple ‘software increments’, deliver an operational
prototype or portion of an OS to collect customer feedback for
adaption.

21. Human Factors
 The process molds to the needs of the people and team, not the
other way around
 key traits must exist among the people on an agile team :
 Competence. ( talent, skills, knowledge)
 Common focus. ( deliver a working software increment )
 Collaboration. ( peers and stakeholders)
 Decision-making ability. ( freedom to control its own destiny)
 Fuzzy problem-solving ability.(ambiguity and constant
changes, today problem may not be tomorrow’s problem)
 Mutual trust and respect.
 Self-organization. ( themselves for the work done, process for
its local environment, the work schedule)

22. Agile Process Models
 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Agile Modeling (AM)

23. Extreme programming
 The most widely used agile process.
 Defines 4 framework activities
Planning
Design
Coding
Testing

24. Extreme programming
24
refactoring
user stories
values
acceptance test
criteria
iteration plan
simple design
CRC cards
spike solutions
prototypes
pair
programming
unit test
continuous integration
acceptance
testing
software increment
project velocity computed
Release

25. Extreme programming
 XP Planning
 Begins with the creation of “user requirements”
 Agile team assesses it and assigns a
cost
 They are grouped to form a deliverable
increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments

26. Extreme programming
 XP Design
Follows the KIS principle
For difficult design problems, suggests the
creation of “spike solutions”—a design
prototype
Encourages “refactoring”—an iterative
refinement of the internal program design

27. Extreme programming
 XP Coding
Recommends the construction of a unit test
for a store before coding commences.
Encourages “pair programming”.
 XP Testing
All unit tests are executed daily
“Acceptance tests” are defined by the
customer and executed to assess customer
visible functionality

28. Adaptive Software Development (ASD)
 Self-organization arises when independent agents
cooperate to create a solution to a problem that is
beyond the capability of any individual agent
 Adaptive cycle characteristics
 Mission-driven planning
 Component-based focus
 Uses “time-boxing”
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning”

29. Three Phases of ASD
ad ap t ive cycle p lanning
uses m issio n st at em ent
pro jec t c o nst raint s
b asic requirem ent s
t im e-b o xed release p lan
Req uirem ent s g at hering
JA D
m ini-sp ecs
co m p o nent s im p lem ent ed / t est ed
f o cus g ro up s f o r f eed b ack
f o rm al t echnical review s
p o st m o rt em s
so f t w a re in cre m e n t
a d ju st m e n t s f o r su b se q u e n t cy cle s
Release

30. Three Phases of ASD
1. Speculation:
 Project is initiated and adaptive cycle planning is
conducted.
 Adaptive cycle planning uses project initiation
information.
 Based on the information obtained at the
completion of the first cycle, the plan is
reviewed and adjusted.

31. Three Phases of ASD
2. Collaborations
 Are used to multiply their talent and creative output
beyond absolute number (1+1>2).
 It encompasses communication and teamwork, but it
also emphasizes individualism.

32. Three Phases of ASD
3. Learning:
 As members of ASD team begin to develop the
components, the emphasis is on “learning”.
 Learning will help them to improve developers level of
real understanding.
 Three ways: focus groups, technical reviews and project
postmortems

33. Process Assessment

34. What is Process Assessment
 An objective model-independent method to
assess the capability of an organization to meet
the process goals
 About collecting information
 A way to demonstrate program effectiveness

35. Assessment Method
 Assessment Stages
 Key Players
 Initiation
 Preparation
 Assessment
 Analysis and Reporting
 Closure

36. Assessment Stages
Initiation
Preparation
Assessment
Analysis
and
Reporting
Closure

37. Initiation (stage 1)
Define the
inputs
• identify the assessment purpose
• select the assessment model
• define goals for the assessment
• identify the business drivers
• identify constraints
• document assumptions
• identify additional information gathering requirements
• identify feedback and output requirements
• complete the assessment brief
Sanction
the
business case
• costs and benefits
• decision to proceed
Select the
Resources
Outputs
• assessment purpose
• constraints
• assessment goals
• confidentiality agreements
• quality measures to be collected

38. Assessment (stage 3)
Gather
Information
• conduct interviews
• study documentation
• document findings
• consolidate the findings
• rate the goals
• rate the process
• feedback initial conclusions
• determine the Organizational Unit’s Capability Level
Reach
Consensus
• on ALL ratings!
Conduct
• according assessment plan
• adapt plan for changes and feedback
• data collection by interview or document
• data review for process ratings
• assessors agree on ratings before submitting
them to the Lead Assessor
Types
• measurement only (no analysis)
• Findings & Recommendations
• Findings & Action Planning

39. Analysis & Reporting (stage 4)
Analyse
Findings
Disseminate
Findings
Identify
Action Plan
issue
Final Report
• Strengths & Weaknesses
• Gap Analysis
• Identify Improvement
Opportunities
• semi-formal interactive
feedback session
• prioritise improvements
according impact & effort
against business drivers
• Cost/benefit Analysis
• Schedule of improvement
roll-out
• management findings &
recommendations
• summary assessment process
& key players
• results compared with targets
• detailed process findings

40. Closure (stage 5)
Post-Assessment
Review
• results of the analysis of the participants feedback forms
• the assessments’ achievements against its goals
• the overall level of confidence in the assessments results
• any problems the assessors experienced during the assessment
including problems with the use of the method
• the successes achieved
• the techniques used during the assessment
• the organizational unit and the Sponsor's response to the results
• Lead Assessor ensures that the Assessment Conformance Checklist
is complete and signed-off.