Software Engineering

Sobia Iftikhar Week 02

[email protected]
Content
• software process,

• Fundamental Software Engineering Activities

• Linear and Parallel Software

• Software Process Framework

• Software process models,

• Process Improvement

• The waterfall model,

• Waterfall model phases,

• Waterfall model problems,

Software Process
• A software process is a set of related activities that leads to the production of a software system.
 Software Process

• There is no universal software engineering method that is

applicable to all of them. Consequently, there is no
universally applicable software process.
• The process used in different companies depends on the type
of software being developed, the requirements of the
software customer, and the skills of the people.
For Example:
• Imagine two software development teams working on different projects for distinct companies.
Team A is tasked with developing a mobile banking application, while Team B is working on a
virtual reality gaming software. The differences in the nature of these projects highlight the need
for distinct software engineering methods and processes.
• Team A - Mobile Banking Application:
• involves high-security standards, compliance with financial regulations, and seamless integration with
existing banking systems.

• Team B - Virtual Reality Gaming Software:

• The emphasis here may be on graphics rendering, user experience in a virtual environment, and real-time
interaction
Example con’t

Virtual Reality Gaming Software

Aspect Mobile Banking Application (Team A) (Team B)

Testing Approach

Process Cycle

Customer Involvement
Example con’t

Mobile Banking Application Virtual Reality Gaming

Aspect (Team A) Software (Team B)

Priority on performance and user

High emphasis on security and
Testing Approach experience testing in a virtual
compliance testing
environment

Iterative development with

Development Cycle Structured waterfall approach
frequent releases

Regular involvement with

Close collaboration with gamers
banking stakeholders for
Customer Involvement to collect feedback on the virtual
alignment with financial
reality experience
standards
Software Process Must Include The Following Four
Activities:

Software
Software
specification (or Software verification
Software design and evolution (software
requirements and validation:
implementation: maintenance):
engineering): The software must
The software is to be The software is being
Define the main conforms to it’s
designed and modified to meet
functionalities of the specification and meets
programmed. customer and market
software and the the customer needs.
requirements changes.
constrains around them.
Linear and Parallel Software
• A linear process flow executes each of the five framework activities in sequence, beginning with
communication and culminating with deployment.

Communication Modeling Deployment

Planning Construction
Parallel Process
• Executes One Or More Activities In Parallel With Other Activities.
Iterative Process Flow
• An iterative process flow repeats one or more of the activities before proceeding
to the next.
Evolutionary Process
• An evolutionary process flow executes the activities in a
“circular” manner.
Software Process Model
• A software process model is an abstraction of the actual process, which is being described.
• It can also be defined as a simplified representation of a software process.
• Each model represents a process from a specific perspective.
• Basic software process models on which different type of software process models can be
implemented
Waterfall Model
• The waterfall model is a sequential approach, where each fundamental activity of a process
represented as a separate phase, arranged in linear order.
• In the waterfall model, you must plan and schedule all of the activities before starting working on
them (plan-driven process).
• The waterfall model, sometimes called the classic life cycle,
Waterfall Model

Communication: Requirement gathering

Planning: Estimation scheduling tracking

Modeling: Analysis Design

Construction: Code Test

Deployment: Delivery Support Feedback

Waterfall - con’t
• The result of each phase in the waterfall model is one or more documents that are approved
(“signed off”).
• eg For hardware development
• high manufacturing costs are involved
• Software development
• These stages overlap and feed information to each other
• If new Information Emerges in software Process:
• customers and developers may prematurely freeze the software specification
Waterfall - con’t
• In reality, software has to be flexible and accommodate change as it is being developed. The
need for early commitment and system rework when changes are made means that the waterfall
model is only appropriate for some types of system:

1. Embedded systems where the software has to interface with hardware systems. Because of
the inflexibility of hardware
• For example, consider an embedded system in a car's anti-lock braking system. The hardware components
responsible for processing sensor data and controlling the brakes have specific functionalities and cannot be
easily modified or upgraded after manufacturing.

