1. SE 501 Software Development Processes
Dr. Basit Qureshi
College of Computer Science and Information Systems
Prince Sultan University
Lecture for Week 2

2. Contents CMM Re-visited Essence of Software Capability
Software Development Lifecycles
State of the Art
Choosing the best SDLC
Summary
SE 501 Dr. Basit Qureshi

3. Bibliography
What is Rapid Application Development, CASEMaker Inc
Pressman, textbook, Chapter 3
Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A., and Madachy, R., "Using  the WinWin Spiral Model: A Case Study", IEEE Computer, July 1998, pp
Iterative vs. waterfall software development Computer World 2004
SE 501 Dr. Basit Qureshi

4. Capability Maturity Model Revisited
Roger Pressman, Software Engineering: A Practitioners Approach
Capability Maturity Model Revisited
SE 501 Dr. Basit Qureshi

5. Capability Maturity Model (SW-CMM)
Developed in 1987 by the Software Engineering Institute (SEI) at Carnegie-Mellon University under the sponsorship of DARPA
Described in the book Managing the Software Process in 1989 by Watts Humphrey
Published as a separate document: Capability Maturity Model for Software in 1991

6. Immature Software Organizations
Software processes are generally improvised
If a process is specified, it is not rigorously followed or enforced
The software organization is reactionary
Managers only focus on solving immediate (crisis) problems
Schedules and budgets are routinely exceeded because they are not based on realistic estimates
When hard deadlines are imposed, product functionality and quality are often compromised
There is no basis for judging process quality or for solving product or process problems
Activities such as reviews and testing are curtailed or eliminated when projects fall behind schedule

7. Five Levels of Software Process Maturity

8. Characteristics of Each Level
Initial Level (Level 1)
Characterized as ad hoc, and occasionally even chaotic
Few processes are defined, and success depends on individual effort
Repeatable (Level 2)
Basic project management processes are established to track cost, schedule, and functionality
The necessary process discipline is in place to repeat earlier successes on projects with similar applications

9. Characteristics of Each Level (continued)
Defined (Level 3)
The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization
All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software
Managed (Level 4)
Detailed measures of the software process and product quality are collected
Both the software process and products are quantitatively understood and controlled

10. Characteristics of Each Level (continued)
Optimized (Level 5)
Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies

11. Visibility into the Software Process

12. Probability of Schedule and Budget

13. The CMM Structure

14. Key Process Areas

15. Software Process Assessments

16. Essence of Software Capability
SE 501 Dr. Basit Qureshi

17. What is a method?
There is no one method suitable for all problem domains
All good methods are based on timeless principles like abstraction and information hiding
SE 501 Dr. Basit Qureshi

18. Remember
The only source of defects in software development is the human element
Processes are needed to control the human variable, to identify problem sources, to make outcomes repeatable.
SE 501 Dr. Basit Qureshi

19. Two major types of frameworks
Artifact centric – prescribes the kinds of artifacts must be produced
example: MIL-STD 2167
Activity centric – prescribes activities that must be done
example: CMM (and CMMI)
Most process frameworks exhibit properties of both artifact and activity centricism
SE 501 Dr. Basit Qureshi

20. CMM and CMMi….? Tells you what processes to do, but not how to do them
CMM makes no assumption of development lifecycle model!
CMM suffers from a reputation of an old, stodgy, high ceremony waterfall oriented process.
CMM is NOT a PROCESS!!!
CMM is a distillation of best practices!
SE 501 Dr. Basit Qureshi

21. Artifact Centric Example: MIL- STD 2167A – 2
Largely describes what must be produced not how to produce anything:
“How” is vicariously described by referencing other standards
What must be done by the developers is implied in the underlying waterfall structure of the document
Artifacts describe preconditions, post-conditions, and completing artifacts implies some level of progress
SE 501 Dr. Basit Qureshi

22. Process Capability?
Describes range of expected results by following a given software process
Measuring the process
Explicitly defined, managed, measured, controlled, utilized
SE 501 Dr. Basit Qureshi

