Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "SE 501 Software Development Processes Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 2."— Presentation transcript:

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 Qureshi2

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 Qureshi3

4 CAPABILITY MATURITY MODEL REVISITED Roger Pressman, Software Engineering: A Practitioners Approach SE 501 Dr. Basit Qureshi4

5 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 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 7 Five Levels of Software Process Maturity

8 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 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 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 11 Visibility into the Software Process

12 12 Probability of Schedule and Budget

13 13 The CMM Structure

14 14 Key Process Areas

15 15 Software Process Assessments

16 ESSENCE OF SOFTWARE CAPABILITY SE 501 Dr. Basit Qureshi16

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 Qureshi17

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 Qureshi18

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 Qureshi19

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 Qureshi20

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 Qureshi21

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

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 Qureshi23

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 Qureshi24

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 Qureshi25

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 Qureshi26

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 Qureshi27

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 Qureshi28

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 Qureshi29

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 Qureshi30

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 Qureshi31

32 SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) SE 501 Dr. Basit Qureshi32

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 Qureshi33

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

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

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 Qureshi36

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 Qureshi37

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 Qureshi38

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 Qureshi39

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

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 Qureshi41

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 Qureshi42

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 Qureshi43

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 Qureshi44

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 Qureshi45

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 Qureshi46

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

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 Qureshi48

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 Qureshi49

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 evolved overtime to some predetermined final state SE 501 Dr. Basit Qureshi50

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

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

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 Qureshi53

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 Qureshi54

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 Qureshi55

56 Rapid Application Development Model SE 501 Dr. Basit Qureshi56

57 Rapid Application Development Model Phases of RAD 1.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? 2.Data Modeling Data from business modeling is refined into a set of data objects that are needed to support the business 3.Process Modeling Transformed into information flow 4.Application Generation Typically 4GL CASE tools are used SE 501 Dr. Basit Qureshi57

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 Qureshi58

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 Qureshi59

60 Evolutionary Models SE 501 Dr. Basit Qureshi60

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 Qureshi61

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

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 Qureshi63

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 Qureshi64

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 Qureshi65

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 Qureshi66

67 Spiral Model SE 501 Dr. Basit Qureshi67

68 68 Spiral Model (Diagram) ‘pressman 7 th ed Start Communication Planning Modeling ConstructionDeployment

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 Qureshi69

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 Qureshi70

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 Qureshi71

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 Qureshi72

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 SE 501 Dr. Basit Qureshi73 Boehm, B. et al., "Using the WinWin Spiral Model: A Case Study." IEEE Computer, July 1998, pp IEEE Computer, July 1998,

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 Qureshi74

75 V-Model SE 501 Dr. Basit Qureshi75 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.

76 V-Model SE 501 Dr. Basit Qureshi76

77 V-Model SE 501 Dr. Basit Qureshi77 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

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

79 V-Model SE 501 Dr. Basit Qureshi79 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

80 V-Model SE 501 Dr. Basit Qureshi80 Advantages: – Every stage is tested Disadvantages – 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.

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 Qureshi81

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 Qureshi82

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 Qureshi83

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 Qureshi84

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 Qureshi85

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 Qureshi86

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


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

Similar presentations


Ads by Google