Software Engineering

Unit I: SOFTWARE PROCESS

The Nature of the Software:

• Software is both a product and vehicle that delivers a product.

• Software is engineered, not manufactured.
• Software doesn’t wear out, but it does deteriorate

Defining Software:

• Software is an instruction, when it executed provides desired features,

functions and performance.
• Software is data structures that enable the programs to manipulate
information.

Software Application Domains:

• System software
o Written to provide service to other programs
o Some system software (Operating System, Compilers)
• Application software
o Stand-alone programs that solve a specific business need.
• Engineering/Scientific software
o Applications ranging from astronomy to volcanology.
• Embedded Software
o Resides within a product or system
o Used to implement and control features and functions for the end user
o It performs limited functions
o E.g., Key pad control for a microwave oven
• Product-line software
o Designed to provide a specific capability for use by many different
customers.
o E.g., Inventory Control Products, word processing, spreadsheets.
 • Web applications
o It is also called WebApps
o It is special type of application run on the internet.
• Artificial intelligence software
o Applications within this area include robotics, expert systems, pattern
recognition (image and voice), and artificial neural networks.

Legacy Software:

• Legacy software means old software developed decades ago.

• What type of changes are made to legacy systems?

o The software must be adapted to meet the current needs.

o It must be enhanced to implement new requirements.
o It must be extended to make it interoperable with modern systems or
databases.

Characteristics that differentiate WebApps from other Software:

• Network intensiveness
• Concurrency
• Unpredictable load
• Performance
• Availability
• Data driven
• Content sensitive
• Continuous evolution
• Immediacy
• Security
• Aesthetics
Software Engineering:

• Software engineering is systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software.
• Software engineering encompasses a process and methods

A Layered Technology:

Tools
Methods
Process
A Quality Focus
A Quality Focus:

• The Bedrock that support software engineering is a quality focus

Process:

• The foundation for software engineering is the process layer.

• Software engineering process is the glue that holds the technology layers
together.
• Process defines a framework and forms the basis for management control of
software projects.
Methods:

• Methods provide the technical how-to’s for building software

Tools:

• Tools provide automated or semi automated support for the process and
methods.

The Software Process:

• A process is a collection of activities, actions, and tasks that are performed

when some work product is to be created.
• In the context of software engineering, a process is not a rigid prescription
for how to build computer software rather it is an adaptable approach
• The software team must choose the appropriate set of actions and task set.
• The intent is always to deliver software in a timely manner and with
sufficient quality.

Generic Process Frame Work Activities:

A process framework establishes the foundation for a complete software

engineering process

It encompasses five activities:

• Communication
o Involves communication among the customer and other stake holders.
o encompasses requirements gathering
• Planning
o Establishes a plan for software engineering work; addresses technical
tasks, resources, work products, and work schedule
• Modeling
o Encompasses the creation of models to better understand the
requirements and the design
 • Construction
o Combines code generation and testing to uncover errors
• Deployment
o Involves delivery of software to the customer for evaluation and
feedback

Umbrella Activities:

• Software engineering process framework activities are complemented by

umbrella activities
• It applied throughout the software project
• It helps a software team manage and control progress, quality, change and
risk
• It mainly focus on project management, tracking and control

Umbrella Activities Include:

• Software project tracking and control:

o It assess the project progress against the project plan
o Take necessary actions to maintain the schedule
• Risk management:
o Assess risks that may affect the outcome of the project or the quality
of the product
• Software quality assurance:
o Defines and conducts the activities required to ensure software quality
• Technical reviews:
o Assess work products in an effort to uncover and remove errors.
• Measurement:
o Defines and collects process, project, and product measures that assist
the team.
• Software configuration management:
o Manages the effects of change throughout the software process
• Reusability management:
o Defines criteria for work product reuse and reusable components.
 • Work product preparation and production
o Encompasses the activities required to create work products
o Such as:

Models

Documents

Logs

Forms

Lists

How do process models differ from one another?

• Overall flow of activities, actions, and tasks