23. Defining Processes When defining processes:
Be sure that you know why you are developing a process
Ensure that processes are in-line with business goals
Involve stakeholders - they should develop the process, you should facilitate
Be sure that the granularity is appropriate for organization/program/project
SE 501 Dr. Basit Qureshi

24. Some experiences
New process converts are like new social workers, policemen, and clergymen – they all want to save the world from their own devices and they are sure they know how to do it best!
Curb your enthusiasm – it will turn more people off than win converts.
SE 501 Dr. Basit Qureshi

25. Some experiences Be patient!
Establishing and improving software processes takes LOTS of time and money.
You had better have a strategy and everyone better know about it.
Get ready for disappointment.
Change advocacy is a lesson for another day.
SE 501 Dr. Basit Qureshi

26. Some experiences
If you use a process framework to establish or improve processes:
Understand and follow the spirit of the framework, not the blind letter of the law.
Tailor, measure, tailor, measure...
Keep your farmers wits about you at all times!
SE 501 Dr. Basit Qureshi

27. Myths about process Belief that any one model is the Silver Bullet
Mandating processes from above without involving process owners
Beginning a process improvement effort without a baseline of current practices
SE 501 Dr. Basit Qureshi

28. Myths about process
Unwillingness or inability to interpret, tailor, or apply judgment regarding a maturity model in light of business needs
undertaking process improvement without consideration of business goals
following the “letter of the law” instead of the “intent of the law”
SE 501 Dr. Basit Qureshi

29. Myths about process
The assumption that high quality processes automatically mean high quality designs, code, and implementations.
chances are better that the quality of these artifacts will be better, but there is no guarantee
SE 501 Dr. Basit Qureshi

30. Myths about process
The assumption that low maturity organizations will automatically produce low quality designs, code, and implementations
successful organizations that have low maturity processes typically have lots of virtuosos
often these organizations produce reasonable, even innovative systems, but the results are unpredictable
SE 501 Dr. Basit Qureshi

31. Myths about process
High maturity level organizations are guaranteed to enjoy high profitability.
High maturity can only be achieved through high ritualization.
SE 501 Dr. Basit Qureshi

32. Software Development Lifecycle (SDLC)
SE 501 Dr. Basit Qureshi

33. What is a S/W Life Cycle?
“The series of stages in form and functional activity through which an organism passes between successive recurrence of a specified primary stage” – Webster (1892)
“Period of time that begins when a software product is conceived and ends when the product is retired from use” – Don Reifer (1997)
SE 501 Dr. Basit Qureshi

34. Life Cycles Ad Hoc Classical (Water fall) Prototype RAD Incremental
Spiral
WinWin
V model
Chaos
SE 501 Dr. Basit Qureshi

35. Scope, Time, Resources, Quality
Life Cycles
Scope, Time, Resources, Quality
(remember these throughout the course)
Stakeholders
Environments
Business / Market
Cultures
Moral, legal constraints
SE 501 Dr. Basit Qureshi

36. What SDLC would fit my project best?
Life Cycles
So when looking at projects we need to ask:
What SDLC would fit my project best?
(Is this better than what type of project would fit each SDLC?)
SE 501 Dr. Basit Qureshi

37. Ad Hoc Legacy Code – Test – Code – Test… (Build & Fix model)
Becomes a mess, chuck it, start over
Design (high level) – Code – Test – Code –Test…
(Reality was Code - Test – Code – Test – Document the resulting design)
SE 501 Dr. Basit Qureshi

38. Classic – Water fall Model
First proposed in 1970 by W.W. Royce
Development flows steadily through:
requirements analysis, design implementation, testing, integration, and maintenance.
Royce advocated iterations of waterfalls adapting the results of the precedent waterfall.
Referred to as a linear sequential model, document-driven model
SE 501 Dr. Basit Qureshi

39. Classic – Water fall Model
Technology had some influence on the viability of the waterfall model.
slow code, compile, and debug cycles
Reflected the way that other engineering disciplines build things.
Formed the basis of the earliest software process frameworks
Waterfall is still used today (but no one will admit it)
SE 501 Dr. Basit Qureshi

