SE 501 Software Development Processes

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. 2000. • 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. 33-44 • www.waterfall-model.com • Iterative vs. waterfall software development Computer World 2004 SE 501 Dr. Basit Qureshi

4. 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. 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. 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. 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) • 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 evolvedovertime to some predetermined final state SE 501 Dr. Basit Qureshi