Software Engineering

Prof. Lakshita Mandpe

 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. Hardware has bathtub curve
of failure rate.
❖ 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.
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 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

Computer programs, data structures and associated documentation.

What is software? Software products may be developed for a particular customer or may be
developed for a general market.

Good software should deliver the required functionality and performance to

What are the attributes of good software?
the user and should be maintainable, dependable and usable.

Software engineering is an engineering discipline that is concerned with all

What is software engineering?
aspects of software production.

Computer science focuses on theory and fundamentals; software

What is the difference between software engineering
engineering is concerned with the practicalities of developing and delivering
and computer science?
useful software.

System engineering is concerned with all aspects of computer-based

What is the difference between software engineering
systems development including hardware, software and process
and system engineering?
engineering. Software engineering is part of this more general process.
Essential attributes of good software
Product characteristic Description

Software should be written in such a way so that it can evolve to meet the changing
Maintainability needs of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.

Software dependability includes a range of characteristics including reliability, security

and safety. Dependable software should not cause physical or economic damage in the
Dependability and security
event of system failure. Malicious users should not be able to access or damage the
system.

Software should not make wasteful use of system resources such as memory and
Efficiency processor cycles. Efficiency therefore includes responsiveness, processing time,
memory utilisation, etc.

Software must be acceptable to the type of users for which it is designed. This means
Acceptability
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 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.
Software Process
❖ 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
Five Activities of a Generic Process
subset of overall software features and functionality.

framework
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
■ 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.

A Generic Process Model

Process Flow
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.
■ 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.

Example of a Task Set for Elicitation

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,
EstablishingCommunication would incorporate the task pattern
RequirementsGathering 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 SprialModel 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 of
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?
Software Development Life Cycle
SDLC( Software Development Life Cycle)/Process Model-
1.Prescriptive model-
Waterfall Model, Prototyping Model, RAD Model

2.Evolutionary model- Spiral Model, Incremental Model

3.Agile Process Model- Extreme Programming, Adaptive Software

Developmen
1. The Waterfall Model
❖ The Waterfall Model was the first Process Model to be introduced.
❖ It is also referred to as a linear-sequential life cycle model.
❖ It is also referred to as a Classical waterfall model.
❖ Waterfall model is very simple to understand and use.
❖ In a waterfall model, each phase must be completed before the next phase can
begin and there is no overlapping in the phases.
❖ Classical waterfall model divides the life cycle into a set of phases. This model
considers that one phase can be started after completion of the previous phase.
 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 Waterfall Model
The Waterfall Model Cont……
❖ Most organizations usually define:
standards on the outputs (deliverables) produced at the end of every phase
entry and exit criteria for every phase.
❖ They also prescribe specific methodologies for:
specification,
design,
testing,
project management, etc.
The Waterfall Model Cont……
1. Feasibility Study:
• The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software.
• The feasibility study involves understanding the problem and then determine the various
possible strategies to solve the problem.

❖ First roughly understand what the customer wants:

different data which would be input to the system,
processing needed on these data,
output data to be produced by the system,
various constraints on the behavior of the system.
Activities during Feasibility Study
❖Work out an overall understanding of the problem.
❖Formulate different solution strategies.
❖Examine alternate solution strategies in terms of:
▪ resources required,
▪ cost of development, and
▪ development time.
Activities during Feasibility Study
❖Perform a cost/benefit analysis:
to determine which solution is the best.
you may determine that none of the solutions is feasible
due to:
▪ high cost,
▪ resource constraints,
▪ technical reasons.
Requirements Analysis and Specification
❖ Aim of this phase:
understand the exact requirements of the customer,
document them properly.
❖ Consists of two distinct activities:
requirements gathering and analysis
requirements specification.
Goals of Requirements Analysis
❖ Collect all related data from the customer:
analyze the collected data to clearly understand what the
customer wants,
find out any inconsistencies and incompleteness in the
requirements,
resolve all inconsistencies and incompleteness.
Requirements Gathering
❖Gathering relevant data:
usually collected from the end-users through interviews
and discussions.
For example, for a business accounting software:
▪ interview all the accountants of the organization to find out
their requirements.
Requirements Analysis Cont....
❖ The data you initially collect from the users:
would usually contain several contradictions and ambiguities:
each user typically has only a partial and incomplete view of the system.
❖ Ambiguities and contradictions:
must be identified
resolved by discussions with the customers.
❖ Next, requirements are organized:
into a Software Requirements Specification (SRS) document.
❖ Engineers doing requirements analysis and specification:
are designated as analysts.
Design
❖ Design phase transforms requirements specification:
into a form suitable for implementation in some programming
language.
❖ In technical terms:
during design phase, software architecture is derived from the
SRS document.
❖ Two design approaches:
traditional approach,
object oriented approach.
Traditional Design Approach
❖Consists of two activities:
1. Structured analysis 2.Structured design
Structured analysis
1.Identify all the functions to be performed.
2.Identify data flow among the functions.
3.Decompose each function recursively into sub-functions.
4.Identify data flow among the subfunctions as well.
Structured Analysis (CONT.)
❖ Carried out using Data flow diagrams (DFDs).
❖ After structured analysis, carry out structured design:
architectural design (or high-level design)
detailed design (or low-level design).
Structured Design
❖High-level design:
decompose the system into modules,
represent invocation relationships among the modules.
❖Detailed design:
different modules designed in greater detail:
▪ data structures and algorithms for each module are designed.
Object Oriented Design
❖First identify various objects (real world entities)
occurring in the problem:
identify the relationships among the objects.
For example, the objects in a pay-roll software may be:
▪ employees,
▪ managers,
▪ pay-roll register,
▪ Departments, etc.
Implementation
❖ During the implementation phase:
each module of the design is coded,
each module is unit tested
▪ tested independently as a stand alone unit, and debugged,
each module is documented.
❖ The purpose of unit testing:
test if individual modules work correctly.
❖ The end product of implementation phase:
a set of program modules that have been tested individually
Integration and System Testing
❖ Different modules are integrated in a planned manner:
modules are almost never integrated in one shot.
Normally integration is carried out through a number of steps.
❖ During each integration step,
the partially integrated system is tested.

M1 M2

M3 M4
System Testing

❖After all the modules have been successfully

integrated and tested:
system testing is carried out.
❖Goal of system testing:
ensure that the developed system functions according to its
requirements as specified in the SRS document.
Maintenance
❖ Maintenance of any software product:
requires much more effort than the effort to develop the product itself.
development effort to maintenance effort is typically 40:60.
❖ Corrective maintenance:
Correct errors which were not discovered during the product
development phases.
❖ Perfective maintenance:
Improve implementation of the system
enhance functionalities of the system.
❖ Adaptive maintenance:
Port software to a new environment,
▪ e.g. to a new computer or to a new operating system.
Advantages of Waterfall Model
❖ This model is very simple and is easy to understand.
❖ Phases in this model are processed one at a time.
❖ Each stage in the model is clearly defined.
❖ This model has very clear and well undestood milestones.
❖ Process, actions and results are very well documented.
❖ Reinforces good habits: define-before- design,
design-before-code.
❖ This model works well for smaller projects and projects where requirements are
well understood.
Drawbacks of Classical Waterfall Model
❖ No feedback path: In this model evolution of a software from one phase to
another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phases. Therefore, it does not incorporate any
mechanism for error correction.
❖ Difficult to accommodate change requests: This model assumes that all the
customer requirements can be completely and correctly defined at the beginning
of the project, but actually customers’ requirements keep on changing with
time. It is difficult to accommodate any change requests after the requirements
specification phase is complete.
❖ No overlapping of phases: This model recommends that new phase can start
only after the completion of the previous phase. But in real projects, this can’t
be maintained. To increase the efficiency and reduce the cost, phases may
overlap.
2. Iterative Waterfall Model
2. Iterative Waterfall Model
❖ The iterative waterfall model provides feedback paths from every phase to its
preceding phases, which is the main difference from the classical waterfall
model.
❖ Advantages : 1. Feedback Path 2. Simple Model
❖ Drawbacks:
1.Difficult to incorporate change requests:
2.Incremental delivery not supported:
3.Overlapping of phases not supported:
4. Risk handling not supported:
5. Limited customer interactions:
3.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.
3.The V-Model
Why preferred?
It is easy to manage due to the rigidity of the model. Each phase of V-Model
has specific deliverables and a review process.
Proactive defect tracking – that is defects are found at early stage.
When to use?
Where requirements are clearly defined and fixed.
The V-Model is used when sample technical resources are available with
technical expertise.
3. The V-Model
Advantages:
❖ This is a highly disciplined model and Phases are completed one at a time.
❖ V-Model is used for small projects where project requirements are clear.
❖ Simple and easy to understand and use.
❖ This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.
❖ It enables project management to track progress accurately.
Disadvantages:
❖ High risk and uncertainty.
❖ It is not a good for complex and object-oriented projects.
❖ It is not suitable for projects where requirements are not clear & contains high risk of
changing.
❖ This model does not support iteration of phases.
❖ It does not easily handle concurrent events.
4.The Incremental Model
4.The Incremental or Successive Versions Model
4.The Incremental or Successive Versions Model
❖ Requirements of Software are first broken down into several modules that can be
incrementally constructed and delivered. At any time, the plan is made just for the next
increment and not for any kind of long term plans. Therefore, it is easier to modify the
version as per the need of the customer. Development Team first undertakes to develop core
features of the system.
❖ Once the core features are fully developed, then these are refined to increase levels of
capabilities by adding new functions in Successive versions. Each incremental version is
usually developed using an iterative waterfall model of development.
❖ As each successive version of the software is constructed and delivered, now the feedback of
the Customer is to be taken and these were then incorporated in the next version. Each
version of the software have more additional features over the previous ones.
4.The Incremental or Successive Versions Model
When to use this –
❖ Funding Schedule, need for early realization of benefits.
❖ When Requirements are known up-front.
❖ Projects with new Technology.
Advantages –
❖ Error Reduction (core modules are used by the customer from the beginning of the phase and
then these are tested thoroughly)
❖ Uses divide and conquer for breakdown of tasks.
❖ Incremental Resource Deployment.
Disadvantages –
❖ Requires good planning and design.
❖ Well defined module interfaces are required.
4. 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.
5. 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.
5. Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype
 6. Evolutionary Models: The Spiral Model
