02 software processes.ppt [호환 모드] -...

Real-Time Computing and Communications Lab., Hanyang Universityhttp://rtcc.hanyang.ac.kr

Real-Time Computing and Communications Lab., Hanyang Universityhttp://rtcc.hanyang.ac.kr

Software Processes

Minsoo Ryu

Hanyang University

2Real-Time Computing and Communications Lab., Hanyang University

http://rtcc.hanyang.ac.kr 2Real-Time Computing and Communications Lab., Hanyang Universityhttp://rtcc.hanyang.ac.kr

Topics covered

1. What is a Software Process?2. Software Process Activities3. Waterfall Development4. Iterative and Incremental Development5. Others

1. Spiral Development2. Rapid Application Development3. V Model

6. Software Process Standard



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



4 Major Software Processes

Requirements engineering Design and implementation Verification and validation Evolution



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



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



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



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



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 (1929–1995) 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)




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



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



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



Iterative and Incremental Development



Iterative and Incremental Development

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t d e l i v e r y f e e d b a c k

ana ly s is

des ign c ode

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nt h increment

increment # n

project calendar t ime


M o d e l i n gC o n s t r u c t i o n


ana ly s is des ign c ode

t es t


M o d e l i n gC o n s t r u c t i o n


analy s is des ign

c ode t es t



“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



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



Other Software Processes

Spiral Development Rapid Application Development V Model



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



Spiral Development



RAD (Rapid Application Development)

Communicat ion

Planning

Mode lingbusiness modeling dat a modeling process modeling

Const ruct ioncomponent reuse aut omat ic code generat ion t est ing

De ployme nt

6 0 - 9 0 days

Team # 1

Mo d elingbusiness m odel ing dat a m odel ing process m odel ing

Co nst ruct io ncom ponent reuse aut om at ic code generat ion t est ing

M o d e lin gbusiness m odeling data m odeling process m odeling

Co n st ru ct io ncom ponent reuse autom at ic code generat ion test ing

Team # 2

Team # n

int egrat ion delivery feedback



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



V Model



ISO 12207

ISO 12207 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 12207 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



ISO 12207 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

02 software processes.ppt [호환 모드] -...

Documents