1

SE311-Software Construction & Development

Week 1 Lecture 1 & 2

Instructor: Ali Haider

 2
Agenda

► Introduction to software development process

► Adaptive vs. Predictive software development
► Traditional Software development process
► Waterfall model
► Iterative developmet
► Reuse oriented software engineering
 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

2
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 mechanisms3 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
4
automated tools.
A Generic Process Model 5
 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.
6
Process Flow

7
 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
8
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
9
 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.
10
Example of a Task Set for Elicitation

■■ The task sets for Requirements gathering action

forsimple
a 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.
1
6. Note areas of uncertainty. 1
 4
Introduction: Software Process

► There are many different software processes but all must include four activities that are
fundamental to software engineering:
1. Software specification The functionality of the software and constraints on its operation must
be defined.
2. Software design and implementation The software to meet the specification must be
produced.
3. Software validation The software must be validated to ensure that it does what the customer
wants.
4. Software evolution The software must evolve to meet changing customer needs.
Software Process

► When we describe and discuss processes, we usually talk about the activities in these
processes such as specifying a data model, designing a user interface, etc., and the
ordering of these activities. However, as well as activities, process descriptions may also
include:
► Products
► Roles
► Pre- and post-conditions
 5
Introduction

Software Development Process

Traditional Agile

Incremental Extreme
Waterfall Spiral SCRUM
iterative programming
 6
Adaptive vs. Predictive approach

► Adaptive methods focuses on adapting quickly to change

► When the project requirement change the adapted team also change
► An adaptive team cannot report exactly what tasks will be done in next week
► An Example of adaptive methods is Agile
 7
Adaptive vs. Predictive approach

► Predictive method focus on planning the future in details

► Predictive team can report exactly what features and tasks are planned for the entire
length of the development process.
► Predictive team have difficulty changing direction, the plan is typically optimized for the
original destination and changing direction can require completed work to be started over
 8
Traditional software development Methods

► Waterfall
► Iterative Incremental
► RAD (Rapid Application Development)
► RUP (Rational Unified Process)
► Spiral
► V-Model
► Reuse-oriented software engineering
 9
Cont’d

► These models are not mutually exclusive and are often used together, especially for large
systems development. For large systems, it makes sense to combine some of the best
features of the waterfall and the incremental development models.
 10
Waterfall Model

► This model is known as the ‘waterfall model’ or software life cycle. The waterfall model
is an example of a plan-driven process—in principle, you must plan and schedule all of
the process activities before starting work on them.
► The following phase should not start until the previous phase has finished.
► In practice, these stages overlap and feed information to each other. During design,
problems with requirements are identified. During coding, design problems are found and
so on
► The software process is not a simple linear model but involves feedback from one phase to
another. Documents produced in each phase may then have to be modified to reflect the
changes made.
 11
Waterfall model
 12
Cont’d

► Requirements analysis and definition The system’s services, constraints, and goals are
established by consultation with system users.
► They are then defined in detail and serve as a system specification.
► System and software design The systems design process allocates the requirements to
either hardware or software systems by establishing an overall system architecture.
► Software design involves identifying and describing the fundamental software system
abstractions and their relationships.
 13
Cont’d

► Implementation and unit testing During this stage, the software design is realized as a
set of programs or program units.
► Unit testing involves verifying that each unit meets its specification.
► Integration and system testing The individual program units or programs are integrated
and tested as a complete system to ensure that the software requirements have been met.
► After testing, the software system is delivered to the customer.
 14
Cont’d

► Operation and maintenance Normally (although not necessarily), this is the longest life
cycle phase. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life cycle, improving
the implementation of system units and enhancing the system’s services as new
requirements are discovered.
 15
When to use Waterfall Model

► In principle, the waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.
► However, the waterfall model reflects the type of process used in other engineering
projects. As is easier to use a common management model for the whole project, software
processes based on the waterfall model are still commonly used.
 16
Drawbacks of Waterfall Model

► Because of the costs of producing and approving documents, iterations can be costly and
involve significant rework.
► Therefore, after a small number of iterations, it is normal to freeze parts of the
development, such as the specification, and to continue with the later development stages.
► Problems are left for later resolution, ignored, or programmed around.
► This premature freezing of requirements may mean that the system won’t do what the user
wants.
► It may also lead to badly structured systems as design problems are circumvented by
implementation tricks.
 17
Drawbacks of Waterfall Model

► Designers may not be aware of future Implementation

► Client may not know exactly what requirements he need and he will need to change his
requirements at any time
► Stakeholders may not be fully aware of the capabilities of the technology being
implemented
 18
Incremental Development

► Incremental development is based on the idea of developing an initial implementation,

exposing this to user comment and evolving it through several versions until an adequate
system has been developed.
► It is better than a waterfall approach for most business, e-commerce, and personal
systems.
► Incremental development reflects the way that we solve problems. We rarely work out a
complete problem solution in advance but move toward a solution in a series of steps,
backtracking when we realize that we have made a mistake.
► By developing the software incrementally, it is cheaper and easier to make changes in the
software as it is being developed.
 19
Incremental Development

► Each increment or version of the system incorporates some of the functionality that is
needed by the customer.
► Generally, the early increments of the system include the most important or most urgently
required functionality.
► This means that the customer can evaluate the system at a relatively early stage in the
development to see if it delivers what is required.
► If not, then only the current increment has to be changed and, possibly, new functionality
defined for later increments.
 20
