INTRODUCTION TO

SOFTWARE
ENGINEERING
 MODULE 1
OBJECTIVES
Upon the completion of this module, the students are
expected to:

• Explain and define software engineering.

• Identify the difference between software engineering and
computer science.
• Categorize software by characteristics, responsiveness and
type.
• Describe the process of software
• Interpret the process assessment and improvement
 SOFTWARE
ENGINEERING
OVERVIEW
 What is Software?
The product that software professionals build and then support
over the long term.
Software encompasses: (1) instructions (computer programs)
that when executed provide desired features, function, and
performance; (2) data structures that enable the programs to
adequately store and manipulate information and (3)
documentation that describes the operation and use of the
programs.
Software products

• Generic products
• Stand-alone systems that are marketed and sold to any
customer who wishes to buy them.
• Examples – PC software such as editing, graphics programs,
project management tools; CAD software; software for
specific markets such as appointments systems for dentists.
• Customized products
• Software that is commissioned by a specific customer to
meet their own needs.
• Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
 Why Software is Important?

• The economies of ALL developed nations are dependent

on software.
• More and more systems are software controlled (
transportation, medical, telecommunications, military,
industrial, entertainment,)
• Software engineering is concerned with theories,
methods and tools for professional software
development.
• Expenditure on software represents a
significant fraction of GNP in all developed countries.
Software costs

• Software costs often dominate computer system

costs. The costs of software on a PC are often greater
than the hardware cost.
• Software costs more to maintain than it does to
develop. For systems with a long life, maintenance
costs may be several times development costs.
• Software engineering is concerned with cost-effective
software development.
 Features of Software?