.
Waterfall - con’t
2. Critical systems where there is a need for extensive safety and security analysis of the
software specification and design
For example, consider an aircraft's flight control system. The specification and design
documents must detail how the system responds to various inputs, ensures stability, and
includes fail-safe mechanisms.
Waterfall - con’t
3. Large software systems that are part of broader engineering systems developed by
several partner companies.
eg: such as a modern electric vehicle (EV) with an integrated charging infrastructure. This
example involves large software systems as part of a broader engineering system, and the
hardware, both in the vehicle and the charging infrastructure, is developed using a common
model to streamline collaboration and interoperability.
Water Fall Model
• 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. It
establishes an overall system architecture.
A variation in waterfall model
• A variation in the representation of the waterfall model is called the V-model.
• V Model is a highly disciplined SDLC model in which there is a testing phase parallel to each
development phase.
• The V model is an extension of the waterfall model in which testing is done on each stage parallel
with development in a sequential way
 Requirement Acceptance
Modeling Testing
V-Model
Architectural
Ve Design System Testing
ri
fic

Component
Integration
a
t io

Design

n
Testing
n

a t io
id
Val
Code Unit
Generation Testing

Executable
Product
Issues With Waterfall Model
• Real projects rarely follow the sequential flow that the model proposes. Although the linear model
can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
• It is often difficult for the customer to state all requirements explicitly. The waterfall model
requires this and has difficulty accommodating the natural uncertainty that exists at the beginning
of many projects.
• The customer must have patience. A working version of the program(s) will not be available until
late in the project time span. A major blunder, if undetected until the working program is reviewed,
can be disastrous.
Content
• Incremental development
• Incremental development benefits,
• Incremental development problems,
• Integration and configuration,
• Types of reusable software
waterfall
Water Fall Model Phases
Plan-driven Approaches
• Plan-driven processes are processes where all of the process activities are planned
in advance and progress is measured against this plan.
• The waterfall model is not the right process model in situations where informal
team communication is possible and software requirements change quickly.
Drawback of Water Fall Model
• A Previous phase has to be complete before moving onto the next phase.
• Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.
• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites.
Incremental Development
• Incremental development is based on the idea of developing an initial
implementation, getting feedback from users and others, and evolving
the software through several versions until the required system has
been developed.
Incremental Development-Process
Incremental Development Benefits

The cost of implementing requirements changes is reduced. The amount of analysis and documentation that
has to be redone is significantly 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 fromsoftware design documents.

Early 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..
Incremental
Approach Has Two
Problems:
Problems might cause due to
system architecture as such not all
requirements collected up front for
the entire software lifecycle
Integration and configuration
• Based on software reuse where systems are integrated from existing components
or application systems (sometimes called COTS -Commercial-off-the-shelf)
systems).
• Reused elements may be configured to adapt their behaviour and functionality to a
user’s requirements
• Reuse is now the standard approach for building many types of business system
Types of reusable software
• Stand-alone application systems (sometimes called COTS) that are configured for
use in a particular environment.
• Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or J2EE.
• Web services that are developed according to service standards and which are
available for remote invocation.
 Reuse oriented The requirements are
modified to reflect the
software engineering available components,
and the system
specification is re-
defined.

The initial requirements for the Candidate components and

system are proposed. These do If an off-the-shelf n If there is no off-the-
systems are evaluated to
not have to be elaborated in application system that shelf system, individual
see if they meet the
detail but should include brief meets the requirements is reusable components may
essential requirements and
descriptions of essential available, it may then be be modified and new
if they are generally
requirements and desirable configured for use to components developed.
suitable for use in the
system features. create the new system.
system.
Reuse-oriented software engineering
• configuration and integration, 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.
Process-Activity
• The four basic process activities:
1. Specification
2. Development
3. Validation
4. evolution
are organized differently in different development processes.

