ESE Module 1-2
Software Engineering Paradigms
A paradigm is the model of a process. It defines the
flow of activities that occur as the process progresses
from start to end. In the context of software engineering, a paradigm provides a framework that identifies
major activities (sometime called phases), detailed
work tasks, milestones and deliverables.
A number of different paradigms can be applied
during a software project. These will be discussed in
this ESE module.
Software Engineering Paradigm
If you're wondering what all the fuss is about ... "paradigms, schmaradigms ... we sit down and start writing
code." you weren't paying too much attention during
Module 1-1! Building high-quality computer software
demands an engineering approach (and that's
encompasses far more than writing code). And an
engineering approach must be applied within the
context of a process model. The paradigm that you
choose will have a lot to do with the success of your
software engineering process.
Exercise 1-3.
Do You Use Software Engineering
Paradigm?
Think about a typical software project within your
organization and answer Yes or No to the following
questions:
1. Does a written project plan (it can be a few
pages or an in-depth document) exist before the project begins?
2. Is there a predictable set of tasks (other than coding) that will be performed on every project?
3. Do practitioners (e.g., programmers, engineers)
apply a predictable set of methods as the software
project proceeds?
4. Do your customers understand your approach to
software development or maintenance and their role
within your approach?
5. Does everyone have a clear understanding of the
milestones that represent progress on a software project?
6. Do practitioners understand what deliverables to
produce and what the content of these deliverables
should be?
If you answered Yes to all of the above questions, you
probably have a defined software process and have
established a software engineering paradigm.
Describe the major activities below, and then compare them to the paradigms discussed in the video
portion of this module.
Readings
The discussion of software engineering paradigms in
the video portion of this module presented evolutionary models as one of a number of alternative process
models. The following excerpt discusses the evolutionary model in a bit more detail.
The Evolutionary Process Model:
A New Attempt to Achieve Process Quality
Every evolutionary process model exhibits a "spiraling"
characteristic. Work proceeds along a spiral that passes
through a number of task regions in which a variety of
related software engineering tasks are conducted. With
each pass around the spiral, the software becomes more
complete.
Figure 1 depicts a multi-entry point, multi-task region,
evolutionary model. The task flow may be initiated at four
different entry points. Therefore, an individual or group
may enter the task flow at a number of different locations,
defined by the nature of the project that is to be undertaken. Typical entry points might be:
I. Concept feasibility projects that evolve as a result of
some new concept or the application of some new technology
II. New application projects to be undertaken as a consequence of a specific customer request for a computer-based
system
III. Roll-out projects that occur when a new application is
to be disseminated to many users
IV. Maintenance and/or support projects that correct,
adapt, or extend an existing application or system.
Projects in each of the above categories begin at a different
place in the task flow that is defined by the evolutionary
model.
A task region indicates a time span in the task flow
during which functionally related tasks are conducted. The
task regions for the model shown in Figure 1 are:

communication-tasks required to establish effective
communication between developer and customer
1-2.2 ·· Essential Software Engineering
 planning--tasks required to define resources, timelines,
and other project-related information
 risk assessment--tasks required to assess both technical
and management risks
 engineering--tasks required to build one or more representations of the application
 installation-tasks required to test, install, and provide
user support (e.g., documentation and training)
 customer evaluation--tasks required to obtain customer
feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Management and technical tasks are defined for each of the
task regions. To accommodate the need for an adaptive
process (e.g., one that adapts itself to the characteristics of
the project at hand), the evolutionary model should define
a number of task sets. Each task set contains software engineering tasks, milestones, and deliverables that have been
chosen to meet the needs of different types of projects.
Each task set must provide enough discipline to achieve
high software quality. But at the same time, it must not
burden the project team with unnecessary work.
Although any number of task sets can be suggested,
the following are typical:
Casual. The process model does not apply to the project,
but selected tasks may be applied informally and basic
principles of software engineering must still be followed.
Disciplined. The process model will be applied for the
project with a degree of discipline that will ensure high
quality and good application maintainability.
Rigorous. All process model tasks, documents, and milestones will be applied to the project. High quality, good
documentation, and long maintainability are paramount.
Quick reaction. The process model will be applied for the
project, but because of extremely tight time constraints,
only those tasks essential to maintaining good quality will
be applied. When necessary, "back-filling" (e.g., developing a complete set of documentation) will be accomplished
after the application is delivered to the customer.
The process model should provide a set of adaptation
criteria that can be used to guide a project manager in
selecting the right task set. Each adaptation criterion is
assigned a grade that is chosen based on a set of project
characteristics. Some suggested adaptation criteria follow:
Size of project. This criterion can be estimated in work
units (e.g., person-months) or product units (e.g., number
of lines of code to be generated).
Number of potential clients/customers. This criterion provides information on the potential market and, by inference, the amount of support required.
Business criticality. This criterion provides an indication
of the relative business impact of the project.
Longevity. This criterion estimates the number of years
that the application to be built will be in active use.
Stability of requirements. This criterion indicates the
degree to which software requirements are understood and
will remain stable throughout the project.
Ease of customer-developer communication. This criterion provides an indication of the ease with which communication can be conducted between customer and developer.
It is often affected by the location of developer and customer.
Maturity of technology. This criterion provides a relative
indication of the risk associated with the technology to be
implemented.
Performance constraints. This criterion provides a relative
indication of the overall performance demanded of the
application and the risk associated with achieving it.
Hardware and software environment. This criterion
defines the maturity and risk associated with the hardware
and software environment into which the application is to
be placed.
The Process Framework
The software engineering paradigm becomes one
part of the process model that establishes a framework for your software project. The detailed character
of your framework will vary, depending on local
requirements, the kinds of software that you develop
and maintain, and a variety of other factors. In this
portion of ESE Module 1-2, the basic attributes of the
framework are discussed.
Software Engineering Paradigms ·· 1-2.3
Exercise 1-4.
Designing a Common Process
Framework
Using information presented in the video and further
information contained in the next Readings section,
outline a common process framework for your organization. Perform the following tasks:
1. Identify the framework activities that will be
applicable for all projects.
2. Define the major tasks that are appropriate for
each framework activity.
3. Define the deliverables that are associated with
each task.
4. Indicate what milestones will be used and how
quality will be assessed as a consequence of reaching
each milestone.
Discuss your work with colleagues to obtain construetive criticism of your process model.
Readings
Before any organization can succeed in establishing
effective software engineering practices, it must
develop a common process framework. The following
excerpt from A Manager's Guide to Software
Engineering describes the attributes of a common
process framework and proposes at set of questions
that can serve as a prototype for selecting a framework and the technologies that populate it.
The common process framework encompasses a common
set of tasks, milestones and deliverables that establish the
criteria for task completion at each step in the software
engineering process. Organizational responsibility is
defined for each deliverable. Reviews are conducted to
confirm completion. The framework also incorporates the
activities and responsibilities of quality assurance and configuration management.
A common process framework should be easily adapted to different technical methods (e.g., analysis, design or
testing methods) that are used for information system
development. It establishes milestones (checkpoints) and
deliverables for all projects and should be used for both
new work and maintenance.
While a minimum set of document deliverables are
necessary at each framework checkpoint, the formats can
be tailored to meet organizational and project needs as
long as the intent of the common deliverable is met.
A combination of a common framework, a conforming
(to the intent of the common framework) set of technical ·
methods, and a set of conforming (to the intent of the common framework) deliverables define the software engineering process.
In order to develop an appropriate common process
framework, it is important to establish a set of criteria for
the framework that your organization can live with. The
following criteria should get you started:
1. The process model should define tasks, milestones and
deliverables in a way that will guide project managers in
their work.
2. The process model should be adaptable. That is, it
should provide a framework for both large and small projects.
3. The process model should be applicable to both new
development and maintenance work.
4. The process model should demand appropriate documentation, but should not bury developers/maintainers
under an avalanche of documents.
5. The process model should serve as a first step toward
ther development of software engineering standards.
You goal is to select a set of methods that will complement
the software engineering tasks chosen as part of a common
process framework. To do this, you can begin with the following criteria that I have listed for each of the major methods areas. You should supplement these with criteria of
your own:
Analysis
 Does the analysis method support facilitated application specification with customers?
 Does the analysis modeling approach support a graphical notation that is widely used and understood?
 Are data, functional, and behavioral modeling supported?
 Is partitioning of all models supported?
· Does the method lead directly to (1) a specification or
(2) a prototype?
 Is the model that is created capable of being mapped
into a design?
 Is the method supported by a number of different
CASE tools supplied by different vendors on different platforms?
Design
 Does the design method support data design, architectural design, and procedural design?
 Does the design modeling approach support a graphical notation that is widely used and understood?
 Are design fundamentals such as support for abstraction, refinement, functional independence, or modularity
directly implemented using the method?
 Are design quality criteria explicitly stated?
 Does the design method result in the derivation of
reusable components?
 Is the method supported by a number of different
CASE tools supplied by different vendors on different platforms?
Programming Languages and 4GLs
 Are the programming languages that have been chosen best for your application domain?
 Are the programming languages that have been cho-
