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.
DEVELOPMENT
MODELS AND ITS
PRINCIPLES
 MODULE 2
OBJECTIVES
Upon the completion of this module, the students are
expected to:

• Distinguish the principle of agile development

• Identify the importance of agility.
• Identify the general principles
• Compare and Contrast the different principles.
AGILE DEVELOPMENT
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes
and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al
 What is “Agility”?
• Effective (rapid and adaptive) response to change (team members, new
technology, requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers。
• Drawing the customer into the team. Eliminate “us and them” attitude. Planning in
an uncertain world has its limits and plan must be flexible.
• Organizing a team so that it is in control of the work performed
• Eliminate all but the most essential work products and keep them lean.
• Emphasize an incremental delivery strategy as opposed to intermediate products
that gets working software to the customer as rapidly as feasible.
 What is “Agility”?
Yielding …
• Rapid, incremental delivery of software
• The development guidelines stress delivery over
analysis and design although these activates are
not discouraged, and active and continuous
communication between developers and
customers.
 Why and What Steps are“Agility”
important?
• Why? The modern business environment is fast-paced and
ever-changing. It represents a reasonable alternative to
conventional software engineering for certain classes of
software projects. It has been demonstrated to deliver
successful systems quickly.
• What? May be termed as “software engineering lite” The
basic activities- communication, planning, modeling,
construction and deployment remain. But they morph into
a minimal task set that push the team toward construction
and delivery sooner.
• The only really important work product is an operational
“software increment” that is delivered.
Agility and the Cost of Change
• Conventional wisdom is that the cost of change increases nonlinearly as a
project progresses. It is relatively easy to accommodate a change when a team
is gathering requirements early in a project. If there are any changes, the costs
of doing this work are minimal. But if the middle of validation testing, a
stakeholder is requesting a major functional change. Then the change requires
a modification to the architectural design, construction of new components,
changes to other existing components, new testing and so on. Costs escalate
quickly.

• A well-designed agile process may “flatten” the cost of change curve by

coupling incremental delivery with agile practices such as continuous unit
testing and pair programming. Thus team can accommodate changes late in
the software project without dramatic cost and time impact.
Agility and the Cost of Change
 An Agile Process
• Is driven by customer descriptions of what is required
(scenarios). Some assumptions:
• Recognizes that plans are short-lived (some requirements will persist, some
will change. Customer priorities will change)
• Develops software iteratively with a heavy emphasis on
construction activities (design and construction are interleaved, hard to say how much
design is necessary before construction. Design models are proven as they are created. )
• Analysis, design, construction and testing are not predictable.

• Thus has to Adapt as changes occur due to unpredictability

• Delivers multiple ‘software increments’, deliver an
operational prototype or portion of an OS to collect
customer feedback for adaption.

11
 Agility Principles - I
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face–to–face conversation.
 Agility Principles - II
7.Working software is the primary measure of progress.
8.Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9.Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
 Human Factors
• the process molds to the needs of the people and
team, not the other way around
• key traits must exist among the people on an agile
team and the team itself:
• Competence. ( talent, skills, knowledge)
• Common focus. ( deliver a working software increment )
• Collaboration. ( peers and stakeholders)
• Decision-making ability. ( freedom to control its own destiny)
• Fuzzy problem-solving ability.(ambiguity and constant changes, today
problem may not be tomorrow’s problem)
• Mutual trust and respect.
• Self-organization. ( themselves for the work done, process for its local
environment, the work schedule)
 Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck in 2004. It
uses an object-oriented approach.
• XP Planning
• Begins with the listening, leads to creation of “user stories” that describes required
output, features, and functionality. Customer assigns a value(i.e., a priority) to each
story.
• Agile team assesses each story and assigns a cost (development weeks. If more than 3 weeks,
customer asked to split into smaller stories)
• Working together, stories are grouped for a deliverable increment next release.
• A commitment (stories to be included, delivery date and other project matters) is
made. Three ways: 1. Either all stories will be implemented in a few weeks, 2. high priority
stories first, or 3. the riskiest stories will be implemented first.
• After the first increment “project velocity”, namely number of stories implemented
during the first release is used to help define subsequent delivery dates for other
increments. Customers can add stories, delete existing stories, change values of an
existing story, split stories as development work proceeds.
 Extreme Programming (XP)
• XP Design ( occurs both before and after coding as refactoring is encouraged)
• Follows the KIS principle (keep it simple) Nothing more nothing less than the story.
• Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented context. The only
design work product of XP. They identify and organize the classes that are relevant to the current
software increment. (see Chapter 8)
• For difficult design problems, suggests the creation of “spike solutions”—a design prototype for that
portion is implemented and evaluated.
• Encourages “refactoring”—an iterative refinement of the internal program design. Does not alter the
external behavior yet improve the internal structure. Minimize chances of bugs. More efficient, easy to
read.
• XP Coding
• Recommends the construction of a unit test for a story before coding commences. So implementer can
focus on what must be implemented to pass the test.
• Encourages “pair programming”. Two people work together at one workstation. Real time problem
solving, real time review for quality assurance. Take slightly different roles.
• XP Testing
• All unit tests are executed daily and ideally should be automated. Regression tests are conducted to test
current and previous components.
• “Acceptance tests” are defined by the customer and executed to assess customer visible functionality
Extreme Programming (XP)
spike solut ions
simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

refact oring

pair
programming

Release
sof t ware increment unit t est
project velocit y comput ed cont inuous int egrat ion

accept ance t est ing

The XP Debate
 Requirements volatility: customer is an active member of XP team, changes to
requirements are requested informally and frequently.
 Conflicting customer needs: different customers' needs need to be
assimilated. Different vision or beyond their authority.
 Requirements are expressed informally: Use stories and acceptance tests are
the only explicit manifestation of requirements. Formal models may avoid
inconsistencies and errors before the system is built. Proponents said changing
nature makes such models obsolete as soon as they are developed.
 Lack of formal design: XP deemphasizes the need for architectural design.
Complex systems need overall structure to exhibit quality and maintainability.
Proponents said incremental nature limits complexity as simplicity is a core
value.
 Adaptive Software Development (ASD)
• Originally proposed by Jim Highsmith
(2000)focusing on human collaboration and team
self-organization as a technique to build complex
software and system.
• ASD — distinguishing features
• Mission-driven planning
• Component-based focus
• Uses “time-boxing” (See Chapter 24)
• Explicit consideration of risks
• Emphasizes collaboration for requirements gathering
• Emphasizes “learning” throughout the process
Three Phases of ASD
• 1. Speculation: project is initiated and adaptive cycle
planning is conducted. Adaptive cycle planning uses
project initiation information- the customer’s
mission statement, project constraints (e.g. delivery
date), and basic requirements to define the set of
release cycles (increments) that will be required for
the project. Based on the information obtained at
the completion of the first cycle, the plan is reviewed
and adjusted so that planned work better fits the
reality.
 Three Phases of ASD
• 2. Collaborations are used to multiply their talent and creative output beyond
absolute number (1+1>2). It encompasses communication and teamwork, but it
also emphasizes individualism, because individual creativity plays an important
role in collaborative thinking.
• It is a matter of trust. 1) criticize without animosity, 2) assist without
resentments, 3) work as hard as or harder than they do. 4) have the skill set to
contribute to the work at hand, 5) communicate problems or concerns in a way
that leas to effective action.
• 3. Learning: As members of ASD team begin to develop the components, the
emphasis is on “learning”. Highsmith argues that software developers often
overestimate their own understanding of the technology, the process, and the
project and that learning will help them to improve their level of real
understanding. Three ways: focus groups, technical reviews and project
postmortems.
Adaptive Software Development
adapt ive cycle planning Requirement s gat hering
uses mission st at ement JAD
project const raint s mini-specs
basic requirement s
t ime-boxed release plan

