Software

Process
2023
PTIK - UNS
  What is it? When you work to build a product or system, it’s important to go
through a series of predictable steps—a road map that helps you create a
timely, high-quality result. The road map that you follow is called a “software
process.”
 Who does it? Software engineers and their managers adapt the process to their
needs and then follow it. In addition, the people who have requested the
software have a role to play in the process of defining, building, and testing it.
 Why is it important? Because it provides stability, control, and organization

Process to an activity that can, if left uncontrolled, become quite chaotic. However, a
modern software engineering approach must be “agile.” It must demand only
those activities, controls, and work products that are appropriate for the project

Model 
team and the product that is to be produced.
What are the steps? At a detailed level, the process that you adopt depends on
the software that you’re building. One process might be appropriate for
creating software for an aircraft avionics system, while an entirely different
process
would be indicated for the creation of a website.
 What is the work product? From the point of view of a software engineer,
the work products are the programs, documents, and data that are produced as
a consequence of the activities and tasks defined by the process.
 How do I ensure that I’ve done it right?
There are a number of software process assessment mechanisms that enable
organizations to determine the “maturity” of their software process. However,
the quality, timeliness, and long-term viability of the product you build are the
best indicators of the efficacy of the process that you use.
 A Generic
Process
Model

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S

APPROACH, 7/E (MCGRAW-HILL 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.

3
 Framework Activities
Communication.
 Before any technical work can commence, it is critically important to
communicate and collaborate with the customer.
 The intent is to understand stakeholders’ objectives for the project and
to gather requirements that help define software features and
functions.
 Framework Activities
Planning.
 Any complicated journey can be simplified if a map exists.
 A software project is a complicated journey, and the planning activity creates a “map”
that helps guide the team as it makes the journey.
 The map—called a software project plan—defines the software engineering work by
describing the technical tasks to be conducted, the risks that are likely, the resources that
will be required, the work products to be produced, and a work schedule.
 Framework Activities
Modeling.
 Whether you’re a landscaper, a bridge builder, an
aeronautical engineer, a carpenter, or an architect, you work
with models every day.
 You 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, and many other
characteristics.
 If required, you refine the sketch into greater and greater
detail in an effort to better understand the problem and how
you’re going to solve it.
 A software engineer does the same thing by creating models
to better understand software requirements and the design
that will achieve those requirements.
 Framework Activities
 Construction.
This activity combines code generation (either manual or automated)
and the testing that is required to uncover errors in the code.
 Framework Activities
Deployment.
 The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.
 Umbrella Activities
 Software project tracking and control—allows the software team to assess progress against the project
plan and take any necessary action to maintain the schedule.
 Risk management—assesses risks that may affect the outcome of the project or the quality of the product.
 Software quality assurance—defines and conducts the activities required to ensure software quality.
 Technical reviews—assesses software engineering work products in an effort to uncover and remove errors
before they are propagated to the next activity.
 Measurement—defines and collects process, project, and product measures that assist the team in delivering
software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella
activities.
 Software configuration management—manages the effects of change throughout the software process.
 Reusability management—defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.
 Work product preparation and production—encompasses the activities required to create work products
such as models, documents, logs, forms, and lists.
Software process model
 Process models prescribe a distinct set of
activities, actions, tasks, milestones, and work
products required to engineer high quality
software.
 Process models are not perfect, but provide
roadmap for software engineering work.
 Software models provide stability, control, and
organization to a process that if not managed
can easily get out of control
 Software process models are adapted to meet
the needs of software engineers and managers
for a specific project.
Why Models are needed?
Symptoms of inadequacy: the software crisis
 scheduled time and cost exceeded
 user expectations not met
 poor quality
The size and economic value of software applications
required appropriate “process model”
Build and Fix Model
Build and Fix Model
The earlier approach
 Product is constructed without specification or any attempt at design.
 developers simply build a product that is reworked as many times as necessary to satisfy the
client.
 model may work for small projects but is totally unsatisfactory for products of any reasonable
size.
 Maintenance is high.
 Source of difficulties and deficiencies
 impossible to predict
 impossible to manage
Process as a "black box"

Informal
Requirements
Process

Product

Quality?
Uncertain /
Incomplete requirement
In the beginning
Problems
 The assumption is that requirements can be fully understood prior
to development
 Interaction with the customer occurs only at the beginning
(requirements) and end (after delivery)
 Unfortunately the assumption almost never holds
Process as a "white box"
Informal
Requirements
Process

Product

feedback
Advantages
 Reduce risks by improving visibility
 Lower the costs
 Allow project changes as the project progresses based on feedback
from the customer
Process Flow
Process Flow
Process Flow
 Task Set
 A task set defines the actual work to be done to
accomplish the objectives of a software
engineering action.
 For example, elicitation (requirements gathering)
is an important software engineering action that
occurs during
the communication activity.
 The goal of requirements gathering is to
understand what various stakeholders want from
the software that is to be built.
Task Set: Small Project
 1. Make a list of stakeholders for the project.
 2. Invite all stakeholders to an informal meeting.
 3. Ask each stakeholder to make a list of features and functions required.
 4. Discuss requirements and build a final list.
 5. Prioritize requirements.

 6. Note areas of uncertainty

Task Set: Large Project
 1. Make a list of stakeholders for the project.
 2. Interview each stakeholder separately to determine overall wants and needs.
 3. Build a preliminary list of functions and features based on stakeholder input.
 4. Schedule a series of facilitated application specification meetings.
 5. Conduct meetings.
 6. Produce informal user scenarios as part of each meeting.
 7. Refine user scenarios based on stakeholder feedback.
 8. Build a revised list of stakeholder requirements.
 9. Use quality function deployment techniques to prioritize requirements.
 10. Package requirements so that they can be delivered incrementally.
 11. Note constraints and restrictions that will be placed on the system.
 12. Discuss methods for validating the system
Process Pattern
 A process pattern describes a process-related problem that is encountered during software
engineering work, identifies the environment in which the problem has been encountered, and
suggests one or more proven solutions to the problem.
Process Pattern Template
 Pattern Name. The pattern is given a meaningful name describing it within the context of the software
process (e.g., TechnicalReviews).
 Forces. The environment in which the pattern is encountered and the issues that make the problem visible
and may affect its solution.
 Type. The pattern type is specified. There are three types:
 1. Stage pattern—defines a problem associated with a framework activity for the process. Since a framework activity
encompasses multiple actions and work tasks, a stage pattern incorporates multiple task patterns (see the following)
that are relevant to the stage (framework activity). An example of a stage pattern might be
EstablishingCommunication. This pattern would incorporate the task pattern RequirementsGathering and others.
 2. Task pattern—defines a problem associated with a software engineering action or work task and relevant to
successful software engineering practice (e.g., RequirementsGathering is a task pattern).
 3. Phase pattern—define the sequence of framework activities that occurs within the process, even when the overall
flow of activities is iterative in nature. An example of a phase pattern might be SpiralModel or Prototyping.
Process Pattern Template
 Initial context. Describes the conditions under which the pattern applies. Prior to the initiation of the pattern: (1) What
organizational or team-related activities have already occurred? (2) What is the entry state for the process? (3) What
software engineering information or project information already exists?

 Problem. The specific problem to be solved by the pattern.

 Solution. Describes how to implement the pattern successfully. This section describes how the initial state of the process
(that exists before the pattern is implemented) is modified as a consequence of the initiation of the pattern. It also describes
how software engineering information or project information that is available before the initiation of the pattern is
transformed as a consequence of the successful execution of the pattern.

 Resulting Context. Describes the conditions that will result once the pattern has been successfully implemented. Upon
completion of the pattern: (1) What organizational or team-related activities must have occurred? (2) What is the exit state
for the process? (3) What software engineering information or project information has been developed?

 Related Patterns. Provide a list of all process patterns that are directly related to this one. This may be represented as a
hierarchy or in some other diagrammatic form. For example, the stage pattern Communication encompasses the task
patterns: ProjectTeam, CollaborativeGuidelines, ScopeIsolation, RequirementsGathering, ConstraintDescription,
and ScenarioCreation.

 Known Uses and Examples. Indicate the specific instances in which the pattern is applicable. For example,
Communication is mandatory at the beginning of every software project, is recommended throughout the software
project, and is mandatory once the deployment activity is under way.
Process Pattern Example
 Pattern name. RequirementsUnclear

 Intent. This pattern describes an approach for building a model (a prototype) that can be assessed iteratively by stakeholders in an effort
to identify or solidify software requirements.

 Type. Phase pattern.

 Initial context. The following conditions must be met prior to the initiation of this pattern: (1) stakeholders have been identified; (2) a
mode of communication between stakeholders and the software team has been established; (3) the overriding software problem to be
solved has been identified by stakeholders; (4) an initial understanding of project scope, basic business requirements, and project
constraints has been developed.

 Problem. Requirements are hazy or nonexistent, yet there is clear recognition that there is a problem to be solved, and the problem must
be addressed with a software solution. Stakeholders are unsure of what they want; that is, they cannot describe software requirements in
any detail.

 Solution. A description of the prototyping process model.

 Resulting context. A software prototype that identifies basic requirements (e.g., modes of interaction, computational features,
processing functions) is approved by stakeholders. Following this, (1) the prototype may evolve through a series of increments to
become the production software or (2) the prototype may be discarded and the production software built using some other process
pattern.

 Related patterns. The following patterns are related to this pattern: CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.

 Known uses and examples. Prototyping is recommended when requirements are uncertain
 Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
28
Waterfall Model (Description)
 Oldest software lifecycle model and best understood by upper
management
 Used when requirements are well understood and risk is low
 Work flow is in a linear (i.e., sequential) fashion
 Used often with well-defined adaptations or enhancements to
current software

29
Waterfall Model (Problems)
 Doesn't support iteration, so changes can cause confusion
 Difficult for customers to state all requirements explicitly and up
front
 Requires customer patience because a working version of the
program doesn't occur until the final phase
 Problems can be somewhat alleviated in the model through the
addition of feedback loops (see the next slide)

30
 Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
31
 Incremental Model
(Diagram)
Increment #1
Communication
Planning
Modeling
Construction
Deployment

Increment #2
Communication
Planning
Modeling
Construction
Deployment

Increment #3

Communication
Planning
Modeling
Construction
Deployment

32
Incremental Model (Description)
 Used when requirements are well understood
 Multiple independent deliveries are identified
 Work flow is in a linear (i.e., sequential) fashion within an
increment and is staggered between increments
 Iterative in nature; focuses on an operational product with each
increment
 Provides a needed set of functionality sooner while delivering
optional components later
 Useful also when staffing is too short for a full-scale development

33
 Prototyping Model
(Diagram)
Quick
Planning

Communication
Start

Modeling
Quick Design
Deployment,
Delivery,
and Feedback

Construction
Of Prototype
34
Prototyping Model (Description)
 Follows an evolutionary and iterative approach
 Used when requirements are not well understood
 Serves as a mechanism for identifying software requirements
 Focuses on those aspects of the software that are visible to the
customer/user
 Feedback is used to refine the prototype

35
Prototyping Model (Potential Problems)
 The customer sees a "working version" of the software, wants to
stop all development and then buy the prototype after a "few
fixes" are made
 Developers often make implementation compromises to get the
software running quickly (e.g., language choice, user interface,
operating system choice, inefficient algorithms)
 Lesson learned
 Define the rules up front on the final disposition of the prototype before it is
built
 In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal toward quality

36
Spiral Model
(Diagram)
Spiral Model (Description)
 Invented by Dr. Barry Boehm in 1988 while working at TRW
 Follows an evolutionary approach
 Used when requirements are not well understood and risks are high
 Inner spirals focus on identifying software requirements and project risks; may
also incorporate prototyping
 Outer spirals take on a classical waterfall approach after requirements have been
defined, but permit iterative growth of the software
 Operates as a risk-driven model…a go/no-go decision occurs after each complete
spiral in order to react to risk determinations
 Requires considerable expertise in risk assessment
 Serves as a realistic model for large-scale software development

38
Task
 Diskusikan ragam process model yang ada
pada software engineering
 Secara bergiliran, ajukan perwakilan masing-
masing tim untuk menyebutkan:
 Nama
 Diagram
 Fase
 Kelebihan
 Kelemahan
 Process Technology Tools
 One or more of the process models discussed in the preceding sections must be adapted for use by a software team. To accomplish this,
process technology tools have been developed to help software organizations analyze their current process, organize work tasks, control and
monitor progress, and manage technical quality.

 Representative Tools:
 1. Jira
 2. Zoho Projects
 3. Trello
 4. Wrike
 5. Asana
 6. Basecamp
 7. Redmine
 8. Celoxis
 9. Scoro
 10. TeamGantt
40
End of Chapter 2