Specialized Process Models

Outline
Software Applications
Process Patterns
Specialized process models

2
 Software Applications
1. System software: such as compilers, editors, file management
utilities
2. Application software: stand-alone programs for specific needs.
3. Engineering/scientific software: Characterized by “number
crunching”algorithms. such as automotive stress analysis,
molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system. (key
pad control of a microwave oven, digital function of dashboard
display in a car)
5. Product-line software focus on a limited marketplace to address
mass consumer market. (word processing, graphics, database
management)
6. WebApps (Web applications) network centric software. As web
2.0 emerges, more sophisticated computing environments is
supported integrated with remote database and business
applications.
7. AI software uses non-numerical algorithm to solve complex
problem. Robotics, expert system, pattern recognition game
playing 3
Software—New Categories
 Open world computing—pervasive, ubiquitous, distributed
computing due to wireless networking. How to allow mobile
devices, personal computer, enterprise system to
communicate across vast network.
 Netsourcing—the Web as a computing engine. How to
architect simple and sophisticated applications to target
end-users worldwide.
 Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
 Also … (see Chapter 31)
◦ Data mining
◦ Grid computing
◦ Cognitive machines
◦ Software for nanotechnologies

4
 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.
 Stated in more general terms, a process pattern provides
you with a template [Amb98]—a consistent method for
describing problem solutions within the context of the
software process.
( defined at different levels of abstraction)
1.Problems and solutions associated with a complete
process model (e.g. prototyping).
2.Problems and solutions associated with a framework
activity (e.g. planning) or
3.an action with a framework activity (e.g. project
estimating).
5
 Process Pattern Types
 Stage patterns—defines a problem associated with
a framework activity for the process. It includes
multiple task patterns as well. For example,
EstablishingCommunication would incorporate the
task pattern RequirementsGathering and others.
 Task patterns—defines a problem associated with
a software engineering action or work task and
relevant to successful software engineering practice
 Phase patterns—define the sequence of framework
activities that occur with the process, even when
the overall flow of activities is iterative in nature.
Example includes Sprial Model or Prototyping.

6
An Example of Process Pattern
 Describes an approach that may be applicable when stakeholders have a general idea of what
must be done but are unsure of specific software requirements.
 Pattern name. RequiremetnsUnclear
 Intent. This pattern describes an approach for building a model that can be assessed iteratively by
stakeholders in an effort to identify or solidify software requirements.
 Type. Phase pattern
 Initial context. Conditions must be met (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. stakeholders are unsure
of what they want.
 Solution. A description of the prototyping process would be presented
here.
 Resulting context. A software prototype that identifies basic
requirements. (modes of interaction, computational features, processing
functions) is approved by stakeholders. Following this, 1. This prototype
may evolve through a series of increments to become the production
software or 2. the prototype may be discarded.
 Related patterns. CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.

7
Process Assessment and Improvement

SP cannot guarantee that software will be delivered on time, meet the needs, or has the
desired technical characteristics. However, the process can be assessed to ensure that it meets
a set of basic process criteria that have been shown to be essential for a successful software
engineering.

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; uses the SEI CMM as the basis for the assessment
[Dun01]
SPICE—The SPICE (ISO/IEC15504) standard 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. [ISO08]

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. [Ant06]

8
Still Other Process Models
 Component based development—the process to apply when
reuse is a development objective ( like spiral model)
 Formal methods—emphasizes the mathematical
specification of requirements ( easy to discover and eliminate
ambiguity, incompleteness and inconsistency)
 Aspect Oriented software development (AOSD)—provides a
process and methodological approach for defining,
specifying, designing, and constructing aspects
 Unified Process —a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML) to model and
develop object-oriented system iteratively and incrementally.

9
Component-Based Development
Commercial off-the-shelf (COTS) software
components can be used
Components should have well-defined
interfaces
Incorporates many of the characteristics
of the spiral model
Evolutionary in nature

10
Steps in component-based development

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.
11
The Formal Methods Model
Encompasses a set of activities that leads to
formal mathematical specification of
computer software
Have provision to apply a rigorous,
mathematical notation
Ambiguity, incompleteness, and inconsistency
can be discovered and corrected more easily –
not through ad-hoc review, but through the
application of mathematical analysis
Offers the promise of defect-free software
Cleanroom Software Engineering is a variation
of the Formal Methods Model
12
The Formal Methods Model –
Critical Issues
The development of formal models is
currently quite time-consuming and
expensive
Extensive training is required
It is difficult to use the models as a
communication mechanism for
technically unsophisticated customers

13
The Unified Process (UP)
elaboration

inception

14
UP Phases

15
UP Work Products

16
Team Software Process (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 (IPT) of three 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.
 The Capability Maturity Model (CMM), a measure of the effectiveness
of a software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade
team skills. 17
Specialized Process Models
Take on many of the characteristics of one or
more of the conventional models
Tend to be applied when a narrowly defined
software engineering approach is chosen
Examples:
◦ Component-Based Development
◦ The Formal Methods Model

18
Thanks

19