❖ 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.
The Spiral Model
The Spiral Model
When to use Spiral Model:
1.When there is a budget constraint and risk evaluation is important.
2.For medium to high-risk projects.
3.Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
4.Customer is not sure of their requirements which is usually the case.
5.Requirements are complex and need evaluation to get clarity.
6.New product line which should be released in phases to get enough customer feedback.
7.Significant changes are expected in the product during the development cycle.
The Spiral Model
Advantages:
1. High amount of risk analysis hence, avoidance of risk is enhanced.
2. Good for large projects
3.Strong approval and documentation control
4.High Customer Satisfaction: Customer can see the development of the product at the early phase of
the software development and thus, they habituated with the system by using it before completion of the
total product.

Disadvantages :
1.Complex: The Spiral Model is much more complex than other SDLC models.
2.Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Risk Analysis: The successful completion of the project is very much dependent on Risk Analysis.
Without very highly experienced experts, it is going to be a failure to develop a project using this model.
 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.
 7. Rational Unified Process (RUP)
❖ RUP is a software development process for object-oriented models. It is
also known as the Unified Process Model. It is created by Rational
corporation and is designed and documented using UML (Unified
Modeling Language).
❖ This process is included in IBM Rational Method Composer (RMC)
product. IBM (International Business Machine Corporation) allows us to
customize, design, and personalize the unified process.
❖ RUP is proposed by Ivar Jacobson, Grady Bootch, and James Rambaugh.
Some characteristics of RUP include use-case driven, Iterative (repetition
of the process), and Incremental (increase in value) by nature, delivered
online using web technology, can be customized or tailored in modular and
electronic form, etc. RUP reduces unexpected development costs and
prevents wastage of resources.
The Unified Process (UP)

elaboration

inception
 The Unified Process (UP)
1. Inception –
Communication and planning are main.
Identifies Scope of the project using use-case model allowing managers to estimate costs and time
required.
Customers requirements are identified and then it becomes easy to make a plan of the project.
Project plan, Project goal, risks, use-case model, Project description, are made.
Project is checked against the milestone criteria and if it couldn’t pass these criteria then project
can be either cancelled or redesigned.
2. Elaboration –
Planning and modeling are main.
Detailed evaluation, development plan is carried out and diminish the risks.
Revise or redefine use-case model (approx. 80%), business case, risks.
Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can
be cancelled or redesigned.
Executable architecture baseline.
 The Unified Process (UP)
