Chap#2

Process Models
2.1 A Generic Process Model
• In Chapter 1, a process was defined as a collection of work activities, actions, and tasks that are performed when some work
product is to be created. Each of these activities, actions, and tasks reside within a framework or model that defines their
relationship with the process and with one another.
• Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work
products that will be produced, the quality assurance points that will be required, and the milestones that will be used to
indicate progress.
• Generic process framework for software engineering defines five framework activities—communication, planning, modeling,
construction, and deployment.
• In addition, a set of umbrella activities—project tracking and control, risk management, quality assurance, configuration
management, technical reviews, and others—are applied throughout the process.
• 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.
• A linear process flow executes each of the five framework activities in sequence,beginning with communication and
culminating with deployment.
• Iterative process flow repeats one or more of the activities before proceeding to the next.
• An evolutionary process flow executes the activities in a “circular”manner. Each circuit through the five activities leads to a
more complete version of the software.
• A parallel process flow executes one or more activities in parallel with other activities.
2.1.1 Defining a Framework Activity
• What actions are appropriate for a framework activity, given the
nature of the problem to be solved, the characteristics of the people
doing the work, and the stakeholders who are sponsoring the project?
• Figure 2.2
• different set of requirements, the communication activity might have
six distinct actions: inception(begin), elicitation(raise), elaboration,
negotiation, specification, and validation.
2.1.2 Identifying a Task Set
• Different projects demand different task sets. The software team
chooses the task set based on problem and project characteristics.
2.1.3 Process Patterns
• 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.
• Ambler [Amb98] has proposed a template for describing a process
pattern: Pattern Name, Forces, Type(Stage pattern, Task pattern,
Phase pattern)
2.2 Process Assessment and Improvement
• A number of different approaches to software process assessment and improvement have
been proposed over the past few decades.
• Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a
five-step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting, and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a
diagnostic technique for assessing the relative maturity of a software organization.
• SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process.
• ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
2.3 Prescriptive Process Models
• Prescriptive process models define a prescribed set of process elements and a predictable process work flow.
2.3.1 The Waterfall Model
• There are times when the requirements for a problem are well understood—when work flows from communication
through deployment in a reasonably linear fashion. The waterfall model, sometimes called the classic life cycle.
• The V-model illustrates how verification and validation actions are associated with earlier engineering actions.
2.3.2 Incremental Process Models
• The incremental model delivers a series of releases, called increments, that provide progressively more functionality for
the customer as each increment is delivered.
2.3.3 Evolutionary Process Models
• Evolutionary process models produce an increasingly more complete version of the software with each iteration.
• The Spiral Model: Spiral model is an evolutionary software process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the waterfall model.
2.3.4 Concurrent Models
• The concurrent development model, sometimes called concurrent engineering, allows a software team to represent
iterative and concurrent elements of any of the process models.
2.3.5 A Final Word on Evolutionary Processes
2.4 Specialized process models
• Specialized process models take on many of the characteristics of one or more of the traditional models.
These models tend to be applied when a specialized or narrowly defined software engineering approach is
chosen.
• 2.4.1 Component-Based Development
• Component-based development model incorporates many of the characteristics of the spiral model.
• Component-based development model incorporates the following steps (implemented using an
evolutionary approach):
1. Available component-based products are researched and evaluated for the application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
• The component-based development model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits.
Continue…
• 2.4.2 The Formal Methods Model
• The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software. Formal methods enable you to specify,
develop, and verify a computer-based system by applying a rigorous, mathematical
notation.
• used during development, they provide a mechanism for eliminating many of the
problems that are difficult to overcome using other software engineering paradigms.
applicability in a business environment has been voiced:
• The development of formal models is currently quite time consuming and expensive.
• Because few software developers have the necessary background to apply formal
methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
2.4.3 Aspect-Oriented Software
Development
• When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
Aspectual requirements define those crosscutting concerns that have
an impact across the software architecture.
• AOCE uses a concept of horizontal slices through vertically-
decomposed software components, called “aspects,” to characterize
cross-cutting functional and non-functional properties of
components. Common, systemic aspects include user interfaces,
collaborative work, distribution, persistency, memory management,
transaction processing, security, integrity and so on.
2.5 Unified Process
• Today, the trend in software is toward bigger, more complex systems. That is due in part
to the fact that computers become more powerful every year, leading users to expect
more from them. This trend has also been influenced by the expanding use of the
Internet for exchanging all kinds of information. . . . Our appetite for ever-more
sophisticated software grows as we learn from one product release to the next how the
product could be improved. We want software that is better adapted to our needs, but
that, in turn, merely makes the software more complex. In short, we want more.
• Unified Process is an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that implements
many of the best principles of agile software development.
• The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system (the use case).
• understandability, reliance to future changes, and reuse
2.5.1 A Brief History
• “unified method” that would combine the best features of each of
their individual object-oriented analysis and design methods and
adopt additional features proposed by other experts. UML—a unified
modeling language that contains a robust notation for the modeling
and development of object-oriented systems.
• Unified Process, a framework for object-oriented software
engineering using UML. Today, the Unified Process (UP) and UML are
widely used on object-oriented projects of all kinds. The iterative,
incremental model proposed by the UP can and should be adapted to
meet specific project needs.
2.5.2 Phases of the Unified Process
• Figure 2.9
• The inception phase of the UP encompasses both customer communication and
planning activities.
• The elaboration phase encompasses the communication and modeling activities of the
generic process model.
• The construction phase of the UP is identical to the construction activity defined for the
generic software process.
• The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity.
• The production phase of the UP coincides with the deployment activity of the generic
process(ongoing monitoring).
• A software engineering workflow is distributed across all UP phases.
2.6 PERSONAL AND TEAM PROCESS
MODELS
• The best software process is one that is close to the people who will
be doing the work (Project Requirements).
• In an ideal setting, you would create a process that best fits your
needs, and at the same time, meets the broader needs of the team
and the organization.
• It is possible to create a “personal software process(PSP)” and/or a
“team software process(TSP).” Both require hard work, training, and
coordination, but both are achievable.
2.6.1 Personal Software Process (PSP)
• Every developer uses some process to build computer software.
• In order to change an ineffective personal process, an individual must move through phases, each
requiring training and careful instrumentation.
• The Personal Software Process (PSP) emphasizes personal measurement of both the work product that
is produced and the resultant quality of the work product.
The PSP model defines five framework activities:
1)Planning: requirements, resource estimates, defect estimate, development tasks.
2)High-level design: External specifications, Prototypes, issues are recorded and tracked, component
design.
3)High-level design review: Formal verification methods, to uncover errors, maintenance
4)Development: Code is generated, reviewed, compiled, and tested
5)Postmortem: data analysis, process effectiveness, guidance to improve
• PSP emphasizes the need to record and analyze the types of errors you make, so that you can develop
strategies to eliminate them.
2.6.2 Team Software Process (TSP)
• The goal of TSP is to build a “self-directed” project team that organizes itself to produce high-quality
software. To form a self-directed team, you must collaborate well internally and communicate well
externally.
Objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals, and own their processes and
plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
• Accelerate software process improvement by making CMM Level 5 behavior normal and expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
• TSP defines the following framework activities: project launch, high-level design ,implementation,
integration and test, and postmortem.
• TSP scripts define elements of the team process and activities that occur within the process.
2.7 Process Technology
• 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.
• Process technology tools allow a software organization to build an
automated model of the process framework.
• Reduced development time or cost.
2.8 Product and Process
• If the process is weak, the end product will undoubtedly suffer.
• As creative software professional, you should also derive as much
satisfaction from the process as the end product.
• The duality of product and process is one important element in
keeping creative people engaged as software engineering continues
to evolve.