• In the waterfall model, they are organized in sequence, whereas in incremental development they
are interleaved.
• How these activities are carried out depends on the type of software being developed, the
experience and competence of the developers, and the type of organization developing the
software.
Software specification/ Requirements Engineering
• Software specification or requirements engineering is the process of understanding and defining
what services are required from the system and identifying the constraints on the system’s
operation and development.
• Requirements engineering is a particularly critical stage of the software process, as mistakes made
at this stage inevitably lead to later problems in the system design and implementation.
• Before the requirements engineering process starts, a company may carry out a feasibility or
marketing study to assess whether or not there is a need or a market for the software
 Requirements Engineering Process translating the information gathered
during requirements analysis into a
document that defines a set of
requirements.
User requirement
End-User requirement
This is the process of deriving
the system requirements
through observation of existing
systems

This activity checks the

requirements for realism,
consistency, and
completeness
Software design and implementation
• The implementation stage of
software development is the
process of developing an
executable system for delivery to
the customer.
Class 06
Software validation
• Software validation or, more generally, verification and
validation (V & V) is intended to show that a system both
conforms to its specification and meets the expectations of
the system customer.
• Figure shows a three-stage testing process in which
system components are individually tested, then the
integrated system is tested.
Software validation-Component testing
• Component testing The components making up the system are tested by the people developing the
system.
• Each component is tested independently, without other system components. Components may be
simple entities such as functions or object classes or may be coherent groupings of these entities.
• Test automation tools, such as JUnit for Java, that can rerun tests when new versions of the
component are created, are commonly used
Software validation-System testing
• System testing System components are integrated to create a complete system.
• For large systems, this may be a multistage process where components are integrated to form
subsystems that are individually tested before these subsystems are integrated to form the final
system
Beta Testing
• When a system is to be marketed as a software product, a testing process called beta testing is
often used.
• Beta testing involves delivering a system to a number of potential customers who agree to use that
system.
• They report problems to the system developers. This exposes the product to real use and detects
errors that may not have been anticipated by the product developers.
• After this feedback, the software product may be modified and released for further beta testing or
general sale.
 Beta Testing

Tech and Knowledge is a small software company that

ended the development stage of its very first product. This
software supports the automation of the most common
procedures executed by a typical elementary school. It is
highly friendly and reliable according to the opinion of the
Developing Department and also includes innovative
functionality for parents and children. The company needed urgent revenues but the Developing
Manager insisted that a Beta testing is crucial before a
client purchases the product. The manager selected two
small schools and installed the product for free. During
two months of testing, the company collected valuable
feedback and was able to correct some minor problems
before the product was formally launched in the open
market.
Software evolution
• This distinction between development and maintenance is increasingly irrelevant.
• Very few software systems are completely new systems, and it makes much more sense to see
development and maintenance as a continuum.
• Rather than two separate processes, it is more realistic to think of software engineering as an
evolutionary process where software is continually changed over its lifetime in response to
changing requirements and customer needs.
Approaches May Be Used To Reduce The Costs Of
Rework:
The system requirements change as businesses respond to external pressures.

Change Change
anticipation For example, a prototype system Tolerance Proposed changes may be
may be developed to show some implemented in increments that
key features of the system to have not yet been developed. If
customers. They can experiment this is impossible, then only a
with the prototype and refine their single increment (a small part of
requirements before committing the system) may have to be altered
to high software production cost. to incorporate the change.
Two Ways Of Coping With Change And Changing System
Requirements

System Incremental
prototyping delivery
Prototyping
• A prototype is an early version of a software system that is used to demonstrate concepts, try out design
options, and find out more about the problem and its possible solutions.
• A software prototype can be used in a software development process to help anticipate changes that may
be required:

In the system design