Incremental Development
 21
Benefits

Incremental development has three important benefits, compared to the waterfall model:
► The cost of accommodating changing customer requirements is reduced. The amount
of analysis and documentation that has to be redone is much less than is required with the
waterfall model.
► It is easier to get customer feedback on the development work that has been done.
Customers can comment on demonstrations of the software and see how much has been
implemented. Customers find it difficult to judge progress from software design
documents.
 22
Benefits

► More rapid delivery and deployment of useful software to the customer is possible, even
if all of the functionality has not been included. Customers are able to use and gain value
from the software earlier than is possible with a waterfall process.
 23
Drawbacks

► From a management perspective, the incremental approach has two problems:

► The process is not visible. Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce documents that reflect
every version of the system.
► System structure tends to degrade as new increments are added. Unless time and money is
spent on refactoring to improve the software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly difficult and costly.
 A variation of waterfall model
The V-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.

19
 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
22

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
23 may make
. compromises in order to get a prototype working quickly.
Evolutionary Models: Prototyping

Q u ick p lan
Quick
Com m u n ication plan
communication
Mo d e lin g
Modeling n
Q u ick d e sig
Quick design

Deployment
Deployment
De live ry
Construction
delivery &
& Fe e dback of Con
prototype
stru ction
feedback Construction
of
prototype
of prototype

24
 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;25subsequent
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
Evolutionary Models: The
Spiral planning
estimatio
n
schedulin
g risk
communicati analysis
on
modeli
ng
analysi
star s
t design

deployme
nt constructio
delivery n
feedback code
26
test
 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.
27
 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 30incrementally.
The Unified Process (UP)
Elabor
elaboration
ation

Incep
inception
tion

constr
Release uction
software
increment tr ansition
31
pr od
uction
UP Work Products
Inception phase

Elaboration phase Construction

Vision document phase
Design model
Initial use-case Transition
Software
model Initial Use-case model phase
Delivered software
components
project glossary Supplementary increment Beta test
Integrated
Initial business requirements including reports
software
case Initial risk non-functional Analysis General user feedback
increment
assessment. model Test plan and
Project plan, Software architecture procedure Test
phases and iterations. Description. cases
Business Executable
Support
model, if architectural documentation
necessary. prototype. user manuals
One or more prototypes Preliminary design installation
model Revised risk manuals
list description of
Project plan including current increment
iteration plan
adapted
workflows
milestones
technical work
products Preliminary
user manual
33
 24
Reuse-oriented software engineering

► In the majority of software projects, there is some software reuse. This often happens
informally when people working on the project know of designs or code that are similar to
what is required. They look for these, modify them as needed, and incorporate them into
their system.
 25
Reuse-oriented software engineering
 26
Reuse-oriented software engineering

► Component analysis Given the requirements specification, a search is made for

components to implement that specification. Usually, there is no exact match and the
components that may be used only provide some of the functionality required.
► Requirements modification During this stage, the requirements are analyzed using
information about the components that have been discovered. They are then modified to
reflect the available components. Where modifications are impossible, the component
analysis activity may be re-entered to search for alternative solutions.
 27
Reuse-oriented software engineering

► System design with reuse During this phase, the framework of the system is designed or
an existing framework is reused. The designers take into account the components that are
reused and organize the framework to cater for this. Some new software may have to be
designed if reusable components are not available.
► Development and integration Software that cannot be externally procured is developed,
and the components and COTS (commercial off-the-shelf systems) systems are integrated
to create the new system. System integration, in this model, may be part of the
development process rather than a separate activity.
► COTS products are designed to be easily installed and to interoperate with
existing system components
 28
Reuse-oriented software engineering

► There are three types of software component that may be used in a reuse-oriented process:
► Web services that are developed according to service standards and which are available
for distant request.
► Collections of objects that are developed as a package to be integrated with a component
framework such as .NET or J2EE.
► Stand-alone software systems that are configured for use in a particular environment.
 29
Pros and cons

► Reuse-oriented software engineering has the obvious advantage of reducing the amount of
software to be developed and so reducing cost and risks. It usually also leads to faster
delivery of the software.
► However, requirements compromises are unavoidable and this may lead to a system that
does not meet the real needs of users. Furthermore, some control over the system
evolution is lost as new versions of the reusable components are not under the control of
the organization using them.
 30
References

► Software Engineering Ian Sommerville edition 9th (2011) chapter 2

LAB TASK 1:

► A canvas consists of many figures. Figures could be circles, lines, polygons, or groups. A
group consists of many figures. When a client asks the canvas to draw itself, the canvas
asks its associated figures to draw themselves. Each figure (circles, line, or polygons) is
responsible for drawing itself in an appropriate way. Note that the canvas does not have to
ask each figure which kind of figure it is; it just has to call the draw operation and
everything else works automatically.
► Draw the class diagram for the above stated scenario.
LAB TASK 2:

Pre condition: card holder has searched the book

Post condition: Card holder has book and book issuance receipt
Main Success Scenario
► Card holder notes the books accession no, DDC # and shelf no
► Card holder (CH) finds the shelf and get the book
► Card holder presents the book to counter officer
► Counter officer (CO) checks the book status (should not be reference section book)
► Counter officer prompts for the library card
► CH provides the library card
► CO verifies the card
► CH fills the book issuance card
► CO verifies book issuance card
► CO issues the receipt
► CH gets the receipt and the book
Draw the sequence diagram for the above stated use case scenario.