02 - Generic Process Model

8/12/2019 02 - Generic Process Model

http://slidepdf.com/reader/full/02-generic-process-model 1/65

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Faculty of Computer Science

University of Indonesia

CSF3600202Rekayasa Perangkat

LunakTerm 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



2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Faculty of Computer Science

University of Indonesia

Topic 02:Generic Process Model



3

References

• [Pressman, 2010] Pressman, Roger S. Software

Engineering: A Practitioner’s Approach. New

York:McGraw-Hill Higher Education, 2010. Print

• [Sommerville, 2007] Sommerville, Ian, Software

Engineering, 8 th Edition, Pearson‐Addison

Wesley, England, 2007.

• [Dennis, 2010] Dennis, Alan, et al, SystemAnalysis 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.



4

Outline

• Why do we need Process✤The meaning of process

• Software Development Process

• Five Generic Framework Activities

• Software Development Process Flows

• Generic Software Development ProcessModels

• Prescriptive Software Development

Process Models



5

Why do we need to use a process model?

• Many failed systems were abandonedbecause software engineers tried tobuild wonderful systems withoutunderstanding how the system would

fit with the organization’s goals



6



• If the process is right, the result will takecare of themselves – Takashi Osada

[Pressman, 2010]



Prologue

• Engineering software is both a creativeand a step-by-step process which ofteninvolving many people.

• Engineering software is also an iterativesocial learning process.

✤The outcome is an embodiment ofknowledge collected, distilled andorganized as process is conducted



The Meaning of Process

• A series of steps composed of activities,actions, and tasks that are performed whensome work product is to be created and involvesa set of tools and techniques.

[Pressman, 2007] [Pfleeger & Atlee, 2010]

• A structured set of activities required to developa software system.

[Sommerville, 2007]



• An activity strives to achieve a broad objective(e.g. communication with stakeholders) and isapplied regardless of:

✤ the application domain

✤ size of the project

✤complexity of the effort, or

✤ degree of rigor with which software engineering isto be applied




• An action (e.g. architectural design)

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

• A task focuses on small, but well-definedobjective (e.g. conducting a unit test) thatproduces a tangible outcome.





• Process is also called life cycles when itinvolves the building of some product

• Software development process is also called

software development life cycle

✤ It describes the life of a software product from itsconception to its implementation, delivery, use and

maintenance.

• Processes impose consistency and structure ona set of activities.



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 producesintermediate 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, orproduct.



Software Development Process

• In software engineering, a process is not a rigidprescription for how to build computer software.

• It is an adaptable approach that enables thepeople doing the work to pick and choose theappropriate work actions and tasks.

• The end goal is always to deliver software in

timely manner and with sufficient quality tosatisfy those who have sponsored its creation andthose who will use it.



Generic Software Development Process Models

• A software process model is an abstract representation ofa 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



A Generic Software Development Process



Five Generic Framework Activities

• Communication

• Planning• Modeling

• Construction

• Deployment

Process

Flow?



Communication

• Conducted before any technical work cancommence

• Communicate and collaborate with customersand other stakeholders

• The intent is to understand stakeholders’

objectives for the project and to gatherrequirements that help define software featuresand functions

1



Planning

• Any complicated journey can be simplified if a mapexists.

• Planning activity creates a “map” that helps guide

the team as it makes the journey.

• The map is called software project plan (definessoftware engineering work)

✤ technical tasks to be conducted

✤ risks that are likely

✤ the resource required, the work product to be produced,and work schedule

2



Modeling

• Create a “sketch” of the thing so that you’ll

understand the big picture

✤what it will look like architecturally

✤ how the constituent parts fit together

✤ etc

• The goal is to better understand softwarerequirements and the design that will achievethose requirements

3



Construction

• Code generation (either manual or automated)

• Testing that is required to uncover errors in thecode

4



22

Deployment

• Completed software is delivered to the customerwho evaluates the delivered product andprovides feedback based on the evaluation

5



23

Software Development Process Flows

• Process flow describes how the frameworkactivities and the actions and tasks that occur

within each framework activity are organizedwith respect to sequence and time.

• There are four process flow, based on

[Pressman, 2010], (see next slide forillustrations)



24

Software Development Process Flow



25




26




28

Prescriptive Software Development Process Models

• The Waterfall Model

• Incremental Model• Evolutionary Model

• Unified Process



29

The Waterfall Model

• One of the first software development processmodel

[Pressman, 2010]



30

The Waterfall Model

[Pfleeger & Atlee, 2010]



31

The Waterfall Model

• Its variants:

✤V-shaped model: relationship between types oftests and phases before testing

✤Prototyping variant: requirements and designprototypes



32

The Waterfall Model : V-Shaped




33

The Waterfall Model : Prototype




34

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.

✤ Today’s business environment no longer tolerate long

delays.



35

The Incremental Model

[Pressman, 2010]



36


• The system as specified in the requirementsdocuments is partitioned into subsystems byfunctionality.

• The releases are defined by beginning with onesmall, functional subsystem and then addingfunctionality with each new release.

• Thus, there are usually two systems functioning in

parallel:

✤The production system

✤The development system



37


• The initial requirements are reasonablywell-defined so that we can partitionthem into subsystems.

• The requirements are prioritized beforepartitioning into several subsystems.

