. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Faculty of Computer Science University of Indonesia

CSF3600202 Rekayasa Perangkat Lunak

Term 2 - 2013/2014
Slide dibuat oleh : Satrio Baskoro Yudhoatmojo S.Kom., M.T.I. Dimodifikasi dan dipergunakan kembali oleh : Arlisa Yuliawati, S.Kom., M.Kom
1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Faculty of Computer Science University of Indonesia

Topic 02: Generic Process Model

References

[Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioners Approach. New York:McGraw-Hill Higher Education, 2010. Print [Sommerville, 2007] Sommerville, Ian, Software Engineering, 8 th Edition, PearsonAddison Wesley, England, 2007. [Dennis, 2010] Dennis, Alan, et al, System Analysis and Design, 4th Edition, John Wiley & Sons, New Jersey, 2010. [Pfleeger & Atlee, 2010] Pfleeger, Shari Lawrence., and Joanne M. Atlee. Software Engineering: Theory and Practice. 4th ed. Upper Saddle River [N.J.: Prentice Hall, 2010. Print.
3

Outline

Why do we need Process

The meaning of process

Software Development Process Five Generic Framework Activities Software Development Process Flows Generic Software Development Process
Models

Prescriptive Software Development

Process Models
4

Why do we need to use a process model?

Many failed systems were abandoned

because software engineers tried to build wonderful systems without understanding how the system would fit with the organizations goals

 If the process is right, the result will take

care of themselves Takashi Osada [Pressman, 2010]

Prologue

Engineering software is both a creative

and a step-by-step process which often involving many people.

Engineering software is also an iterative

social learning process.
The outcome is an embodiment of knowledge collected, distilled and organized as process is conducted

The Meaning of Process

A series of steps composed of activities,

actions, and tasks that are performed when some work product is to be created and involves a set of tools and techniques. [Pressman, 2007] [Pfleeger & Atlee, 2010]

A structured set of activities required to develop

a software system.

[Sommerville, 2007]
9

The Meaning of Process

An activity strives to achieve a broad objective

(e.g. communication with stakeholders) and is applied regardless of:
the application domain size of the project

complexity of the effort, or

degree of rigor with which software engineering is to be applied
10

The Meaning of Process

An action (e.g. architectural design)

encompasses a set of tasks that produce a major work product (e.g. architectural design model)

A task focuses on small, but well-defined

objective (e.g. conducting a unit test) that produces a tangible outcome.

11

The Meaning of Process

Process is also called life cycles when it

involves the building of some product

Software development process is also called

software development life cycle
It describes the life of a software product from its conception to its implementation, delivery, use and maintenance.

Processes impose consistency and structure on

a set of activities.
12

Characteristics of a process

Characteristics of a process [Pfleeger & Atlee, 2010] :

prescribes all major process activities

uses resources, subject to a set of constraints, and produces intermediate and final products
may be composed of subprocesses linked together

each process activity has entry and exit criteria

each activity are organized in a sequence every process has a set of guiding principles

constraints or controls may apply to an activity, resource, or product.

13

Software Development Process

In software engineering, a process is not a rigid prescription for how to build computer software.
It is an adaptable approach that enables the people doing the work to pick and choose the appropriate work actions and tasks. The end goal is always to deliver software in timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it.
14

Generic Software Development Process Models

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Process should be:
Visible: Activities should provide clear indications of progress (deadlines/milestones)
Understandable: Activities and their order of execution are well-defined Supportable: Automated support for activities is available Usable: Process is acceptable to and usable by developers
15

A Generic Software Development Process

16

Five Generic Framework Activities

Communication Planning Modeling Construction Deployment

Process Flow?

17

1
commence

Communication

Conducted before any technical work can

Communicate and collaborate with customers

and other stakeholders

The intent is to understand stakeholders

objectives for the project and to gather requirements that help define software features and functions
18

2 Any complicated journey can be simplified if a map

exists.

Planning

Planning activity creates a map that helps guide the team as it makes the journey. The map is called software project plan (defines software engineering work)
technical tasks to be conducted risks that are likely the resource required, the work product to be produced, and work schedule
19

Modeling

Create a sketch of the thing so that youll

understand the big picture
what it will look like architecturally how the constituent parts fit together etc

The goal is to better understand software

requirements and the design that will achieve those requirements
20

Construction

Code generation (either manual or automated) Testing that is required to uncover errors in the
code

21

Deployment

Completed software is delivered to the customer

who evaluates the delivered product and provides feedback based on the evaluation

22

Software Development Process Flows

Process flow describes how the framework

activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time.

There are four process flow, based on

[Pressman, 2010], (see next slide for illustrations)

23

Software Development Process Flow

24

Software Development Process Flow

25

Software Development Process Flow

26

Prescriptive Software Development Process Models

Prescriptive process models advocate an

orderly approach to software engineering
Order and project consistency are dominant issues

Prescriptive in a sense they provide a set of

process elements

Each model prescribes a process flow.

27

Prescriptive Software Development Process Models

The Waterfall Model Incremental Model Evolutionary Model Unified Process

28

The Waterfall Model

One of the first software development process

model

[Pressman, 2010]

29

The Waterfall Model

[Pfleeger & Atlee, 2010]

30

The Waterfall Model

Its variants:
V-shaped model: relationship between types of tests and phases before testing Prototyping variant: requirements and design prototypes

31

The Waterfall Model : V-Shaped

[Pfleeger & Atlee, 2010]

32

The Waterfall Model : Prototype

[Pfleeger & Atlee, 2010]

33

The Waterfall Model

The problems [Pressman, 2010] [Sommerville, 2007] [Pfleeger & Atlee, 2010]: Inflexible partitioning of the project into distinct stages makes (difficult to respond to changing customer requirements). Requirements must be well-understood up front (difficult to customers). Few business systems have stable requirements. This model is mostly used for large systems engineering projects where a system is developed at several sites.

Todays business environment no longer tolerate long delays.

34

The Incremental Model

[Pressman, 2010]

35

The Incremental Model

The system as specified in the requirements documents is partitioned into subsystems by functionality. The releases are defined by beginning with one small, functional subsystem and then adding functionality with each new release. Thus, there are usually two systems functioning in parallel:
The production system
The development system
36

The Incremental Model

The initial requirements are reasonably

well-defined so that we can partition them into subsystems.

The requirements are prioritized before

partitioning into several subsystems.
37

The Incremental Model

Used in situation where a limited set of software

functionality must be presented to users quickly and refinement and expansion of functionality could be done in later release

It combines elements of linear and parallel

process flows
Each linear process flow produces an increment of the software.

38

The Incremental Model

The advantages [Sommerville, 2007]

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

Evolutionary Process Model

These models are iterative Characterized in a manner that enables you to

develop increasingly more complete versions of the software.

Two common Evolutionary Process Model :

Prototyping Spiral Model

40

Evolutionary Process Model :

Prototyping

41

Evolutionary Process Model :

Prototyping

Prototyping:
Assists you and other stakeholders to better understand what is to be built when requirements are fuzzy. Users get a feel for the actual system and developers get to build something immediately.

42

Evolutionary Process Model :

Prototyping

Process: quick design, build prototype,

of analysis

Forms of prototypes varies depending on forms

Paper spec of SW from functional analysis or requirements gathering through FAST (Facilitated Application Specification Techniques)
Coded prototype (not fully functional!) Preliminary user manual Story boards
43

evaluate, refine prototype, engineer product

Evolutionary Process Model :

Prototyping

Problems [Sommerville, 2007] [Pressman, 2010]

Lack of process visibility; Systems are often poorly structured; Special skills (e.g. in languages for rapid prototyping) may be required.

Customer sees prototype, then wants a few fixes quick and delivery
Implementation compromises made to get prototype done quickly/forgets compromises and become part of the system
44

Evolutionary Process Model :

Prototyping

With those problems which might occur,

nevertheless prototyping can be an effective paradigm.

The key is to define the rules of the game at

the beginning:
All stakeholders should agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part), and the actual software is engineered with an eye toward quality.
45

Evolutionary Process Model :

Prototyping

Applicability [Sommerville, 2007]

For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface); For short-lifetime systems.