Release
sof t ware increment
adjust ment s f or subsequent cycles
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
 Dynamic Systems Development Method
• It is an agile software development approach that provides a framework for
building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project
environment.
• Promoted by the DSDM Consortium (www.dsdm.org)
• DSDM—distinguishing features
• Similar in most respects to XP and/or ASD
• Nine guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for acceptance of deliverables.
• Iterative and incremental development is necessary to converge on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
Dynamic Systems Development Method

DSDM Life Cycle (with permission of the DSDM consortium)

 Scrum
• A software development method Originally proposed by Schwaber and
Beedle (an activity occurs during a rugby match) in early 1990.
• Scrum—distinguishing features
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is constructed
• Work units occurs in “sprints” and is derived from a “backlog” of existing
changing prioritized requirements
• Changes are not introduced in sprints (short term but stable) but in backlog.
• Meetings are very short (15 minutes daily) and sometimes conducted without
chairs ( what did you do since last meeting? What obstacles are you
encountering? What do you plan to accomplish by next meeting?)
• “demos” are delivered to the customer with the time-box allocated. May not
contain all functionalities. So customers can evaluate and give feedbacks.
Scrum

Scrum Process Flow (used wit h permission)

Crystal
• Proposed by Cockburn and Highsmith
• Crystal—distinguishing features
• Actually a family of process models that allow
“maneuverability” based on problem
characteristics
• Face-to-face communication is emphasized
• Suggests the use of “reflection workshops” to
review the work habits of the team
 Feature Driven Development
