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