46

Evolutionary Process Model :

The Spiral Model

The Spiral Model [Sommerville, 2007]

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. Risks are explicitly assessed and resolved throughout the process.

47

Evolutionary Process Model :

The Spiral Model

48

Evolutionary Process Model :

The Spiral Model

This evolutionary model couples the iterative

nature of prototyping with the controlled and systematic aspects of the waterfall model.

Provides the potential for rapid development of

increasingly more complete versions of the software.

A realistic approach to the development of largescale systems and software.

49

Evolutionary Process Model :

The Spiral Model

Example:
The first circuit around the spiral might result in the development of a product specification Subsequent passes might be used to develop a prototype Then, progressively more sophisticated versions of the software Each pass through the planning region result in adjustments to the project plan
50

Evolutionary Process Model

Can be adapted to apply throughout

the life of the computer software => realistic approach for the development of large-scale systems and software

Allows a software team to represent

iterative and concurrent elements of any of the process models described before.

51

Unified Process

Ivar Jacobson, Grady Booch, James Rumbaugh UP recognizes the importance of customer

Emphasizes the important role of software

architecture --> architecture-centric

communication and streamlined methods for describing the customers view of a system (the use case) --> use-case driven

Suggests a process flow that is iterative and

incremental, providing the evolutionary feel that is essential in modern software development --> iterative and incremental
52

