Presentation is loading. Please wait.

Presentation is loading. Please wait.

SE 501 Software Development Processes

Similar presentations

Presentation on theme: "SE 501 Software Development Processes"— 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 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

Download ppt "SE 501 Software Development Processes"

Similar presentations

Ads by Google