40. Classic – Water fall Model
Communication
Project initiation
Requirements gathering
Planning
Estimating
Scheduling
Tracking
Modeling
Analysis
Design
Construction
Code
Test
Deployment
Delivery
Support
Feedback
SE 501 Dr. Basit Qureshi

41. Classic – Water fall Model
Advantages?
Staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client.
Emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met.
SE 501 Dr. Basit Qureshi

42. Classic – Water fall Model
Advantages?
Improves quality; it's much easier to catch and correct possible flaws at the design stage than at the testing stage
Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when team members are dispersed in different locations
SE 501 Dr. Basit Qureshi

43. Classic – Water fall Model
Problems?
Requirements Gathering: very often, customers don't really know what they want up-front; rather, what they want emerges out of repeated two-way interactions over the course of the project.
is seen as somewhat unrealistic and unsuitable for the vagaries of the real world
SE 501 Dr. Basit Qureshi

44. Classic – Water fall Model
Problems?
given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult
SE 501 Dr. Basit Qureshi

45. Classic – Water fall Model
Problems?
Another criticism revolves around the model's implicit assumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation
Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design
SE 501 Dr. Basit Qureshi

46. Classic – Water fall Model
Problems?
Human Resources: the waterfall model implies a clear division of labor between, say, "designers", "programmers" and "testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient
In general, therefore, the model is recommended for use only in projects which are relatively stable and where customer needs can be clearly identified at an early stage.
SE 501 Dr. Basit Qureshi

47. Requirements gathering
Water fall reality…
Communication
Project initiation
Requirements gathering
Planning
Estimating
Scheduling
Tracking
Modeling
Analysis
Design
Construction
Code
Test
Deployment
Delivery
Support
Feedback
SE 501 Dr. Basit Qureshi

48. Prototype Model
The Prototyping Model is a systems development method in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed
SE 501 Dr. Basit Qureshi

49. Prototype Model When to deploy?
When it is very difficult to obtain exact requirements from the customer
User feedbacks from time to time
Completely built sample model is shown to user and based on feedback
SRS(System Requirements Specifications) document is prepared
SE 501 Dr. Basit Qureshi

50. Prototype Model Throw Away (Rapid) Evolutionary
Proof of concept – It can be done
End point unknown!
Evolutionary
Keep something
Different than incremental?
The evolutionary development model can be distinguished from the prototyping model in that
a final product is typically specified
the product features are evolved overtime to some predetermined final state
SE 501 Dr. Basit Qureshi

51. Rapid Prototype Model Prototype Idea Analysis Design Construction Code
Test
Deployment
SE 501 Dr. Basit Qureshi

52. Common Mis-use of Rapid Prototype Model
Idea
Prototype
Construction
Code
Test
Deployment
SE 501 Dr. Basit Qureshi

53. Prototype Model Advantages: Proof of concept
User gets a proper clarity and 'feel' of the functionality
Used for non-IT-literate people. Not good for specifications of requirements
Reduces risk of failure, as potential risks can be identified early and mitigation steps can be taken
Iterative
Time required to complete the project after getting final SRS reduced
SE 501 Dr. Basit Qureshi

54. Prototype Model Problems: Insufficient analysis
User confusion of prototype and finished system
Developer misunderstanding of user objectives
Developer attachment to prototype
Excessive development time of the prototype
Expense of implementing prototyping
If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost.
SE 501 Dr. Basit Qureshi

55. Rapid Application Development Model
RAD is a linear sequential development process model that emphasis an extremely short development cycle.
Rapid development is achieved by using a component based construction approach.
The RAD model is useful if requirements are well understood and project scope is constrained (controlled ).
SE 501 Dr. Basit Qureshi

56. Rapid Application Development Model
SE 501 Dr. Basit Qureshi

57. Rapid Application Development Model
Phases of RAD
Business Modeling
The information flow among business functions is modeled in a way that answers the following questions What information drive the business? What information is generated? Who generates it? Where does the information go? Who processes it?
Data Modeling
Data from business modeling is refined into a set of data objects that are needed to support the business
Process Modeling
Transformed into information flow
Application Generation
Typically 4GL CASE tools are used
SE 501 Dr. Basit Qureshi