• Originally proposed by Peter Coad et al as a object-oriented software
engineering process model.
• FDD—distinguishing features
• Emphasis is on defining “features” which can be organized hierarchically.
• a feature “is a client-valued function that can be implemented in two weeks or
less.”
• Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
• E.g. Add the product to shopping cart.
• Display the technical-specifications of the product.
• Store the shipping-information for the customer.
• A features list is created and “plan by feature” is conducted
• Design and construction merge in FDD
Feature Driven Development

Reprinted with permission of Peter Coad

Agile Modeling
Originally proposed by Scott Ambler
Suggests a set of agile modeling principles
Model with a purpose
Use multiple models
Travel light
Content is more important than representation
Know the models and the tools you use to create
them
Adapt locally
PRINCIPLE THAT GUIDE
PRACTICE
 What, who, why?
• Software Practice is a broad array of principles, concepts, methods
and tools that you must consider as software is planned and
developed.
• Software engineers and their managers conduct a variety of
software engineering tasks are using it.
• Software Process provides everyone with a road map for getting to
a successful destination. Practice provides you with the details
you will need to drive along the road. Where the bridges, the
roadblocks, and the forks are located? It instructs you how to
drive, where to slow down, and where to speed up. In the software
engineering context, it is what you do day in and day out as
software evolves from an idea to a reality.
• Three elements: principles, concepts and methods. A fourth
element namely tools supports the application of methods.
General Principles that Span Software
Engineering Process and Practice
High Level Abstraction
• Principle #1. Provide Value to end users.
• Principle #2. Keep it simple
• Principle #3. Maintain the vision for the product and project.
• Principle #4. Recognize that other consume what you
produce
• Principle #5. Be open to the future
• Principle #6. Plan ahead for reuse
• Principle #7. Think!
 Principles that Guide Process
• Principle #1. Be agile. Whether the process model you choose is prescriptive or agile, the
basic tenets of agile development should govern your approach.
• Principle #2. Focus on quality at every step. The exit condition for every process activity,
action, and task should focus on the quality of the work product that has been produced.
• Principle #3. Be ready to adapt. Process is not a religious experience and dogma has no
place in it. When necessary, adapt your approach to constraints imposed by the problem, the
people, and the project itself.
• Principle #4. Build an effective team. Software engineering process and practice are
important, but the bottom line is people. Build a self-organizing team that has mutual trust and
respect.
Principles that Guide Process
• Principle #5. Establish mechanisms for communication and coordination. Projects fail
because important information falls into the cracks and/or stakeholders fail to coordinate their
efforts to create a successful end product.
• Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.
• Principle #7. Assess risk. Lots of things can go wrong as software is being developed. It’s
essential that you establish contingency plans.
• Principle #8. Create work products that provide value for others. Create only those work
products that provide value for other process activities, actions or tasks.
 Principles that Guide Practice
• Principle #1. Divide and conquer. Stated in a more technical manner,
analysis and design should always emphasize separation of concerns
(SoC).
• Principle #2. Understand the use of abstraction. At it core, an
abstraction is a simplification of some complex element of a system
used to communication meaning in a single phrase.
• Principle #3. Strive for consistency. A familiar context makes
software easier to use.
• Principle #4. Focus on the transfer of information. Pay special
attention to the analysis, design, construction, and testing of interfaces.
 Principles that Guide Practice
