Software Development Processes
The Processes • Software Development Process: a • Waterfall defined by Royce (seventies) structured and progressive refinement • Introduced to address the “software from idea to an actual system crisis” • Processes • New processes proposed to: – Waterfall – Increase flexibility in the organization of – Prototype development activities – Incremental – Improve: – Spiral * User satisfaction (building systems that are closer to user needs) – V-Model * Efficiency (building systems faster) – Cleanroom * Time and costs (being more reliable with estimations) – RUP * Quality – XP • Heavy-weight vs. Agile – SCRUM – RAD – ASAP – MSF – DFDM spm � 2
Waterfall Model • Managing the development of I SYSTE M large software systems (Winston W. Royce) I ANALYSIS PROGRAM DESIGN I coo,.o TESTING I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. spm � 3 I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs. One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software without these steps, but generally these phases are managed with relative ease and have little impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbit mechanics, spacecraft attitude determination, mathematical optimization of payload activity and so forth, but when these departments have completed their difficult and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their difficult and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases. However, I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks. 329
� 4 • Managing the development of large software systems (Winston W. Royce) Irl o i0 . i . . IIII ~,- ,,*,1 = • . ~ illl ~$~ z~_~ u, m E X E 8 "0 Ill N ~, .~- r" .2 / " Waterfall Model z_ ,,,. ~ ~ E ~OLU /, a. .~ N N I0: wZ t- /oo i ,~ g ~ I , ~ , - Z w i-,<~ LL spm 333
Waterfall Model • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • This model is only appropriate when: – The requirements are well-understood and/or – The level of formality is high (e.g. it is essential to “freeze” the requirement document) spm � 5
Waterfall Model • Managing the development of I SYSTEM ! large software systems REQUIREMENTSIBI~ (Winston W. Royce) ~"'i so,w.,~ I ANALYSIS ~1111~ I I p R I ~ O G R A M ~lll I CODING Ii TESTING OPERATIONS Figure 3. Hopefully, the ~terat=ve interact=on between the various phases is confined to successive steps. .~oo,.~-,..Sl.,~ I SYSTEM "1 spm � 6 I so,w..~ !. I ANALYSIS PROGRAM DESIGN I coo,.G I,~ ! TESTING I O .ATO.S ! I Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps. 330
Waterfall Variations • Sashimi waterfall: activities are allowed to overlap • Waterfall with sub projects: implementation of different components proceeds in parallel • Waterfall with risk reduction: an initial risk analysis helps mitigate risks in later phases of implementation spm � 7
V-Cycle • Structural support for backtracking Acceptance • Focus on testing Requirements Testing • German standard System Specification Testing Architectural Integration Design Testing Coding Unit Testing spm � 8
Rational Unified Process spm � 9
Rational Unified Process • Process introduced by Rational in the eighties (the same company of UML) [Rational is now IBM] � • Process organized in two dimension: – phases, organized in iterations, correspond to different levels of maturity – workflows, focusing on a specific software development concern • Phases are organized in iterations • Workflows are overlapping and characterized by levels of intensity spm � 10
Rational Unified Process Best Practices • Six main practices define guiding principles of RUP: – Develop software iteratively – Manage requirements (including evaluation of product alternatives) – Use component-based architectures (robust components) – Visually model software (simple and unambiguous representation to build a shared vision) – Verify software quality – Control changes to the software (both for quality and management) spm � 11
Open Unified Process • The evolution of RUP • Open source • “Agile” • http://epf.eclipse.org/ wikis/openup/ spm � 12
Spiral • A Spiral Model of Software Development and Enhancement (Barry W. Boehm) Evaluate alternatives, risks Commitment Review partition Reauirements besign /T---i \ \ DeveloD- 1 !‘,“I’p-y 1 Design validation Plan next phases verify I next-level product Figure 2. Spiral model of the software process. spm � 13 Additionally, it would face a formidable The spiral model difficulties. Automatic transformation knowledge-base-maintenance problem in capabilities are only available for small products in a few limited areas: spread- dealing with the rapidly increasing and The spiral model of the software process evolving supply of reusable software com- sheets, small fourth-generation language (see Figure 2) has been evolving for several ponents and commercial software applications, and limited computer- years, based on experience with various products. (Simply consider the problem of science domains. The transform model refinements of the waterfall model as tracking the costs, performance, and fea- also shares some of the difficulties of the applied to large government software tures of all commercial database manage- evolutionary development model, such as projects. As will be discussed, the spiral ment systems, and automatically choosing the assumption that users’ operational sys- model can accommodate most previous the best one to implement each new or tems will always be flexible enough to sup- models as special cases and further pro- changed specification.) port unplanned evolution paths. COMPUTER 64
Spiral • Defined by Barry W. Boehm (end of the ‘80s) • Iterative: software is developed in cycles • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required • Alternative and risk-aware: first phases include an evaluation of possible alternatives and an assessment of the risks • The paper includes a list of common project risks (*)(not only process, also practices) (*) which we will look at during the Risk Management lessons spm � 14
Spiral • Advantages – Matching to contract software – Alternative and Risk driven – Difficulties in coming out – It accommodates different with estimations at the software development beginning practices (among which – Flexibility reuse and automatic code generation) – Intrinsically fit for software evolution (maintenance is another loop in the spiral) • Disadvantages spm � 15
Prototype Approach • Once the high level requirements are fixed, a prototype of the application is developed (e.g. the GUI) and evaluated with the client • Breadth and depth of the prototype – Horizontal prototype: focus on the application – Vertical prototype: focus on a specific function • Types of prototypes: – Throw-away: the prototype demonstrates the system (but it is not the system!) – Evolutionary: the prototype evolves to become the system spm � 16
Prototype Approach High Level Detailed Requirements Requirements Architectural Design Implementation Prototype Testing (V&V) Evaluation spm � 17
Recommend
More recommend