58. Rapid Application Development Model
Suitable for:
Focused project scope where the business objectives are well defined and narrow
Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Decisions can be made by a small number of people who are available and preferably co-located.
The project team is small (preferably six people or less).
Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used.
SE 501 Dr. Basit Qureshi

59. Rapid Application Development Model
Un-Suitable for:
Broad project scope where the business objectives are obscure or broad.
Complex and voluminous data must be analyzed, designed and created within the scope of the project.
Many people must be involved in the decisions on the project
Project team is large or there are multiple teams
Technical requirements are tight for the equipment to be used
SE 501 Dr. Basit Qureshi

60. Evolutionary Models
SE 501 Dr. Basit Qureshi

61. Incremental
The incremental model prescribes developing and delivering the product in planned increments (or builds). = “Staged Delivery” model
The product is designed to be delivered in increments.
Each increments provides (in theory) more functionality than the previous increment.
SE 501 Dr. Basit Qureshi

62. Incremental Increment #1 Increment #2 Increment #3 Communication
Planning
Modeling
Construction
Deployment
Increment #1
Increment #2
Increment #3
SE 501 Dr. Basit Qureshi

63. Incremental Advantages:
User requirements are prioritized and the highest priority requirements are included in early increments.
Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
Generates working software quickly and early during the software life cycle.
More flexible - less costly to change scope and requirements.
Easier to test and debug during a smaller iteration.
Easier to manage risk because risky pieces are identified and handled during its iteration
SE 501 Dr. Basit Qureshi

64. Incremental Disadvantages: Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
Total cost is higher than waterfall.
Each phase of an iteration is rigid and do not overlap each other.
Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle
SE 501 Dr. Basit Qureshi

65. Incremental When to use:
Requirements of the complete system are clearly defined and understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available
There are some high risk features and goals.
How is this different from evolutionary development?
SE 501 Dr. Basit Qureshi

66. Spiral Model First defined by Barry Boehm 1988 Combines elements of:
evolutionary, incremental, and prototyping models
First model to explain
why iteration matters
How iteration could be used effectively
The term “spiral ” refers to successive iterations outward from a central starting point.
SE 501 Dr. Basit Qureshi

67. Spiral Model
SE 501 Dr. Basit Qureshi

68. Spiral Model (Diagram) ‘pressman 7th ed
Start
Communication
Planning
Modeling
Construction
Deployment 68

69. Spiral Model The goal is to
identify risks
focus on it early.
In theory, risk is reduced in outer spirals as the product becomes more refined.
Each spiral
starts with design goals
ends with the client reviewing the progress thus far and future direction
was originally prescribed to last up to 2 years
SE 501 Dr. Basit Qureshi

70. Spiral Model Advantages:
Spiral Life Cycle Model is one of the most flexible SDLC models in place
Project monitoring is very easy and effective. Each phase, as well as each loop, requires a review from concerned people.
Risk management is one of the in-built features of the model
Changes can be introduced later in the life cycle as well
Project estimates in terms of schedule, cost etc become more and more realistic as the project moves forward and loops in spiral get completed
It is suitable for high risk projects, where business needs may be unstable.
A highly customized product can be developed using this.
SE 501 Dr. Basit Qureshi

71. Spiral Model Disadvantages:
Cost involved in this model is usually high.
It is a complicated approach especially for projects with a clear SRS.
Skills required, to evaluate and review project from time to time, need expertise.
Rules and protocols should be followed properly to effectively implement this model. Doing so, through-out the span of project is tedious.
Due to various customizations allowed from the client, using the same prototype in other projects, in future, is difficult.
Not suitable for low risk projects.
Meeting budgetary and scheduling requirements is difficult
Amount of documentation required in intermediate stages makes management of project very complex affair.
SE 501 Dr. Basit Qureshi

72. Win Win Spiral Model Extension of the spiral approach.
The phase in this approach is same as the phase in the spiral approach.
SE 501 Dr. Basit Qureshi