• Principle #5. Build software that exhibits effective modularity. Separation of
concerns (Principle #1) establishes a philosophy for software. Modularity provides a
mechanism for realizing the philosophy.
• Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The goal of
patterns within the software community is to create a body of literature to help
software developers resolve recurring problems encountered throughout all of
software development.
• Principle #7. When possible, represent the problem and its solution from a
number of different perspectives.
• Principle #8. Remember that someone will maintain the software.
 Communication Principles
• Principle #1. Listen. Try to focus on the speaker’s words, rather than formulating
your response to those words.
• Principle # 2. Prepare before you communicate. Spend the time to understand
the problem before you meet with others.
• Principle # 3. Someone should facilitate the activity. Every communication
meeting should have a leader (a facilitator) to keep the conversation moving in a
productive direction; (2) to mediate any conflict that does occur, and (3) to ensure
than other principles are followed.
• Principle #4. Face-to-face communication is best. But it usually works better
when some other representation of the relevant information is present.
Communication Principles
• Principle # 5. Take notes and document decisions. Someone participating in the communication should
serve as a “recorder” and write down all important points and decisions.
• Principle # 6. Strive for collaboration. Collaboration and consensus occur when the collective
knowledge of members of the team is combined …

• Principle # 7. Stay focused, modularize your discussion. The more people involved in any
communication, the more likely that discussion will bounce from one topic to the next.

• Principle # 8. If something is unclear, draw a picture.

• Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to something, move
on; (c) If a feature or function is unclear and cannot be clarified at the moment, move on.

• Principle # 10. Negotiation is not a contest or a game. It works best when both parties win.
 Planning Principles
• Principle #1. Understand the scope of the project. It’s impossible to use a
roadmap if you don’t know where you’re going. Scope provides the software team
with a destination.
• Principle #2. Involve the customer in the planning activity. The customer defines
priorities and establishes project constraints.
• Principle #3. Recognize that planning is iterative. A project plan is never
engraved in stone. As work begins, it very likely that things will change.
• Principle #4. Estimate based on what you know. The intent of estimation is to
provide an indication of effort, cost, and task duration, based on the team’s current
understanding of the work to be done.
Planning Principles
• Principle #5. Consider risk as you define the plan. If you have identified risks
that have high impact and high probability, contingency planning is necessary.
• Principle #6. Be realistic. People don’t work 100 percent of every day.
• Principle #7. Adjust granularity as you define the plan. Granularity refers to
the level of detail that is introduced as a project plan is developed.
• Principle #8. Define how you intend to ensure quality. The plan should
identify how the software team intends to ensure quality.
• Principle #9. Describe how you intend to accommodate change. Even the
best planning can be obviated by uncontrolled change.
• Principle #10. Track the plan frequently and make adjustments as required.
Software projects fall behind schedule one day at a time.
Modeling Principles
• In software engineering work, two classes of models can be
created:
• Requirements models (also called analysis models) represent the
customer requirements by depicting the software in three different
domains: the information domain, the functional domain, and the
behavioral domain.
• Design models represent characteristics of the software that help
practitioners to construct it effectively: the architecture, the user
interface, and component-level detail.
 Requirements Modeling Principles
• Principle #1. The information domain of a problem must be represented and
understood.
• Principle #2. The functions that the software performs must be defined.
• Principle #3. The behavior of the software (as a consequence of external
events) must be represented.
• Principle #4. The models that depict information, function, and behavior must
be partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion.
• Principle #5. The analysis task should move from essential information toward
implementation detail.
Design Modeling Principles
• Principle #1. Design should be traceable to the requirements model.
• Principle #2. Always consider the architecture of the system to be built.
• Principle #3. Design of data is as important as design of processing functions.
• Principle #5. User interface design should be tuned to the needs of the end-user. However, in every
case, it should stress ease of use.
• Principle #6. Component-level design should be functionally independent.
• Principle #7. Components should be loosely coupled to one another and to the external
environment.
• Principle #8. Design representations (models) should be easily understandable.
• Principle #9. The design should be developed iteratively. With each iteration, the designer should
strive for greater simplicity.
Agile Modeling Principles

• Principle #1. The primary goal of the software team is to build software, not create models.
• Principle #2. Travel light—don’t create more models than you need.
• Principle #3. Strive to produce the simplest model that will describe the problem or the software.
• Principle #4. Build models in a way that makes them amenable to change.
• Principle #5. Be able to state an explicit purpose for each model that is created.
• Principle #6. Adapt the models you develop to the system at hand.
• Principle #7. Try to build useful models, but forget about building perfect models.
• Principle #8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully,
representation is secondary.
• Principle #9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have
reason to be concerned.
• Principle #10. Get feedback as soon as you can.
Construction Principles
• The construction activity encompasses a set of coding and
testing tasks that lead to operational software that is ready
for delivery to the customer or end-user.
• Coding principles and concepts are closely aligned
programming style, programming languages, and
programming methods.
• Testing principles and concepts lead to the design of tests
that systematically uncover different classes of errors and to
do so with a minimum amount of time and effort.
Preparation Principles

• Before you write one line of code, be sure you:

• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be built
and the environment in which it will operate.
• Select a programming environment that provides tools that will make your
work easier.
• Create a set of unit tests that will be applied once the component you code is
completed.
Coding Principles
• As you begin writing code, be sure you:
• Constrain your algorithms by following structured programming [Boh00] practice.
• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that aids understanding.
 Validation Principles

• After you’ve completed your first coding pass, be sure

you:
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.
Testing Principles
• Al Davis [Dav95] suggests the following:
• Principle #1. All tests should be traceable to customer
requirements.
• Principle #2. Tests should be planned long before testing
begins.
• Principle #3. The Pareto principle applies to software testing.
• Principle #4. Testing should begin “in the small” and progress
toward testing “in the large.”
• Principle #5. Exhaustive testing is not possible.
Deployment Principles
• Principle #1. Customer expectations for the software must be managed. Too
often, the customer expects more than the team has promised to deliver, and
disappointment occurs immediately.
• Principle #2. A complete delivery package should be assembled and tested.
• Principle #3. A support regime must be established before the software is
delivered. An end-user expects responsiveness and accurate information when a
question or problem arises.
• Principle #4. Appropriate instructional materials must be provided to end-
users.
• Principle #5. Buggy software should be fixed first, delivered later.
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.