Software Processes. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University

Transcription

1 Software Processes Minsoo Ryu Hanyang University

2 Topics covered 1. What is a Software Process? 2. Software Process Activities 3. Waterfall Development 4. Iterative and Incremental Development 5. Others 1. Spiral Development 2. Rapid Application Development 3. V Model 6. Software Process Standard 2 2

3 What is a Software Process Ivar Jacobson, Grady Booch, and James Rumbaugh A process defines who is doing what, when, and how to reach a certain goal It is widely accepted that the quality of the product depends on the quality of the process! Synonyms include software life cycle and software development process There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process 3 3

4 4 Major Software Processes Requirements engineering Design and implementation Verification and validation Evolution 4 4

5 Requirements Engineering The process of establishing what services are required and the constraints on the system s operation and development Requirements engineering process Feasibility study (technologies, deadline, budget); Requirements elicitation and analysis; Requirements specification; Requirements validation 5 5

6 Design and Implementation The process of converting the system specification into an executable system Design Design a software structure that realizes the specification; Implementation Translate this structure into an executable program; The activities of design and implementation are closely related and may be inter-leaved 6 6

7 Verification and Validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer Involves checking and review processes and system testing System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system 7 7

8 Evolution Software is inherently flexible and can change As requirements change through changing business circumstances, the software that supports the business must also evolve and change Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new 8 8

9 Waterfall Development The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance The origin of the term "waterfall" is often cited to be an article published in 1970 by Winston W. Royce ( ) although Royce did not use the term "waterfall" in this article Ironically, Royce was actually presenting this model as an example of a flawed, non-working model (Royce 1970) 9 9

10 Waterfall Development 10 10

11 Waterfall Development The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected In pure Waterfall model, phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them However, there are various modified waterfall models that may include slight or major variations upon this process 11 11

12 Criticism of the Waterfall Development Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process Few business systems have stable requirements The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites 12 12

13 Sashimi Model The sashimi model (so called because it features overlapping phases, like the overlapping fish of Japanese sashimi) was originated by Peter DeGrace It is sometimes referred to as the "waterfall model with overlapping phases" or "the waterfall model with feedback Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases of the waterfall model that would typically "precede" others in the pure waterfall model. This helps alleviate many of the problems associated with the Big Design Up Front philosophy of the waterfall model 13 13

14 Iterative and Incremental Development 14 14

15 Iterative and Incremental Development increment # n Communicat ion Planning Modeling analysis design Const ruct ion code test Deployment delivery feedback increment # 2 delivery of nt h increment Communicat ion Planning Modeling increment # 1 analysis design Const ruct ion code test Deployment delivery feedback delivery of 2nd increment Communicat ion Planning Modeling analysis design Const ruct ion code test Deployment delivery feedback delivery of 1st increment project calendar time 15 15

16 Incremental and Iterative Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed The alternative to incremental development is to develop the entire system with a "big bang" integration Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system It does not presuppose incremental development, but works very well with it 16 16

17 Advantages of Iterative and Incremental Development Customer value can be delivered with each increment so system functionality is available earlier Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest priority system services tend to receive the most testing 17 17

18 Other Software Processes Spiral Development Rapid Application Development V Model 18 18

19 Spiral Development Proposed by Barry Bohem, 1988 Process is represented as a spiral rather than as a sequence of activities with backtracking. 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 Risks are explicitly assessed and resolved throughout the process 19 19

20 Spiral Development 20 20

21 RAD (Rapid Application Development) Team # n Modeling business modeling data m odeling process m odeling Communication Team # 2 Modeling business modeling data modeling process modeling Construction component reuse autom atic code generation testing Planning Team # 1 Modeling business modeling dat a modeling process modeling Const ruct ion component reuse automatic code generation t est ing Deployment int egrat ion delivery feedback Construction component reuse aut omat ic code generat ion testing days 21 21

22 V Model The V-model is a software development model which can be presumed to be the extension of the waterfall model The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing The V-model can be said to have developed as a result of the evolution of software testing The tests in the ascending (Validation) hand are derived directly from their design or requirements counterparts in the descending (Verification) hand The V can also stand for the terms Verification and Validation 22 22

23 V Model 23 23

24 ISO ISO is an ISO standard for software lifecycle processes It aims to be 'the' standard that defines all the tasks required for developing and maintaining software Standard ISO establishes a process of life cycle for software, including processes and activities applied during the acquisition and configuration of the services of the system Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes 24 24

25 ISO The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it The standard is based on two basic principles: modularity and responsibility Modularity means processes with minimum coupling and maximum cohesion Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved The set of processes, activities and tasks can be adapted according to the software project These processes are classified in three types: basic, support and organizational The support and organizational processes must exist independently of the organization and the project being executed The basic processes are instantiated according to the situation 25 25