73. Win Win Spiral Model
Adds three activities to the front end of each spiral cycle:
Identify the system or subsystem's key stakeholders
Identify the stakeholders' win conditions for the system or subsystem
Negotiate win-win reconciliations of the stakeholders' win conditions
Customer Wins by getting the product that fulfills most of the requirements
Development team wins by delivering software which is developed with all the requirements established
When to use: Time-bound releases
Boehm, B. et al., "Using the WinWin Spiral Model: A Case Study." IEEE Computer, July 1998, pp
SE 501 Dr. Basit Qureshi

74. V-Model
Often used in system engineering environments to represent the system development lifecycle.
summarizes the main steps taken to build systems not specifically software
describes appropriate deliverables corresponding with each step in the model.
SE 501 Dr. Basit Qureshi

75. V-Model
The V model is essentially a modified version of the Waterfall method.
Non-linear, in fact the stages turn back upwards after the coding phase is done so that it makes a V shape and hence the name – V Model.
SE 501 Dr. Basit Qureshi

76. V-Model
SE 501 Dr. Basit Qureshi

77. V-Model
Process relies on the verification from the previous steps before proceeding forward
Product from every phase needs to be checked and approved before moving forward.
This way of verification continues for all the stages and with subsequent phases
SE 501 Dr. Basit Qureshi

78. V-Model Stages: Development
Requirement Analysis : brainstorming and documentation reveal requirements
System Design: Overall design
Architecture Design : unit design
Module Design : sub- unit design
Development
SE 501 Dr. Basit Qureshi

79. V-Model Validation Unit testing : Each unit / sub-unit is tested
Integration / interface testing : determine flaws in the interfaces
System Testing : embedded requirements testing
Acceptance Testing : general requirements testing
Release Testing : product testing
SE 501 Dr. Basit Qureshi

80. V-Model Advantages: Disadvantages Every stage is tested
It assumes that the requirements do not change.
The design is not authenticated.
The Requirements are not verified.
At each stage there is a potential of errors.
The first testing is done after the design of modules which is very late and costs a lot.
SE 501 Dr. Basit Qureshi

81. Chaos Model
Extends the spiral and waterfall model defined by L.B.S. Raccoon [1995].
espouses the notion that the lifecycle must address all levels of a project, from the larger system to the individual lines of code
The whole project, system, modules, functions and each line of code must by defined, implemented, and integrated holistically.
SE 501 Dr. Basit Qureshi

82. Chaos Model
Chaos Theory underlies the fundamental concepts of the Chaos Model including:
Software projects are non-linear systems exhibiting random motion (linear systems are rare in nature)
Non-linear systems can be more than the sum of their parts.
To characterize the behavior of a non-linear system one needs principles to study the system as a whole and not just its parts in isolation (i.e. it is senseless to study architecture design in isolation).
SE 501 Dr. Basit Qureshi

83. Chaos Model
Chaos strategy resembles the way that programmers work toward the end of a project:
when they have a list of bugs to fix and features to create
usually someone prioritizes the remaining tasks
programmers fix them one at a time
Chaos strategy states that this is the only valid way to do the work.
SE 501 Dr. Basit Qureshi

84. Chaos Model Key points of chaos strategy include
Issues are incomplete programming tasks.
Resolving an issue means to bring it to stability.
Resolve the most important issues first.
The most important issues will be a combination of big, urgent, and robust, where
Big issues provide value to users as working functionality.
Urgent issues are time sensitive and would otherwise hold up other work if not completed sooner rather than later.
Robust issues are trusted and tested.
Work and schedules are derived from big, urgent, and robust issues.
SE 501 Dr. Basit Qureshi

85. Current State of the Art
Iterative, cyclic development
Agile Processes?
Software is grown rather than birthed whole
Short cycles, Small teams
Component development
More integration vice new development?
SE 501 Dr. Basit Qureshi

86. Choosing the Best SDLC DO NOT make your project fit a SDLC!!!
INSTEAD, find the right SDLC and tailor it to your project (if it can be).
Your organization may drive this
But any lifecycle, process should be seen as a tool to assist development, not an end in and of it self.
SE 501 Dr. Basit Qureshi

87. Summary CMM Re-visited Essence of Software Capability
Software Development Lifecycle
Choosing the best SDLC
SE 501 Dr. Basit Qureshi