• Degree to which actions and tasks are defined within each framework
activity
• Degree to which work products are identified and required.
• Manner in which quality assurance, project tracking and control activities
are applied.
• Degree to which team organization and roles are prescribed.

Process Models
• Software process is represented by framework activities and each action is
defined by Task set.
• Each Task set is populated by Work Task, Work Products, and Project
Milestones.
• The hierarchy of technical work within the software process is activities,
encompassing actions, populated by tasks.

Process Flow:

• Process flow describes how the framework activities and the actions and
tasks are organized with respect to sequence and time.
• Types of process flow:
o Linear process flow
o Iterative process flow
o Evolutionary process flow
o Parallel process flow
 Generic
process
Framework
activities

Process
model
Process
flow

Process Pattern:

• A process pattern describes process-related problems and its solutions.

• Process pattern provides us with a template for describing problem solution
within the context of the software process.
• Patterns can be defined at any level of abstraction
• A pattern might be used to describe problems associated with complete
process model or any one framework activity or actions.
• Ambler has proposed following template for describing a process pattern:
o Pattern Name(name of the pattern)
o Intent(for which problem this pattern is indented to )
o Type (type of the pattern: phase or stage or task)
o Initial context(describes the conditions under which the pattern
applies)
o Problem(the specific problem)
o Solution (describes how to implement the pattern successfully)
o Resulting context(describes the result)
o Related patterns(provide list of patterns directly related to this
pattern)
o Known uses and examples(the specific instance in which the pattern
is applicable)
Process Assessment and Improvement

• Assessment attempts to understand the current state of the software process

with the intent of improving it.
• A number of different approaches to software process assessment and
improvement:
o Standard CMMI Assessment Method for Process Improvement
o CMM – Based Appraisal For Internal Process Improvement
o SPIECE (ISO/IECI 15504)
o ISO 9001:2000 for Software

Prescriptive Process Models

• Prescriptive process models were proposed to bring order to the software

development
• The traditional models have brought useful structure to Software
Engineering and provided effective road map for software team.
• Prescriptive process models define a set of process elements and a
predictable process flow.
• All software process models can accommodate the Generic Process
Framework activities.
• Process models are:
o The Waterfall Model
o Incremental Process Model
o Evolutionary Process Model

Prototyping

The Spiral Model

Concurrent Model
The Waterfall Model:

• The original waterfall model proposed by Winston Royce.

• This model is strictly linear type.
• The waterfall model, sometimes called the classic lifecycle, suggests a
systematic sequential approach to software development.

• When to use waterfall

all model:

When the requirements of a problem are reasonably well

understood

When the work flows from communication through deployment
in a reasonably linear fashion.

When requirements are well
well-defined
defined and reasonably stable.

• Drawbacks of using a waterfa

waterfall model:

Real projects rarely follow the sequential flow.

Changes can cause confusion as the project team proceeds.

The waterfall model leads to “blocking states” in which some
project team members must wait for other members of the team
to complete dependent tasks.

The customer must have patience to see working version of the
program until the deployment.
Incremental Process Model

• The incremental model combines elements of the waterfall model applied in

an iterative fashion.
• The incremental model applies linear sequence in a staggered fashion.
• Each linear sequence produces deliverable “increments” of the software.
• The incremental model delivers a series of releases, called increments that
provide progressively more functionality for the customer as each increment
is delivered.
• When incremental software is used, the first increment is often a core
product. That is, basic requirements are addressed, but many supplementary
features remain undelivered.
• The core product is used by the customer. As a reresult
sult of use and/or
evaluation, a plan is developed for the next increment.
• Unlike prototyping, the incremental model focuses on the delivery of an
operational product with each increment.

Increment #1

Incremental Process Model

Evolutionary Process Models

• Evolutionary process models produce an increasingly more complete version

of the software with each iteration.
• Evolutionary models are iterative
• The models are:
o Prototyping
o The Spiral Model
o Concurrent Model

Prototyping

• In prototyping model before ddevelopment