process, a prototype
can be used to explore
software solutions and
In the requirements in the development of
engineering process, a a user interface for the
prototype can help with system.
the elicitation and
validation of system
requirements.
Prototype
• System prototypes allow potential users to see how well the system supports their work.
• They may get new ideas for requirements and find areas of strength and weakness in the software.
Process Improvement
• There is a constant demand from industry for cheaper, better software, which has to be delivered
to ever-tighter deadlines.
• Consequently, many software companies have turned to software process improvement as a way
of enhancing the quality of their software, reducing costs, or accelerating their development
processes.
• Process improvement means understanding existing processes and changing these processes to
increase product quality and/or reduce costs and development time
Two quite different approaches to process improvement

The process • which has focused on improving process and project management and
introducing good software engineering practice into an organization.
maturity • The primary goals of this approach are improved product quality and
approach process predictability.

• Which has focused on iterative development and the reduction of overheads in

The agile the software process.
approach • The primary characteristics of agile methods are rapid delivery of functionality
and responsiveness to changing customer requirements.
 Process Improvement
You measure one or more attributes of the software process or
product.
Measure

The current process is assessed, and process weaknesses and

bottlenecks are identified
Analyze Change
Process changes are proposed to address
some of the identified process weaknesses
Capability Maturity Model
• The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an
increasing series of levels of a software development organization.
• CMM strategy for improving the software process to generate the Quality Software
• This idea was introduced so that the U.S. Department of Defense
• the term maturity relates to degree of formality and optimization of process.
Initial-Level
1. No engineering management - everything is done on ad hoc basis
2. Software process is unpredictable in term of cost and time
3. Staff/ employee matured reflect to the quality
Repeatable- Basic Project Management
1. Planning and managing of new projects based on experiences with similar
projects
2. No training for new staff
3. no written documentation
Defined - Process Standardize
1. Process of development should be documented
2. Training Programs are implemented to ensure that meet the market
requirement
3. Risk Management
Managed (Quantitative)
1. Rules should be implemented
2. Fire Safety should be done monthly
3. Organization should set quantitative goals for software process and product
4. Here Process is predictable with respect to cost and time
Optimized (Continuous Process Improvement)
1. try to improve the system
2. eg: bio metrix
3. Analysis the defects and it cause
 Identify and deploy new tools and
process improvements to meet needs

Capability Maturity Levels and business objectives

Manages the project’s processes

Optimizing
Capability Maturity Model is used
and sub-processes statistically
as a benchmark to measure the
maturity of an organization’s Quantitativel
software process. Makes sure that product meets y managed
the requirements and intended
use
Defined

Estimate project cost, schedule,

and functionality.
Managed

Where requirements for the system

are usually uncertain, misunderstood
and uncontrolled. Initial
Brain Teaser
ISACA stands for the Information Systems Audit and Control
Association.
Analysis
• Suggest the most appropriate generic software process model that might be used as a basis for
managing the development of the following systems. Explain your answer according to the type of
system being developed:
• a) A system to control anti-lock braking in a car
• b) A virtual reality system to support software maintenance
• c) A university accounting system that replaces an existing system
• d) An interactive travel planning system that helps users plan journey with the lowest environment
impact, system will evaluate over the user experience and add new feature to maintain the customer
relation
Analysis
• a) Anti-lock braking system This is a safety-critical system so requires a lot of up-front analysis
before implementation. It certainly needs a plan-driven approach to development with the
requirements carefully analysed. A waterfall model is therefore the most appropriate approach to
use, perhaps with formal transformations between the different development stages.

• b) Virtual reality system This is a system where the requirements will change and there will be
an extensive user interface components. Incremental development with, perhaps, some UI
prototyping is the most appropriate model. An agile process may be used.

•
Analysis
• c) University accounting system This is a system whose requirements are fairly well-known
and which will be used in an environment in conjunction with lots of other systems such as a
research grant management system. Therefore, a reuse-based approach is likely to be appropriate
for this.

• d) Interactive travel planning system with a complex user interface but which must be stable
and reliable. An incremental development approach is the most appropriate as the system
requirements will change as real user experience with the system is gained
Thankyou