SE 501 Software Development
Processes
Dr. Basit Qureshi
College of Computer Science and Information Systems
Prince Sultan University
Lecture for Week 3
Contents
• SDLC’s continued
– Agile, RUP, TSP, ACDM
• Choosing suitable SDLC
• Summary
• Discussion on Assignment #2
SE 501 Dr. Basit Qureshi
2
Bibliography
• Humphrey, Watts (1999). Introduction to the Team Software Process.
Addison Wesley.
• http://www.ibm.com/developerworks/rational/library/1826.html#N100E4
• Justin Rockwood, “Choose Your Weapon Wisely” CMU, 2003
• Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide.
Addison-Wesley
• Lattanze, Anthony J. (2009). Architecting Software Intensive Systems: A
Practitioners Guide. Software Engineering. CRC Press
SE 501 Dr. Basit Qureshi
3
SDLC CONTINUED
SE 501 Dr. Basit Qureshi
4
SDLC continued
• Last week
– Ad Hoc
– Classical (Water fall)
– Prototype
– RAD
– Incremental
– Spiral
– WinWin
– V model
– Chaos
SE 501 Dr. Basit Qureshi
5
SDLC: More recent
•
•
•
•
Agile
RUP
TSP
ACDM
SE 501 Dr. Basit Qureshi
6
SDLC: More recent
SE 501 Dr. Basit Qureshi
7
Agile methods
Webster Dictionary:
“Marked by ready ability to move with quick easy
grace”
As applied to Software Development: Cockburn
“Ability to change development in response to
changing requirements”
SE 501 Dr. Basit Qureshi
8
Agile methods
The Agile Manifesto [http://agilemanifesto.org/]
“A method of software development that aims for
customer satisfaction through early and
continuous delivery of useful software
components”
SE 501 Dr. Basit Qureshi
9
Agile methods
• Rapid development and delivery is now often the most
important requirement for software systems
– Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
– Software has to evolve quickly to reflect changing business
needs.
• Rapid software development
– Specification, design and implementation are inter-leaved
– System is developed as a series of versions with
stakeholders involved in version evaluation
– User interfaces are often developed using an IDE and
graphical toolset.
Chapter 3 Agile software development
10
SE 501 Dr. Basit Qureshi
11
Agile methods
• Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of agile
methods. These methods:
– Focus on the code rather than the design
– Are based on an iterative approach to software development
– Are intended to deliver working software quickly and evolve this quickly
to meet changing requirements.
• The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to be
able to respond quickly to changing requirements without
excessive rework.
Chapter 3 Agile software development
12
Agile manifesto
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
– Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
• That is, whilethere is value in the items on the right,
we value the items on the left more.
Chapter 3 Agile software development
13
The principles of agile methods
Principle
Description
Customer involvement
Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery
The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process
The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change
Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
Chapter 3 Agile software development
14
Agile method applicability
• Product development where a software company is
developing a small or medium-sized product for sale.
• Custom system development within an organization,
where there is a clear commitment from the customer
to become involved in the development process and
where there are not a lot of external rules and
regulations that affect the software.
• Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.
Chapter 3 Agile software development
15
Plan-driven and agile development
• Plan-driven development
– A plan-driven approach to software engineering is based
around separate development stages with the outputs to be
produced at each of these stages planned in advance.
– Not necessarily waterfall model – plan-driven, incremental
development is possible
– Iteration occurs within activities.
• Agile development
– Specification, design, implementation and testing are interleaved and the outputs from the development process are
decided through a process of negotiation during the
software development process.
Chapter 3 Agile software development
16
Plan-driven and agile specification
Chapter 3 Agile software development
17
Agile methods
•
•
•
•
•
•
•
•
•
•
•
•
XP
Scrum
Crystal
Feature Driven
Open Source
Software Develop
RUP (AUP)
Dynamic Systems
Develop Method
Adaptive Software
Develop
Synch and stabilize
SE 501 Dr. Basit Qureshi
18
Agile methods
Common characteristics
• Individuals and Interactions over Processes and
Tools
– Team dynamics
• experience mix, team size
– Physical workspace, communality, meetings
• Working Software over Comprehensive
Documentation
–
–
–
–
Code primary artifact
Iterative (subscription)
Value to the customer
QA inherent
SE 501 Dr. Basit Qureshi
19
Agile methods
• Customer Collaboration over Contract Negotiation
–
–
–
–
Customer Onsite (Involved/Knowledgeable)
Requirements Centric
Rapid Return of Perceived Value
Customer Expectation Management
• Responding to Change over Following a Plan
– Developer / Customer Team
– Emergent Requirements
– Short Iterations
• Smaller changes
– Adaptation
SE 501 Dr. Basit Qureshi
20
Why Agile methods
What agile proponents say:
• Flexibility
– Market Changes
– Technology Changes (Moore’s Law)
– Unclear Requirements
• More coding, less paper-work
• Higher quality, quicker
SE 501 Dr. Basit Qureshi
21
Why Agile methods
What the opponents say:
• No plan, no structure
– Architecture?
– Easily derailed
• Inefficient use of developers
– pair programming
• No documentation
• Unrealistic customer involvement
SE 501 Dr. Basit Qureshi
22
Why Agile methods
“More than 2/3’s of all corporate IT
organizations will use some form of
agile software development process
in the next 18 months.”
Giga Information Group Inc., 2002
• Cutter Report “Agile vs. Heavy”
• Use is increasing
SE 501 Dr. Basit Qureshi
23
Why Agile methods
And now.. Chaos Report published in 2012.
• 49% of businesses say most of their company is using
Agile development
• 52 % of customers are happy or very happy with Agile
projects
• The number of those who plan to implement agile
development in future projects has increased from
59% in 2011 83% in 2012.
• The most popular Agile method used is Scrum (52%)
SE 501 Dr. Basit Qureshi
24
Weakness of Agile methods
• Communication is critical
• Projects with Non- Decomposability / Coupled
Functionality
• Scalability
• Reliance on Corporate Knowledge
• – Document at End
• Maintenance
• Long Life Cycle
SE 501 Dr. Basit Qureshi
25
Weakness of Agile methods
• Centralized management control
• “Big” Specifications
• Required Documentation
– Safety Critical
• Non-flexible work environment
• Fixed Price and Scope
SE 501 Dr. Basit Qureshi
26
Agile methods
• Agile center piece:
Coding
• Emphasizing what we do best
– What we prefer to do
• Lack of formal design, architecture
• Lack of documentation
– But makes you think about what is important
SE 501 Dr. Basit Qureshi
27
Agile methods
Some Agile methods users
• Microsoft
• Thoughtworks
• Valtech Technologies
• RADsoft
• Boeing
– < 5 on a team
• Al Elm Information Security
• Arabian Electronics Co
SE 501 Dr. Basit Qureshi
28
RUP
SE 501 Dr. Basit Qureshi
29
RUP
• The Rational Unified Process (RUP) is an iterative
software development process framework created by
the Rational Software Corporation, a division of IBM
since 2003
• RUP is not a single concrete prescriptive process, but
rather an adaptable process framework, intended to
be tailored by the development organizations and
software project teams that will select the elements of
the process that are appropriate for their needs
SE 501 Dr. Basit Qureshi
30
RUP
• Four project lifecycle phases
1. Inception Phase:
– Stakeholders, Requirements understanding, cost/schedule
estimates, architectural prototype, compare actual expenditures
versus planned expenditures.
2. Elaboration Phase:
– Most of the use-case descriptions are developed (80%), software
architecture, development plan for the overall project, Business
case and risk list.
3. Construction Phase
–
Build the software system, Software Release.
4. Transition Phase
–
Transit from development to production, training, testing
SE 501 Dr. Basit Qureshi
31
RUP Outline – Phases vs iterations
SE 501 Dr. Basit Qureshi
32
RUP
Strengths:
• Structured
• Iterative
• Use Cases – strong concept, used widely
• Tied to UML
• Robust tool support
• Tailor-able / Scalable
• “Agile” ?
SE 501 Dr. Basit Qureshi
33
RUP
Weaknesses
• Use cases – do they work for all projects?
• Learning curve
– Tied to tools
– UML
• Architecture?
• Non functional requirements
– Quality Attributes?
SE 501 Dr. Basit Qureshi
34
RUP
Center piece:
Model analysis
• Modeling allows stakeholders to understand the
problem
• Great for functionality
• Not so good for Quality Attributes
SE 501 Dr. Basit Qureshi
35
PSP / TSP
• Personal Software Process (PSP) 1989’
– structured software development process that is
intended to help software engineers understand
and improve their performance, by using a
"disciplined, data-driven procedure"
• Team Software Process (TSP) 2000’
– designed to help teams of managers and engineers
organize projects and produce software products
• The initial version of the TSP was developed and piloted by
Watts Humphrey in the late 1990s
SE 501 Dr. Basit Qureshi
36
PSP / TSP
• Builds on Personal Software Process (Pre-requisite)
Prevent defects earlier
• Defined framework - Scripted
–
–
–
–
–
–
Cyclic, iterative
Standard measures for quality and performance
Precise data collection- on almost everything
Established Roles
Discipline and guidance
Post Mortem each cycle – find the problems
• CMM…
SE 501 Dr. Basit Qureshi
37
PSP / TSP
Every cycle produces an artifact
A Team Software Process Cycle:
1- Strategy
2- Plan
3- Requirements
4- Design
5- Implementation
6- Test
7- Postmortem
SE 501 Dr. Basit Qureshi
38
PSP / TSP
TSP is document driven
• The “Good” of TSP
–
–
–
–
–
Structured
Scripted
Highly defined
New teams, or ones with no structure
SEI has data on about 20 projects
• The “other”
– Possible problems with change/flexibility
– Requirements?
– Documentation
SE 501 Dr. Basit Qureshi
39
PSP / TSP
• TSP centerpiece: Data
Collection
• Only source of “bugs” is humans
• Developers on the whole are unstructured and
tend towards “hacking”
• Need to identify source and mitigate problem
SE 501 Dr. Basit Qureshi
40
PSP / TSP users
•
•
•
•
•
U. S. Navy
Microsoft
Xerox
Bechtel – Bettis
Advance Information Systems
SE 501 Dr. Basit Qureshi
41
ACDM
• Architecture Centric Development Method
• ACDM is an iterative development method
– iteratively refines and reviews the architecture until it is
deemed fit for the purpose
– permits iteration in the production of the
elements/system/products
• ACDM has 7 stages in the development method.
• ACDM proposed by Anthony J. Lattanze of the of SEI at CMU,
2009.
SE 501 Dr. Basit Qureshi
42
ACDM
SE 501 Dr. Basit Qureshi
43
ACDM
Strengths:
• Product and Architectural focus.
• Agile and relatively lightweight.
• Structured but flexible and tailorable.
• Iterative.
• Derived from Studio Practitioners.
• Provides guidance for roles, activities, and artifacts.
• Derives requirements (architectural drivers) from
business drivers.
SE 501 Dr. Basit Qureshi
44
ACDM
Weaknesses:
• Not a lot of industrial experience or data.
• Unclear how well ACDM scales up to large projects.
• Still maturing.
• No tool support or templates.
• Depends upon a relatively good understanding of
architectural concepts.
SE 501 Dr. Basit Qureshi
45
ACDM
Centerpiece: Architecture
•
•
•
•
Complexity/scope driving need for more abstraction
Key to describing and predicting quality attributes
Lots of development and research
Easily misunderstood
SE 501 Dr. Basit Qureshi
46
CHOOSING SUITABLE SDLC
SE 501 Dr. Basit Qureshi
47
Choosing suitable SDLC
• Looking for a recipe… .
– There is no silver bullet
– Do not tailor your project to a process, instead
tailor the “right process”
• Supermarket shopping
– Do not pick all the “best” techniques within
processes and mix them together
– But you can use some in tailoring
SE 501 Dr. Basit Qureshi
48
Choosing suitable SDLC
SE 501 Dr. Basit Qureshi
49
Choosing suitable SDLC
• “Choose Your Weapon Wisely” Justin Rockwood 2003.
• Describes a weighted matrix model
– Weakness
– Push
– Strength
• Compares suitability of 5 methods
– RUP
– MS Synch and Stabilize
– TSP
– XP
– Scrum
SE 501 Dr. Basit Qureshi
50
Choosing suitable SDLC
• Weighted score for following project characteristics
–
–
–
–
–
–
–
–
–
–
Average team size and total developers
Product size and complexity
Developer competence and experience
“Hacker sentiment”
Management style
Organization wide processes
New process adoption
Type of product
Requirements stability
Requirements traceability
SE 501 Dr. Basit Qureshi
51
Choosing suitable SDLC
Example of determining total number of developers
SE 501 Dr. Basit Qureshi
52
Choosing suitable SDLC
Example of determining type of project
SE 501 Dr. Basit Qureshi
53
Choosing suitable SDLC
Add up scores
• 11 project areas
• But…
– Not definitive – Start point for research
• General direction
• Tied scores, or little variation
– Lower scoring method may still be suitable
– Not complete, needs more work
• Weighting some criteria more than others?
• Defining other processes
SE 501 Dr. Basit Qureshi
54
Choosing suitable SDLC
Balancing…!
SE 501 Dr. Basit Qureshi
55
Choosing suitable SDLC
Personnel discriminator…!
SE 501 Dr. Basit Qureshi
56
Choosing suitable SDLC
Apply discriminators
–
–
–
–
Criticality – Measured by loss, annoyance to $ to life
Size – gradient on this?
Cultural – chaos or planned
Dynamism- volatility of requirements
• Closer to center promotes Agile
SE 501 Dr. Basit Qureshi
57
Choosing suitable SDLC
• The methods shown just point to the right direction
and are not absolute answers
– Analysis of current method
• Plan any adoption of a new method
• ROI is important
– As is cost to benefit
• All methods work for the right
– Project
– Team
– Organization
(But some may be better)
SE 501 Dr. Basit Qureshi
58
Summary
• Continued SDLCs
• Choosing the appropriate SDLC for project
• Assignment #2: Group work
SE 501 Dr. Basit Qureshi
59