evelopment of the actual software, a working
prototype of the system built first.
• There are several reasons for developing a prototype. An important purpose
is to illustrate the input data formats, messages, reports, and the interactive
dialogues to the customer.
stomer.
• Another important use of the prototyping model is that it helps to critically
examine the technical issues associated with the product development.
• The model starts with an initial requirements gathering, quick design and
build prototype, customer evaluation, refine requirements.
• If the prototype is accepted by the customer the actual software will be
developed.
• If not accepted by the customer the prototype simply thrown away and again
go to building of new prototype until the customer accepts the pprototype.
The drawbacks of using Prototype Mode:

The customer sees what appears to be a working version of the software.

Unaware of the prototype will be thrown away.

The developer often makes implementation compromises in order to get a
prototype working quickly.

The Spiral Model

• The spiral model, originally proposed by Berry Boehm

• It couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
• Using the spiral model, software is developed in series of evolutionary
releases.
• During early iterations, the release might be a paper model or
prototype.
• During later iterations, increasingly more complex versions of the
system produced.
• A spiral model is divided into a set of framework activities defined by
the software engineering team.
• The first circuit around the spiral might results in the development of
a product specification.
• Subsequent passes around the spiral might be used to develop a
prototype and the progressively more sophisticated versions of the
software
• Cost and schedule are adjusted based on feedback derived from the
customer after delivery.
• Unlike other process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the
computer software.
• The spiral model is a realistic approach to the development of large-
scale systems and software.
 The Spiral Model

When to use Spiral Model:

• When creation of a prototype is appropriate

• When costs and risk evaluation is important

• For medium to high-risk

risk pr
projects

• Long-term
term project commitment unwise because of potential changes to
economic priorities

• Users are unsure of their needs

• Requirements are complex

• New product line

 • Significant changes are expected (research and exploration)

Spiral Model Weaknesses:

• Time spent for evaluating risks too large for small or low-risk projects

• Time spent planning, resetting objectives, doing risk analysis and

prototyping may be excessive

• The model is complex

• Risk assessment expertise is required

• Spiral may continue indefinitely

• Developers must be reassigned during non-development phase activities

• May be hard to define objective, verifiable milestones that indicate readiness

to proceed through the next iteration

The Concurrent Development Model:

• The concurrent development model, sometime called concurrent

engineering, can be represented schematically as a series of framework
activities, software engineering actions and tasks, and their associated states.
• The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities.
Actions or tasks.
• The concurrent process model is applicable to all type of software
development and provides an accurate picture of the current state of project.
Specialized Process Models

 Component-Based Development

 The Formal Methods Model

 Aspect-Oriented Software Development

Component-Based Development

 Commercial off-the-shelf (COTS) software components, developed by

vendors.

 The vendors offer them as a product.

 They provide them with functionality; well-defined interface enables them to

integrate into the software that is being developed.

 Component –based development model constructs applications from

prepackaged software components

 Modeling and construction activities begin with the identification of

candidate components.

 These components can be designed as either conventional software modules

or object-oriented classes or packages of classes.

 The component-based development model:

o Available component-based products are researched and evaluated for

the application

o Component integration issues are considered.

o A software architecture is designed to accommodate the components.

o Components are integrated into the architecture.

o Comprehensive testing is conducted to ensure proper functionality.

Formal Methods Model

 The Formal Methods Model encompasses a set of activities that leads to

formal mathematical specification of computer software.

 It specifies, develops, and verifies a system by applying a rigorous,

mathematical notation.

 When formal methods are used during development, they provide a

mechanism for eliminating many of the problems.

 Offers the promise of defect-free software

 Used often when building safety-critical systems

Aspect-Oriented Software Development

 Aspect-oriented software development (AOSD), is a new software

engineering standard that provide process and methodological approach.

 For defining, specifying, designing and constructing aspects.

 AOSD defines “aspects” that express customer concerns that cut across
multiple system functions, features, and information

The Unified Process:

 The Unified Process is a “use case driven, architecture-centric, iterative and

incremental” software process designed as a framework for UML methods
and tools.

 Proposed by Jacobson, Rumbaugh, and Booch.

 Today, the Unified Process and UML are widely used on Object-Oriented
Projects of all kinds.
 Inception:

◦ Encompasses the both customer communication and planning

activities

◦ Fundamental business requirements are described through a use cases.

◦ A rough architecture is developed.

 Elaboration:

◦ Encompasses the communication and modeling activities.

◦ Elaboration refines and expands preliminary use cases.

◦ And expands the architectural representation to include five different

views of the software:

 The use case model

 The requirement model

 The design model

 The implementation model

 The deployment model

 Construction:

◦ Identical to the construction activity defined for the generic software

process.

◦ Using the architectural model as input, the construction phase

develops or acquire the software components.

◦ All necessary and required features and functions for the software
increment are then implemented in source code.

 Transition:
 ◦ In this phase is given to end users for beta testing and user feedback
reports both defects and necessary changes.

◦ In addition, the software team creates the necessary support

information (user manuals, trouble shooting guides, installation
procedures)

◦ At the conclusion of this phase the software increment becomes a

usable software release.

 Production:

◦ During this phase, the ongoing use of the software is monitored and
supported.
Personal and Team Software Process:

1. Personal software process (PSP):

 Every developer uses some process to build computer software.

 The process may be ad hoc, may change on a daily basis, may not be
efficient, or even successful. But a process does exist.
 The Personal Software Process (PSP) emphasizes personal
measurement of both the work product and the quality of the work
product.
 In addition PSP makes the practitioner responsible for project
planning and empowers the practitioner to control the quality of
software work product.

The PSP defines five frame work activities:

1. Planning
2. High-level design
3. High-level design review
4. Development
5. Postmortem

2. Team Software Process (TSP):

 Watts Humphrey extended the lessons learned from the introduction

of PSP and proposed a team software process.
 The goal of TSP is to build a “self-directed” project team that
organizes itself to produce high-quality software.

Humphrey defines the following objectives for TSP:

Build self-directed team that plan and track their work, establish goals and
plans.

A self-directed team has a consistent understanding of its overall goals and
objectives. It defines roles and responsibilities for each team member.

Show managers how to motivate their teams.

Accelerate software process improvement by making CMM level 5
expected.

Provide improvement guidance to high-maturity organization.

Facilitate university teaching of industrial – grade team skills.

The TSP defines the following framework activities:

1. Launch
2. High-level design
3. Implementation
4. Integration and test
5. Postmortem

 Like in PSP these activities enable the team to plan, design, and construct
software in a disciplined manner.
 TSP makes use of a wide variety of scripts, forms and standards that
serve to guide team members in their work.

Agile Development

What is Agility?

• Agility means quick response to change.

• It adopts customers as a part of the development team

What is an Agile Process?

• Agile methods are sometimes referred to as light methods or lean methods

• An agile process reduces the cost of change
• Because software is released in increments and change can be better
controlled within an increment.
Extreme Programming

• Extreme Programming (XP), the most widely used approach to agile

software development.
• Extreme Programming uses an object-oriented approach.
• XP Values:
o Beck defines a set of five values that establishes a foundation for all
work performed as part of XP

Communication

Simplicity

Feedback

Courage

Respect
o Each of these values is used as driver for specific XP activities,
actions and tasks.
• The XP Process:
o Framework activities:

Planning
• This activity begins with listening – a requirements
gathering activity
• Listening leads to the creation of a set of “user stories”
(that describe required output, features and functionality
for the software.)
• Customer and developers work together to decide how to
group “user stories” for the release.
• Once commitment is made. The XP team makes an order
of the stories for the development.
• After the first release, the XP team computes project
velocity. (project velocity is the number of customer
stories implemented during the first release)

Design
• XP design follows the KIS principle
 • Rather than design XP recommends use of CRC cards
and spike solution(the immediate creation of operational
prototype)
• XP encourages refactoring
• Refactoring is the process of changing the internal
structure of design or source code without affecting its
external behaviour.

Coding
• A key concept implemented during coding is pair
programming.
• XP recommends that two people work together at one
computer station to create code for story.

Testing
• Unit test is done before the code developed.
• Acceptance test are performed based user stories
• Acceptance test focus on overall system features and
functionality.