Unified Process
Ela b o r a t io n In c e p t io n

c o n st r u c t io n
Releas e
s oft w are inc rem ent

t r a n sit io n

p r o d u c t io n
53

Unified Process

UML a unified modeling language that

contains a robust notation for the modeling and development of OO systems; de facto standard for OO software development

Unified Process: a framework for objectoriented software engineering using UML

54

Unified Process Phases

UP Phases
In ce p t io n Elab o r at io n Co n st r u ct io n Tr an sit io n Pr o d u ct io n

Workflows Requirements

Analysis

Design

Implem entation

Test Support Iterations #1 #2 #n-1 #n

55

Unified Process : Inception

Communication activity collaborating with stakeholders

Business requirements are identified
Fundamental business requirements Described through a set of preliminary use-cases

Rough architecture is proposed

Tentative outline of major subsystems and the functions and features that populate them

Planning activity
Plan for iterative, incremental project is developed
Identify resources, assesses major risks, define a schedule, establishes a basis for the phases that are to be applied
56

Unified Process : Elaboration

Planning activity
Plans are carefully reviewed to ensure scope, risks and delivery dates remain reasonable

Modeling activity
Refines and expands preliminary use-cases and architectural representation
5 different views of systems (see next slide) Executable architectural baseline -->first cut executable systems
57

Unified Process : Elaboration

Five Different View of the System

Logical View Process View

Use Case View Physical View Development View

58

Unified Process : Construction

Construction activity Code generation (Architectural model --> operational usecases) Requirement and design models are completed; final version of the software increment Necessary and required functions and features (i.e., the release) are implemented in source code Testing Unit test is designed and executed Integration activites are conducted Use-case are used to derive a suite of acceptance test and executed
59

Unified Process : Transition

Testing
Beta testing

Deployment
Create necessary support information (e.g., user manuals, troubleshooting guides, installation procedures)

End of transition phase --> usable software

release
60

Unified Process : Production

Deployment activity
Ongoing use of the software is monitored, support for the operating environment is provided, defect reports and requests for changes are submitted and evaluated

61

Unified Process

Five UP phases do not occur in a sequence, but rather with staggered concurrency A software engineering workflow is distributed across all UP phases
Workflow is analogous to a task set

62

Unified Process Phases - Revisited

UP Phases
In ce p t io n Elab o r at io n Co n st r u ct io n Tr an sit io n Pr o d u ct io n

Workflows Requirements

Analysis

Design

Implem entation

Test Support Iterations #1 #2 #n-1 #n

63

Unified Process Work Product

In ce p t io n p h ase
V isio n d o cu m e n t In it ial u se -case m o d e l In it ial p ro je ct g lo ssary In it ial b u sin e ss case In it ial risk asse ssm e n t . Pro je ct p lan , p h ase s an d it e rat io n s. Bu sin e ss m o d e l, if n e ce ssary . On e o r m o re p ro t o t y p e s
Incept io n

Elab o r at io n p h ase Co n st r u ct io n p h ase

D e sig n m o d e l So f t w are co m p o n e n t s In t e g rat e d so f t w are in cre m e n t Te st p lan an d p ro ce d u re Te st case s Su p p o rt d o cu m e n t at io n u se r m an u als in st allat io n m an u als d e scrip t io n o f cu rre n t in cre m e n t D e liv e re d so f t w are in cre m e n t Be t a t e st re p o rt s Ge n e ral u se r f e e d b ack

Use -case m o d e l Su p p le m e n t ary re q u ire m e n t s in clu d in g n o n -f u n ct io n al A n aly sis m o d e l So f t w are arch it e ct u re D e scrip t io n . Exe cu t ab le arch it e ct u ral p ro t o t y p e . Pre lim in ary d e sig n m o d e l Re v ise d risk list Pro je ct p lan in clu d in g it e rat io n p lan ad ap t e d w o rkf lo w s m ile st o n e s t e ch n ical w o rk p ro d u ct s Pre lim in ary u se r m an u al

Tr an sit io n p h ase

64

Q&A