se 501 software development processes dr. basit qureshi college of computer science and information...
TRANSCRIPT
SE 501 Software Development Processes
Dr. Basit QureshiCollege of Computer Science and Information Systems
Prince Sultan University
Lecture for Week 3
SE 501 Dr. Basit Qureshi 2
Contents
• SDLC’s continued– Agile, RUP, TSP, ACDM
• Choosing suitable SDLC• Summary• Discussion on Assignment #2
SE 501 Dr. Basit Qureshi 3
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 4
SDLC CONTINUED
SE 501 Dr. Basit Qureshi 5
SDLC continued
• Last week– Ad Hoc– Classical (Water fall)– Prototype– RAD– Incremental– Spiral– WinWin– V model– Chaos
SE 501 Dr. Basit Qureshi 6
SDLC: More recent
• Agile• RUP• TSP• ACDM
SE 501 Dr. Basit Qureshi 7
SDLC: More recent
SE 501 Dr. Basit Qureshi 8
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 9
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”
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.
10Chapter 3 Agile software development
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.
12Chapter 3 Agile software development
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 negotiationResponding 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.
14Chapter 3 Agile software development
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 inter-
leaved and the outputs from the development process are decided through a process of negotiation during the software development process.
16Chapter 3 Agile software development
Plan-driven and agile specification
17Chapter 3 Agile software development
SE 501 Dr. Basit Qureshi 18
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 19
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 20
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 21
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 22
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 23
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 24
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 25
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 26
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 27
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 28
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 29
RUP
SE 501 Dr. Basit Qureshi 30
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 31
RUP
• Four project lifecycle phases1. 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 32
RUP Outline – Phases vs iterations
SE 501 Dr. Basit Qureshi 33
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 34
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 35
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 36
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 37
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 38
PSP / TSP
Every cycle produces an artifactA Team Software Process Cycle:
1- Strategy2- Plan3- Requirements4- Design5- Implementation6- Test7- Postmortem
SE 501 Dr. Basit Qureshi 39
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 40
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 41
PSP / TSP users
• U. S. Navy• Microsoft• Xerox• Bechtel – Bettis• Advance Information Systems
SE 501 Dr. Basit Qureshi 42
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 43
ACDM
SE 501 Dr. Basit Qureshi 44
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 45
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 46
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 47
CHOOSING SUITABLE SDLC
SE 501 Dr. Basit Qureshi 48
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 49
Choosing suitable SDLC
SE 501 Dr. Basit Qureshi 50
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 51
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 52
Choosing suitable SDLCExample of determining total number of developers
SE 501 Dr. Basit Qureshi 53
Choosing suitable SDLCExample of determining type of project
SE 501 Dr. Basit Qureshi 54
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 55
Choosing suitable SDLCBalancing…!
SE 501 Dr. Basit Qureshi 56
Choosing suitable SDLCPersonnel discriminator…!
SE 501 Dr. Basit Qureshi 57
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 58
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 59
Summary
• Continued SDLCs• Choosing the appropriate SDLC for project• Assignment #2: Group work