• Its characteristics that make it different from other things human being
build.
Features of such logical system:
• Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change). Hardware
has bathtub curve of failure rate ( high failure rate in the beginning, then drop to
steady state, then cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward component-based construction
(e.g. standard screws and off-the-shelf integrated circuits), most
software continues to be custom-built. Modern reusable components
encapsulate data and processing into software parts to be reused by
different programs. E.g. graphical user interface, window, pull-down
menus in library etc.
Wear vs. Deterioration
 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
 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
Software Engineering Definition
The seminal definition:
[Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines.
The IEEE definition:
Software Engineering: (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study of
approaches as in (1).
Importance of Software Engineering

• More and more, individuals and society rely on

advanced software systems. We need to be able to
produce reliable and trustworthy systems
economically and quickly.
• It is usually cheaper, in the long run, to use software
engineering methods and techniques for software
systems rather than just write the programs as if it
was a personal programming project. For most types
of system, the majority of costs are the costs of
changing the software after it has gone into use.
FAQ about software engineering

Question Answer

What is software? Computer programs, data structures and associated

documentation. Software products may be developed for
a particular customer or may be developed for a general
market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.
Essential attributes of good software

Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a
changing business environment.
Dependability and Software dependability includes a range of characteristics
security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.
Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.
Software Engineering
A Layered Technology
tools

methods

process model

a “quality” focus
 Any engineering approach must rest on organizational commitment to quality which fosters a
continuous process improvement culture.
 Process layer as the foundation defines a framework with activities for effective delivery of
software engineering technology. Establish the context where products (model, data, report, and
forms) are produced, milestone are established, quality is ensured and change is managed.
 Method provides technical how-to’s for building software. It encompasses many tasks including
communication, requirement analysis, design modeling, program construction, testing and 17
support.
 Tools provide automated or semi-automated support for the process and methods.
Software Process
• A process is a collection of activities, actions and tasks that are
performed when some work product is to be created. It is not a
rigid prescription for how to build computer software. Rather, it is
an adaptable approach that enables the people doing the work to
pick and choose the appropriate set of work actions and tasks.
• Purpose of process is to deliver software in a timely manner and
with sufficient quality to satisfy those who have sponsored its
creation and those who will use it.
Five Activities of a Generic
Process framework
• Communication: communicate with customer to understand objectives and
gather requirements
• Planning: creates a “map” defines the work by describing the tasks, risks and
resources, work products and work schedule.
• Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
• Construction: code generation and the testing.
• Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation.

• These five framework activities can be used to all software development

regardless of the application domain, size of the project, complexity of the efforts
etc, though the details will be different in each case.

• For many software projects, these framework activities are applied iteratively as
a project progresses. Each iteration produces a software increment that provides
a subset of overall software features and functionality.
 Umbrella Activities
Complement the five process framework activities and help team manage and control
progress, quality, change, and risk.
• Software project tracking and control: assess progress against the plan and take
actions to maintain the schedule.
• Risk management: assesses risks that may affect the outcome and quality.
• Software quality assurance: defines and conduct activities to ensure quality.
• Technical reviews: assesses work products to uncover and remove errors before
going to the next activity.
• Measurement: define and collects process, project, and product measures to
ensure stakeholder’s needs are met.
• Software configuration management: manage the effects of change throughout
the software process.
• Reusability management: defines criteria for work product reuse and establishes
mechanism to achieve reusable components.
• Work product preparation and production: create work products such as models,
documents, logs, forms and lists.
Adapting a Process Model
The process should be agile and adaptable to problems. Process adopted
for one project might be significantly different than a process adopted from
another project. (to the problem, the project, the team, organizational
culture). Among the differences are:

•the overall flow of activities, actions, and tasks and the interdependencies
among them
•the degree to which actions and tasks are defined within each framework
activity
•the degree to which work products are identified and required
•the manner which quality assurance activities are applied
•the manner in which project tracking and control activities are applied
•the overall degree of detail and rigor with which the process is described
•the degree to which the customer and other stakeholders are involved with
the project
•the level of autonomy given to the software team
•the degree to which team organization and roles are prescribed
Prescriptive and Agile
Process Models
•The prescriptive process models stress detailed definition,
identification, and application of process activates and tasks. Intent is
to improve system quality, make projects more manageable, make
delivery dates and costs more predictable, and guide teams of
software engineers as they perform the work required to build a
system.
•Unfortunately, there have been times when these objectives were
not achieved. If prescriptive models are applied dogmatically and
without adaptation, they can increase the level of bureaucracy.

•Agile process models emphasize project “agility” and follow a set

of principles that lead to a more informal approach to software
process. It emphasizes maneuverability and adaptability. It is
particularly useful when Web applications are engineered.
The Essence of Practice
• How does the practice of software engineering fit in
the process activities mentioned above? Namely,
communication, planning, modeling, construction
and deployment.
• George Polya outlines the essence of problem
solving, suggests:
1.Understand the problem (communication and analysis).
2.Plan a solution (modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality
assurance).
Understand the Problem
• Who has a stake in the solution to the problem? That is, who
are the stakeholders?
• What are the unknowns? What data, functions, and features
are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to
understand?
• Can the problem be represented graphically? Can an
analysis model be created?
Plan the Solution
• Have you seen similar problems before? Are there patterns that are recognizable in a
potential solution? Is there existing software that implements the data, functions, and
features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
• Can you represent a solution in a manner that leads to effective implementation? Can
a design model be created?
Carry Out the Plan
• Does the solutions conform to the plan? Is source code
traceable to the design model?
• Is each component part of the solution provably correct? Has
the design and code been reviewed, or better, have
correctness proofs been applied to algorithm?
Examine the Result

• Is it possible to test each component part of the solution?

Has a reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data,
functions, and features that are required? Has the software
been validated against all stakeholder requirements?
Hooker’s General Principles for Software
Engineering Practice: important underlying law
Help you establish mind-set for solid software
engineering practice (David Hooker 96).
•1: The Reason It All Exists: provide values to users
•2: KISS (Keep It Simple, Stupid! As simple as possible)
•3: Maintain the Vision (otherwise, incompatible design)
•4: What You Produce, Others Will Consume (code with concern for
those that must maintain and extend the system)
•5: Be Open to the Future (never design yourself into a corner as
specification and hardware changes)
•6: Plan Ahead for Reuse
•7: Think! Place clear complete thought before action produces better
results.
Software Myths
Erroneous beliefs about software and the
process that is used to build it.
•Affect managers, customers (and other non-
technical stakeholders) and practitioners
•Are believable because they often have
elements of truth,
but …
•Invariably lead to bad decisions,
therefore …
•Insist on reality as you navigate your way
through software engineering
 Software Myths Examples
• Myth 1: Once we write the program and get it to work, our job is done.
• Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to 80% of
all efforts are spent after software is delivered to the customer for the first time.

• Myth 2: Until I get the program running, I have no way of assessing its quality.
• Reality: technical review are a quality filter that can be used to find certain classes of software
defects from the inception of a project.

• Myth 3: software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down.
• Reality: it is not about creating documents. It is about creating a quality product. Better quality
leads to a reduced rework. Reduced work results in faster delivery times.

• Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and
methods foster poor management and technical practices, even when reality dictates
a better approach.
How It all Starts

• SafeHome:
• Every software project is precipitated by some business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a changing business environment;
• the need to extend the functions and features of an existing application, or
• the need to create a new product, service, or system.
Case studies

• A personal insulin pump

• An embedded system in an insulin pump used by diabetics
to maintain blood glucose control.
• A mental health case patient management system
• A system used to maintain records of people receiving care
for mental health problems.
• A wilderness weather station
• A data collection system that collects data about weather
conditions in remote areas.
Insulin pump control system
• Collects data from a blood sugar sensor and calculates
the amount of insulin required to be injected.
• Calculation based on the rate of change of blood
sugar levels.
• Sends signals to a micro-pump to deliver the correct
dose of insulin.
• Safety-critical system as low blood sugars can lead to
brain malfunctioning, coma and death; high-blood
sugar levels have long-term consequences such as eye
and kidney damage.
Insulin pump hardware
architecture
Activity model of the insulin
pump
 Essential high-level requirements
• The system shall be available to deliver insulin when
required.
• The system shall perform reliably and deliver the
correct amount of insulin to counteract the current
level of blood sugar.
• The system must therefore be designed and
implemented to ensure that the system always meets
these requirements.
A patient information system for
mental health care
• A patient information system to support mental
health care is a medical information system that
maintains information about patients suffering from
mental health problems and the treatments that they
have received.
• Most mental health patients do not require dedicated
hospital treatment but need to attend specialist
clinics regularly where they can meet a doctor who
has detailed knowledge of their problems.
• To make it easier for patients to attend, these clinics
are not just run in hospitals. They may also be held in
local medical practices or community centres.
MHC-PMS

• The MHC-PMS (Mental Health Care-Patient

Management System) is an information system that is
intended for use in clinics.
• It makes use of a centralized database of patient
information but has also been designed to run on a
PC, so that it may be accessed and used from sites
that do not have secure network connectivity.
• When the local systems have secure network access,
they use patient information in the database but they
can download and use local copies of patient records
when they are disconnected.
MHC-PMS goals

• To generate management information that allows

health service managers to assess performance
against local and government targets.
• To provide medical staff with timely information to
support the treatment of patients.
The organization of the MHC-PMS
 MHC-PMS key features
• Individual care management
• Clinicians can create records for patients, edit the information in the system,
view patient history, etc. The system supports data summaries so that doctors
can quickly learn about the key problems and treatments that have been
prescribed.
• Patient monitoring
• The system monitors the records of patients that are involved in treatment
and issues warnings if possible problems are detected.
• Administrative reporting
• The system generates monthly management reports showing the number of
patients treated at each clinic, the number of patients who have entered and
left the care system, number of patients sectioned, the drugs prescribed and
their costs, etc.
MHC-PMS concerns
• Privacy
• It is essential that patient information is confidential and is
never disclosed to anyone apart from authorised medical
staff and the patient themselves.
• Safety
• Some mental illnesses cause patients to become suicidal or
a danger to other people. Wherever possible, the system
should warn medical staff about potentially suicidal or
dangerous patients.
• The system must be available when needed otherwise
safety may be compromised and it may be impossible to
prescribe the correct medication to patients.
Wilderness weather station
• The government of a country with large areas of
wilderness decides to deploy several hundred
weather stations in remote areas.
• Weather stations collect data from a set of
instruments that measure temperature and pressure,
sunshine, rainfall, wind speed and wind direction.
• The weather station includes a number of instruments that
measure weather parameters such as the wind speed and
direction, the ground and air temperatures, the barometric
pressure and the rainfall over a 24-hour period. Each of
these instruments is controlled by a software system that
takes parameter readings periodically and manages the
data collected from the instruments.
The weather station’s
environment
 Weather information system
• The weather station system
• This is responsible for collecting weather data, carrying out
some initial data processing and transmitting it to the data
management system.
• The data management and archiving system
• This system collects the data from all of the wilderness
weather stations, carries out data processing and analysis and
archives the data.
• The station maintenance system
• This system can communicate by satellite with all wilderness
weather stations to monitor the health of these systems and
provide reports of problems.
 Additional software functionality
• Monitor the instruments, power and communication
hardware and report faults to the management
system.
• Manage the system power, ensuring that batteries are
charged whenever the environmental conditions
permit but also that generators are shut down in
potentially damaging weather conditions, such as
high wind.
• Support dynamic reconfiguration where parts of the
software are replaced with new versions and where
backup instruments are switched into the system in
the event of system failure.
PROCESS MODELS
 Social Learning Process
• Software is embodied knowledge that is initially
dispersed, tacit and incomplete.

• In order to convert knowledge into software,

dialogues are needed between users and designers,
between designers and tools to bring knowledge
into software.

• Software development is essentially an iterative

social learning process, and the outcome is
“software capital”.
What / who / why is Process Models?
 What: Go through a series of predictable steps--- a road map that helps you
create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People adapt the
process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that can if left
uncontrolled, become quite chaotic. However, modern software engineering
approaches must be agile and demand ONLY those activities, controls and
work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that you
are building. One process might be good for aircraft avionic system, while an
entirely different process would be used for website creation.
 How to ensure right: A number of software process assessment mechanisms
that enable us to determine the maturity of the software process. However,
the quality, timeliness and long-term viability of the software are the best
indicators of the efficacy of the process you use.
 Definition of Software Process
• A framework for the activities, actions, and tasks
that are required to build high-quality software.

• SP defines the approach that is taken as software

is engineered.

• Is not equal to software engineering, which also

encompasses technologies that populate the
process– technical methods and automated
tools.
A Generic Process Model
 A Generic Process Model
As we discussed before, a 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.
Next question is: how the framework activities and
the actions and tasks that occur within each
activity are organized with respect to sequence
and time? See the process flow for answer.
Process Flow

53
Process Flow
Linear process flow executes each of the five activities
in sequence.
An 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 leads to a more
complete version of the software.
A parallel process flow executes one or more activities
in parallel with other activities ( modeling for one
aspect of the software in parallel with construction of
another aspect of the software.
Identifying a Task Set
Before you can proceed with the process model, a key
question: what actions are appropriate for a framework
activity given the nature of the problem, the characteristics of
the people and the stakeholders?
A task set defines the actual work to be done to accomplish
the objectives of a software engineering action.
A list of the task to be accomplished
A list of the work products to be produced
A list of the quality assurance filters to be applied
Identifying a Task Set
For example, a small software project
requested by one person with simple
requirements, the communication activity might
encompass little more than a phone all with the
stakeholder. Therefore, the only necessary
action is phone conversation, the work tasks of
this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of
requirements.
4. E-mail to stakeholder for review and approval.
Example of a Task Set for Elicitation
The task sets for Requirements gathering
action for a simple project may include:
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.
Example of a Task Set for Elicitation
The task sets for Requirements gathering action
for a big project may include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholders 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.

 Both do the same work with different depth and

formality. Choose the task sets that achieve the goal
and still maintain quality and agility.
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).
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, Establishing
Communication would incorporate the task pattern
Requirements Gathering 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 Spiral Model or Prototyping.
 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 of61
increments to become the production software or 2. the prototype may be
discarded.
• Related patterns. CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.
 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]
 Prescriptive Models
• Originally proposed to bring order to chaos.
• Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial
to bring some creativity?

That leads to a few questions …

• If prescriptive process models strive for structure and order (prescribe a
set of process elements and process flow), are they inappropriate for a
software world that thrives on change?
• Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

to software development.
The V-Model A variation of waterfall model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.
The Incremental Model
 The Incremental Model
• When initial requirements are reasonably well
defined, but the overall scope of the
development effort precludes a purely linear
process. A compelling need to expand a limited
set of new functions to a later system release.
• It combines elements of linear and parallel
process flows. Each linear sequence produces
deliverable increments of the software.
• The first increment is often a core product with
many supplementary features. Users use it and
evaluate it with more modifications to better
meet the needs.
 Evolutionary Models
• Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end
product is not possible. However, a limited version must be
delivered to meet competitive pressure.
• Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Two types are introduced, namely Prototyping and Spiral models.
 Evolutionary Models: Prototyping
• When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure of the
efficiency of an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design) occur.
Quick design focuses on a representation of those aspects the software that will be
visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a
feel for the actual system, and developers get to build something immediately.
However, engineers may make compromises in order to get a prototype working
quickly. The less-than-ideal choice may be adopted forever after you get used to it.
Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment
delivery & Construction
feedback of prototype
Construction
of prototype
Evolutionary Models: The Spiral
• It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The other is a set of anchor point
milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be a model
or prototype. During later iterations, increasingly more complete version of the engineered system are
produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more sophisticated
versions of the software. Each pass results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.
Evolutionary Models: The Spiral
 Three Concerns on Evolutionary
Processes
• First concern is that prototyping poses a problem to project planning because
of the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.
Concurrent Model
• Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
• The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into
the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling is applicable to all types of software development and provides
an accurate picture of the current state of a project. Rather than confining software
engineering activities, actions and tasks to a sequence of events, it defines a process
network. Each activity, action or task on the network exists simultaneously with other
activities, actions or tasks. Events generated at one point trigger transitions among the
states.
Concurrent Model
 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.
The Unified Process (UP)
elaboration

inception
UP Phases
UP Work Products
 Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development tasks are
identified and a project schedule is created.
• High-level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty exists.
All issues are recorded and tracked.
• High-level design review. Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
• Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
• Postmortem. Using the measures and metrics collected (this is a substantial amount of
data that should be analyzed statistically), the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its
effectiveness.
 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.
REFERENCES
• Hartson, R. (2018). The UX Book: Agile UX Design
for A Quality User Experience 2nd edition. Morgan
Kaufmann.

• Gothelf., J. (2018). Lean Vs. Agile Vs. Design

Thinking: What You Really Need to Know To Build
High. Sense and Respond Press.

• Ries, M. et . al. (2017). Agile Project Management: A

Complete Beginner's Guide to Agile Project
Management. Createspace Independent Publishing
• Stephens, R. (2017). Beginning Software
Engineering. Sybex. Createspace Independent
Publishing

• Laplante. P. (2016). Requirements Engineering for

Software and Systems (Applied Software
Engineering Series 3rd edition. Auerbach
Publications.

• Flewelling, P. (2017). The Agile Developers

Handbook. Packt Publishing.
• Flewelling, P. (2017). The Agile Developer's Handbook: Get
More Value From Your Software Development: Get The
Best Out Of The Agile Methodology. Packt Publishing.

• Keane, T. (2017). Project Management: Proven Principles in

Agile Project Management for Successful Managers and
Businesses (Project Management 101).

• Ries, M. et . al. (2016). Agile Project Management: A

Complete Beginner's Guide To Agile Project Management.
Createspace Independent Publishing
THANK YOU.