1-2.4 ·· Essential Software Engineering
sen best for your design approach?
 Are tools available for automatically generating source
code?
 Does the language enable you to maintain coding style
standards?
 Are the languages supported by a number of different
CASE tools supplied by different vendors on different platforms?
Testing
 Do the testing methods chosen support both black box
and white box testing philosophies?
 Are the testing methods supported by CASE tools?
Are the testing methods amenable to automated management by CASE tools?
 Do the testing methods provide path and condition
coverage?
 Are the test methods consistent with the testing strategy specified in the common process framework?
Reengineering Maintenance
· Can the chosen analysis/design/testing methods be
used during maintenance activities? How must they be
modified, if at all?
Are specialized tools available to support re-engineering methods?
Software Quality Assurance
 Do the SQA methods enable quality checking after
each major software engineering step?
Do the SQA methods support the collection of quantitative data?
 Are the methods to be applied by an independent
group? Are they easily learned?
 Is the formal technical review (FTR approach that has
been chosen well suited to the culture and personalities of
the organization's staff?
 Does the FTR method demand record keeping?
Software Configuration Management
 Do the methods for SCM provide the procedural controls implied by the process framework?
 Is SCM an integral part of any CASE repository?
 Are the SCM methods supported by a number of different CASE tools supplied by different vendors on different platforms?
Project Management
 Are cost estimation methods predicated on the collection of historical data?
 Are cost estimates to be derived using two different
and independent methods?
 Is there a way of assessing the risks inherent in a software project?
 Do scheduling methods make use of the tasks implied
in the common process framework?
 Are the project management methods supported by a
number of different CASE tools supplied by different vendors on different platforms?
Post-Test, Module I-2
This post-test has been designed to help you assess
the degree to which you've absorbed the information
presented in this ESE Module.
Software Engineering Paradigms
1. If requirements are well defined and there is little
likelihood that changes will occur, the simplest model
to implement is:
a. the classic lifecycle
b. prototyping
c. the spiral model
d. formal methods
2. One of the problems associated with the linear,
sequential paradigm is:
a. it doesn't accommodate change particularly well
b. it doesn't have well defined milestones
c. it requires the use of structured methods
d. it can't be used when empirical estimation
methods are applied
3. The prototyping model can be used when:
a. requirements are uncertain and the software is
amenable to prototyping
b. the customer demands quick turn around
c. testing is unimportant
d. it can always be used, regardless of the
problem to be solved
4. When an evolutionary model is used:
a. the project plan will evolve
b. the design will evolve
c. the program will evolve
d. all of the above
5. What happens as a project moves outward on
the spiral?
a. risk is reduced
b. the project moves closer to completion
c. changes will not occur
d. none of the above
6. The cube model is a sophisticated version of the
evolutionary model because:
a. it moves toward more detail as time passes
b. it flattens the project organizationaI structure
c. it accommodates multiple, asynchronous
project activities
d. it demands more iterations prior to completion
Software Engineering Paradigms ·· 1-2.5
7. The reuse model is appropriate for object-oriented projects because:
a. it supports object-oriented programming
b. it accommodates evolutionary development and
the use of a class library
c. it has well-defined milestones
d. it supports structured methods
8. The clean room model makes use of formal
methods. This means that:
a. proof of correctness will be used
b. specification will be represented mathematically
c. inspections will be conducted
d. all of the above
9. A process framework will establish:
a. a set of activities that will be used on every
project, no matter what!
b. a set of activities that should be used on
every project
c. a set of activities that may be used on
every project, at the discretion of the individual
project manager
d. a set of activities that are recommended for use
10. The task set must be adaptable because:
a. different projects require different skills
b. different projects require different tasks to get the
job done effectively
c. data, function, and behavior must be
adequately modeled
d. the task set should not be adaptable!
11. All other things being equal, a large project would
have:
a. more framework activities than a smaller project
b. fewer framework activities than a smaller project
c. different framework activities from a smaller
project
d. an identical set of framework activities as a
smaller project
12. All other things being equal, a large project would
have
a. fewer tasks, milestones, and deliverables than a
smaller project
b. more tasks, milestones, and deliverables than a
smaller project
c. an identical set of tasks, milestones, and
deliverables as a smaller project
d. there's really no way to know
Copyright 1995 R.S. Pressman & Associates, Inc.
No part of this material may be electronically copied,
transmitted, or posted without the express written permission of
R.S. Pressman & Associates, Inc.
These materials have been posted on the Local Web Server of
the Department of Computer Science with permission of
R.S. Pressman & Associates, Inc. and are for use only by
students registered for DCS/235 at Queen Mary and Westfield
College