Th I l M d l



38


• Used in situation where a limited set of softwarefunctionality must be presented to usersquickly and refinement and expansion of

functionality could be done in later release

• It combines elements of linear and parallelprocess flows

✤Each linear process flow produces an increment ofthe software.

Th I l M d l



39


• The advantages [Sommerville, 2007]

✤Customer value can be delivered with eachincrement so system functionality is available

earlier.

✤Early increments act as a prototype to help clarifyrequirements for later increments.

✤Lower risk of overall project failure.

✤The highest priority system services tend to receive

the most testing.

E l i P M d l



40

Evolutionary Process Model

• These models are iterative

• Characterized in a manner that enables you todevelop increasingly more complete versions of

the software.

• Two common Evolutionary Process Model :

✤Prototyping

✤Spiral Model

Evolutionary Process Model :



41

Evolutionary Process Model :Prototyping




42


• Prototyping:

✤Assists you and other stakeholders tobetter understand what is to be builtwhen requirements are fuzzy.

✤Users get a feel for the “actual system”

and developers get to build somethingimmediately.




43


• Process: quick design, build prototype,evaluate, refine prototype, … engineer product

• Forms of prototypes varies depending on forms

of analysis✤ Paper spec of SW from functional analysis or requirements

gathering through FAST (Facilitated ApplicationSpecification Techniques)

✤ Coded prototype (not fully functional!)

✤ Preliminary user manual

✤ Story boards




44


•Problems [Sommerville, 2007] [Pressman, 2010]

✤ Lack of process visibility;

✤Systems are often poorly structured;

✤Special skills (e.g. in languages for rapidprototyping) 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 partof the system




45


• With those problems which might occur,nevertheless prototyping can be an effectiveparadigm.

• The key is to define the rules of the game atthe beginning:

✤All stakeholders should agree that the prototype isbuilt to serve as a mechanism for definingrequirements.

✤ It is then discarded (at least in part), and the actualsoftware is engineered with an eye toward quality.




46


• Applicability [Sommerville, 2007]

✤For small or medium-size interactivesystems;

✤For parts of large systems (e.g. the userinterface);

✤For short-lifetime systems.




47

Evolutionary Process Model :The Spiral Model

• The Spiral Model [Sommerville, 2007]

✤Process is represented as a spiral rather

than as a sequence of activities withbacktracking.

✤Each loop in the spiral represents a phasein the process.

✤Risks are explicitly assessed and resolvedthroughout the process.




48





49


• This evolutionary model couples the iterativenature of prototyping with the controlled andsystematic aspects of the waterfall model.

• Provides the potential for rapid development ofincreasingly more complete versions of thesoftware.

• A realistic approach to the development of large-scale systems and software.




50


• Example:

✤The first circuit around the spiral might result in thedevelopment of a product specification

✤Subsequent passes might be used to develop aprototype

✤Then, progressively more sophisticated versions of

the software

✤Each pass through the planning region result inadjustments to the project plan



Unified Process



52

Unified Process

• Ivar Jacobson, Grady Booch, James Rumbaugh

• UP recognizes the importance of customercommunication and streamlined methods for

describing the customer’s view of a system (the

use case) --> “use-case d riven ”

• Emphasizes the important role of softwarearchitecture --> “architecture-centr ic ”

• Suggests a process flow that is iterative andincremental, providing the evolutionary feel thatis essential in modern software development -->

“iterative and incremental”

Unified Process



53

Unified Process

soft ware increment

Release

Ince p t io n

Elab o ra t io n

co nst ruc t io n

t r a nsit ion

p r o d u c t io n

Unified Process



54

Unified Process

• UML – a unified modeling language thatcontains a robust notation for themodeling and development of OOsystems; de facto standard for OOsoftware development

• Unified Process: a framework for object-

oriented software engineering usingUML

Unified Process Phases



55

Unified Process Phases

Inception Elaborat ion Const ruct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

Unified Process : Inception



56

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 andfeatures 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

Unified Process : Elaboration



57


• Planning activity

✤Plans are carefully reviewed to ensure scope, risksand delivery dates remain reasonable

• Modeling activity

✤Refines and expands preliminary use-cases andarchitectural representation

✴ 5 different views of systems (see next slide)

✴ Executable architectural baseline -->“first cut”

executable systems




58


Logical View Process View

Physical View DevelopmentView

Use CaseView

• Five Different View of the System

Unified Process : Construction



59

Unified Process : Construction

• Construction activity

✤ Code generation (Architectural model --> operational use-cases)

✴ Requirement and design models are completed; finalversion of the software increment

✴ Necessary and required functions and features (i.e., therelease) 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

Unified Process : Transition



60

Unified Process : Transition

• Testing

✤Beta testing

• Deployment✤Create necessary support information (e.g., user

manuals, troubleshooting guides, installationprocedures)

• End of transition phase --> usable softwarerelease

Unified Process : Production



61

Unified Process : Production

• Deployment activity

✤Ongoing use of the software is monitored, supportfor the operating environment is provided, defectreports and requests for changes are submitted and

evaluated



Unified Process Phases - Revisited



63

Unified Process Phases - Revisited

Inception Elaborat ion Const ruct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support



Q & A

02 - Generic Process Model

Documents

Transcript of 02 - Generic Process Model