3.Construction –
Project is developed and completed.
System or source code is created and then testing is done.
Coding takes place.
4.Transition –
Final project is released to public.
Transit the project from development into production.
Update project documentation.
Beta testing is conducted.
Defects are removed from project based on feedback from public.
5.Production –
Final phase of the model.
Project is maintained and updated accordingly.
UP Phases
UP Work Products
8. Component Assembly Model
 9.Rapid application development model (RAD)
❖ The Rapid Application Development Model was first proposed by IBM in
1980’s. The critical feature of this model is the use of powerful development
tools and techniques.
❖ A software project can be implemented using this model if the project can be
broken down into small modules wherein each module can be assigned
independently to separate teams. These modules can finally be combined to
form the final product.
❖ Development of each module involves the various basic steps as in waterfall
model i.e. analyzing, designing, coding and then testing, etc.
❖ Another striking feature of this model is a short time span i.e. the time frame
for delivery(time-box) is generally 60-90 days.
9.Rapid application development model (RAD)
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.
 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.
7.Working software is the primary measure of progress.
Agility Principles - II

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)
 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
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
Software Process Customization and Improvement
Capability Maturity Model
❖ The Capability Maturity Model (CMM) is a procedure used to develop and
refine an organization's software development process.
❖ The model defines a five-level evolutionary stage of increasingly organized and
consistently more mature processes.
❖ CMM was developed and is promoted by the Software Engineering Institute
(SEI), a research and development center promote by the U.S. Department of
Defense (DOD).
❖ It is also know as Software Engineering Institute Capability Maturity Model
(SEICMM)
Capability Maturity Model
Capability Maturity Model
Level-1:Initial –
❖ No KPA’s defined.
❖ Processes followed are adhoc and immature and are not well defined.
❖ Unstable environment for software dvelopment.
❖ No basis for predicting product quality, time for completion, etc.

Level-2: Repeatable –
❖ Focuses on establishing basic project management policies.
❖ Experience with earlier projects is used for managing new similar natured projects.
❖ Project Planning- It includes defining resources required, goals, constraints, etc. for the
project. It presents a detailed plan to be followed systematically for successful completion of
a good quality software.
Capability Maturity Model
Level-2: Repeatable –
❖ Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
❖ Requirements Management- It includes the management of customer reviews and feedback
which result in some changes in the requirement set. It also consists of accommodation of
those modified requirements.
❖ Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
❖ Software Quality Assurance- It guarantees a good quality software product by following
certain rules and quality standard guidelines while development.
Capability Maturity Model
Level-3:Defined –
❖ At this level, documentation of the standard guidelines and procedures takes place.
❖ It is a well defined integrated set of project specific software engineering and management
processes.
❖ Peer Reviews- In this method, defects are removed by using a number of review methods like
walkthroughs, inspections, buddy checks, etc.
❖ Intergroup Coordination- It consists of planned interactions between different development teams
to ensure efficient and proper fulfillment of customer needs.
❖ Organization Process Definition- It’s key focus is on the development and maintenance of the
standard development processes.
❖ Organization Process Focus- It includes activities and practices that should be followed to
improve the process capabilities of an organization.
❖ Training Programs- It focuses on the enhancement of knowledge and skills of the team members
including the developers and ensuring an increase in work efficiency.
Capability Maturity Model
Level-4: Managed –

❖ At this stage, quantitative quality goals are set for the organization for software products as
well as software processes.
❖ The measurements made help the organization to predict the product and process quality
within some limits defined quantitatively.
❖ Software Quality Management- It includes the establishment of plans and strategies to
develop a quantitative analysis and understanding of the product’s quality.
❖ Quantitative Management- It focuses on controlling the project performance in a quantitative
manner.
Capability Maturity Model
Level-5: Optimizing –

❖ This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
❖ Use of new tools, techniques and evaluation of software processes is done to prevent
recurrence of known defects.
❖ Process Change Management- Its focus is on the continuous improvement of organization’s
software processes to improve productivity, quality and cycle time for the software product.
❖ Technology Change Management- It consists of identification and use of new technologies to
improve product quality and decrease the product development time.
❖ Defect Prevention- It focuses on identification of causes of defects and to prevent them from
recurring in future projects by improving project defined process.
Q&A
THANKS