Software Engineering CS403 Unit-I

Acropolis Institute of Technology &
Research, Indore
www.acropolis.in
Software Engineering
(CS 403)
Prof. Yamini Barge
21 February 2022 shivshankarrajput@acropolis.in 2

Course Objective:
❖Understand all SDLC Phases and software process models for given
project.
❖Differentiate functional and non-functional require and prepare SRS.
❖Design interfaces, database and functional design for given project.
❖Testing strategies in various software development life cycle phases.
❖Manage the complete software project from inception to completion.

Course Outcome:
❖Implement all SDLC Phases and software process models for given
project.
❖Design SRS by using functional and non-functional requirement

fundamentals.
❖Design software product/application.
❖software development using different testing methodologies.
❖ Maintenance and cost of software.

Chapter 1
CS435: Introduction to Software Engineering
❖Software & Software Engineering
Dr. M. Zhu
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
Software Engineering 9/e

By Ian Sommerville

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.

Wear vs. Deterioration

Wear vs. Deterioration

Software Applications
1. System software such as compilers, editors, file management utilities
2. Application software stand-alone programs for specific needs.
3. Engineering/scientific software Characterized by “number crunching”algorithms. such as
automotive stress analysis, molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system. (key pad control of a microwave
oven, digital function of dashboard display in a car)
5. Product-line software focus on a limited marketplace to address mass consumer market.
(word processing, graphics, database management)
6. WebApps(Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database and
business applications.
7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert
system, pattern recognition game playing

Software—New Categories
❖Open world computing : pervasive, ubiquitous, distributed computing due to
wireless networking. How to allow mobile devices, personal computer, enterprise
system to communicate across vast network.
❖Netsourcing :the Web as a computing engine. How to architect simple and
sophisticated applications to target end-users worldwide.
❖Open source : ”free” source code open to the computing community.
❖Also other categories like
⮚Data mining
⮚Grid computing
⮚Cognitive machines
⮚Software for nanotechnologies

Software Engineering Definition
The seminal definition:
[Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently on real machines.
The IEEE definition:
Software Engineering: (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study
of approaches as in (1).

Importance of Software Engineering
❖More and more, individuals and society rely on advanced software
systems. We need to be able to produce reliable and trustworthy
systems economically and quickly.
❖It is usually cheaper, in the long run, to use software engineering

methods and techniques for software systems rather than just write the
programs as if it was a personal programming project. For most types
of system, the majority of costs are the costs of changing the software
after it has gone into use.

FAQ about software engineering
Question Answer
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 subset of overall
Five Activities of a Generic Process
software features and functionality.
framework
Umbrella Activities
Complement the five process framework activities and help team manage and control progress, quality,
change, and risk.
❖ Software project tracking and control: assess progress against the plan and take actions to maintain
the schedule.
❖ Risk management: assesses risks that may affect the outcome and quality.
❖ Software quality assurance: defines and conduct activities to ensure quality.
❖ Technical reviews: assesses work products to uncover and remove errors before going to the next
activity.
❖ Measurement: define and collects process, project, and product measures to ensure stakeholder’s
needs are met.
❖ Software configuration management: manage the effects of change throughout the software process.
❖ Reusability management: defines criteria for work product reuse and establishes mechanism to
achieve reusable components.
❖ Work product preparation and production: create work products such as models, documents, logs,
forms and lists.

Adapting a Process Model
The process should be agile and adaptable to problems. Process adopted for one project might be
significantly different than a process adopted from another project. (to the problem, the project, the
team, organizational culture). Among the differences are:
⮚the overall flow of activities, actions, and tasks and the interdependencies among them
⮚the degree to which actions and tasks are defined within each framework activity
⮚the degree to which work products are identified and required
⮚the manner which quality assurance activities are applied
⮚the manner in which project tracking and control activities are applied
⮚the overall degree of detail and rigor with which the process is described
⮚the degree to which the customer and other stakeholders are involved with the project
⮚the level of autonomy given to the software team
⮚the degree to which team organization and roles are prescribed

Prescriptive and Agile Process Models
⮚The prescriptive process models stress detailed definition, identification,
and application of process activates and tasks. Intent is to improve
system quality, make projects more manageable, make delivery dates
and costs more predictable, and guide teams of software engineers as
they perform the work required to build a system.
⮚Unfortunately, there have been times when these objectives were not
achieved. If prescriptive models are applied dogmatically and without
adaptation, they can increase the level of bureaucracy.
⮚Agile process models emphasize project “agility” and follow a set of

principles that lead to a more informal approach to software process. It
The Essence of Practice
❖How does the practice of software engineering fit in the
process activities mentioned above? Namely, communication,
planning, modeling, construction and deployment.
❖George Polya outlines the essence of problem solving,
suggests:
1.Understand the problem (communication and analysis).
2.Plan a solution (modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality assurance).

Understand the Problem
❖Who has a stake in the solution to the problem? That is, who are
the stakeholders?
❖What are the unknowns? What data, functions, and features
are required to properly solve the problem?
❖Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to
understand?
❖Can the problem be represented graphically? Can an analysis
model be created?
21 February 2022 shivshankarrajput@acropolis.in

Plan the Solution
❖Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, and features that are required?
❖Has a similar problem been solved? If so, are elements of the solution
reusable?
❖Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
❖Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

Carry Out the Plan
❖Does the solutions conform to the plan? Is source code
traceable to the design model?
❖Is each component part of the solution provably correct?
Has the design and code been reviewed, or better,
have correctness proofs been applied to algorithm?

Examine the Result
❖Is it possible to test each component part of the solution?
Has a reasonable testing strategy been implemented?
❖Does the solution produce results that conform to the
data, functions, and features that are required? Has the
software been validated against all stakeholder
requirements?

Help you establish mind-set for solid software engineering
practice (David Hooker 96).
❖1: The Reason It All Exists: provide values to users

❖2: KISS (Keep It Simple, Stupid! As simple as possible)
❖3: Maintain the Vision (otherwise, incompatible design)
❖4: What You Produce, Others Will Consume (code with concern for those that must maintain and extend
the system)
❖5: Be Open to the Future (never design yourself into a corner as specification and hardware changes)
❖6: Plan Ahead for Reuse
❖7: Think! Place clear complete thought before action produces better results.
Hooker’s General Principles for Software Engineering Practice:

important underlying law
Software Myths
Erroneous beliefs about software and the process that is used to
build it.
❖Affect managers, customers (and other non-technical
stakeholders) and practitioners
❖Are believable because they often have elements of truth, but …
❖Invariably lead to bad decisions,
therefore …
❖Insist on reality as you navigate your way through software
engineering

Software Myths Examples
❖ Myth 1: Once we write the program and get it to work, our job is done.
❖ Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to 80% of all efforts are
spent after software is delivered to the customer for the first time.
❖ Myth 2: Until I get the program running, I have no way of assessing its quality.
❖ Reality: technical review are a quality filter that can be used to find certain classes of software defects from the
inception of a project.
❖ Myth 3: software engineering will make us create voluminous and unnecessary documentation and will invariably
slow us down.
❖ Reality: it is not about creating documents. It is about creating a quality product. Better quality leads to a reduced
rework. Reduced work results in faster delivery times.
❖Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods foster poor
management and technical practices, even when reality dictates a better approach .
How It all Starts
❖SafeHome:
⮚Every software project is precipitated by some business
need—
▪ the need to correct a defect in an existing application;
▪ the need to the need to adapt a ‘legacy system’ to a changing business environment;
▪ the need to extend the functions and features of an existing application, or
▪ the need to create a new product, service, or system.

Case studies
❖A personal insulin pump
⮚An embedded system in an insulin pump used by diabetics to
maintain blood glucose control.
❖A mental health case patient management system
⮚A system used to maintain records of people receiving care for mental
health problems.
❖A wilderness weather station
⮚A data collection system that collects data about weather conditions
in remote areas.

Insulin pump control system
❖Collects data from a blood sugar sensor and calculates the
amount of insulin required to be injected.
❖Calculation based on the rate of change of blood sugar levels.
❖Sends signals to a micro-pump to deliver the correct dose of
insulin.
❖Safety-critical system as low blood sugars can lead to brain
malfunctioning, coma and death; high-blood sugar levels have
long-term consequences such as eye and kidney damage.

Insulin pump hardware architecture

Activity model of the insulin pump

Essential high-level requirements
❖The system shall be available to deliver insulin when required.
❖The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of blood sugar.
❖The system must therefore be designed and implemented to
ensure that the system always meets these requirements.

A patient information system for mental health care
❖A patient information system to support mental health care is a
medical information system that maintains information about
patients suffering from mental health problems and the treatments
that they have received.
❖Most mental health patients do not require dedicated hospital
treatment but need to attend specialist clinics regularly where they
can meet a doctor who has detailed knowledge of their problems.
❖To make it easier for patients to attend, these clinics are not just
run in hospitals. They may also be held in local medical practices or
community centres.

MHC-PMS
❖The MHC-PMS (Mental Health Care-Patient Management
System) is an information system that is intended for use in
clinics.
❖It makes use of a centralized database of patient information but
has also been designed to run on a PC, so that it may be accessed
and used from sites that do not have secure network connectivity.
❖When the local systems have secure network access, they use
patient information in the database but they can download and
use local copies of patient records when they are disconnected.

MHC-PMS goals
❖To generate management information that allows health
service managers to assess performance against local and
government targets.
❖To provide medical staff with timely information to support the
treatment of patients.

The organization of the MHC-PMS

MHC-PMS key features
❖Individual care management
⮚ Clinicians can create records for patients, edit the information in the system, view
patient history, etc. The system supports data summaries so that doctors can quickly
learn about the key problems and treatments that have been prescribed.
❖Patient monitoring
⮚ The system monitors the records of patients that are involved in treatment and issues
warnings if possible problems are detected.
❖Administrative reporting
⮚ The system generates monthly management reports showing the number of patients
treated at each clinic, the number of patients who have entered and left the care
system, number of patients sectioned, the drugs prescribed and their costs, etc.

MHC-PMS concerns
❖Privacy
⮚ It is essential that patient information is confidential and is never disclosed
to anyone apart from authorised medical staff and the patient themselves.
❖Safety
⮚ Some mental illnesses cause patients to become suicidal or a danger to
other people. Wherever possible, the system should warn medical staff
about potentially suicidal or dangerous patients.
⮚ The system must be available when needed otherwise safety may be
compromised and it may be impossible to prescribe the correct
medication to patients.

Wilderness weather station
❖The government of a country with large areas of wilderness decides to
deploy several hundred weather stations in remote areas.
❖Weather stations collect data from a set of instruments that measure
temperature and pressure, sunshine, rainfall, wind speed and wind
direction.
⮚ The weather station includes a number of instruments that measure weather
parameters such as the wind speed and direction, the ground and air
temperatures, the barometric pressure and the rainfall over a 24-hour period.
Each of these instruments is controlled by a software system that takes parameter
readings periodically and manages the data collected from the instruments.
❖

The weather station’s environment

Weather information system
❖ The weather station system
⮚ This is responsible for collecting weather data, carrying out some initial
data processing and transmitting it to the data management system.
❖The data management and archiving system
⮚ This system collects the data from all of the wilderness weather stations,
carries out data processing and analysis and archives the data.
❖The station maintenance system
⮚ This system can communicate by satellite with all wilderness weather
stations to monitor the health of these systems and provide reports of
problems.

Additional software functionality
❖Monitor the instruments, power and communication hardware
and report faults to the management system.
❖Manage the system power, ensuring that batteries are charged
whenever the environmental conditions permit but also that
generators are shut down in potentially damaging weather
conditions, such as high wind.
❖Support dynamic reconfiguration where parts of the software
are replaced with new versions and where backup instruments
are switched into the system in the event of system failure.

Chapter 2 :
■Process Models
Dr. M. Zhu
Software Engineering 9/e

By Ian Sommerville

Social Learning Process
❖Software is embodied knowledge that is initially dispersed, tacit and
incomplete.
❖In order to convert knowledge into software, dialogues are needed between
users and designers, between designers and tools to bring knowledge into
software.
❖Software development is essentially an iterative social learning process, and

the outcome is “software capital”.

What / who / why is Process Models?
■ What: Go through a series of predictable steps--- a road map that helps you create a timely, high-quality
results.
■ Who: Software engineers and their managers, clients also. People adapt the process to their needs and
follow it.
■ Why: Provides stability, control, and organization to an activity that can if left uncontrolled, become quite
chaotic. However, modern software engineering approaches must be agile and demand ONLY those
activities, controls and work products that are appropriate.
■ What Work products: Programs, documents, and data
■ What are the steps: The process you adopt depends on the software that you are building. One process
might be good for aircraft avionic system, while an entirely different process would be used for website
creation.
■ How to ensure right: A number of software process assessment mechanisms that enable us to determine
the maturity of the software process. However, the quality, timeliness and long-term viability of the
software are the best indicators of the efficacy of the process you use.

Definition of Software Process
❖A framework for the activities, actions, and tasks that are

required to build high-quality software.
❖SP defines the approach that is taken as software is engineered.
❖Is not equal to software engineering, which also encompasses

technologies that populate the process– technical methods and
automated tools.

A Generic Process Model

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

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]
64

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?
65

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. 68

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.
72
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.
73
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.
74
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.
75
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.
76
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.
77
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.
78
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.
79
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).
80
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.
81
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.
82
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
83
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
84
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.
85
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.
86
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
94

4.The Incremental or Successive Versions Model
95

❖ 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.
96

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. 97

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.
98

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.
99

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.
100

5. Evolutionary Models: Prototyping
Quick
plan
communication
Modeling
Quick design
Deployment Construction
delivery & of prototype
feedback Construction
of prototype
101

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. 102
❖ 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. 106

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
108

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. 109

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

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.
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
115

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)

Chapter - 3
Dr. M. Zhu
■Agile Development
Slide Set to accompany
shivshankarrajput@acropolis.in 119
21 February 2022
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.
shivshankarrajput@acropolis.in
21 February 2022 123
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
125
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.
128
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)
129
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.

❖ 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
131
132
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.
133
Scrum
❖shivshankarrajput@acropolis.in
134
21 February 2022
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
135
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)


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.

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.

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

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

Software Engineering CS403 Unit-I

Uploaded by

Copyright:

Available Formats

Software Engineering CS403 Unit-I

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering CS403 Unit-I

Uploaded by

Copyright:

Available Formats

Acropolis Institute of Technology &

Prof. Yamini Barge

21 February 2022 shivshankarrajput@acropolis.in 2

❖Differentiate functional and non-functional require and prepare SRS.

❖Design interfaces, database and functional design for given project.

❖Testing strategies in various software development life cycle phases.

❖Manage the complete software project from inception to completion.

❖Design SRS by using functional and non-functional requirement

❖Design software product/application.

❖software development using different testing methodologies.

❖ Maintenance and cost of software.

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

Software Engineering 9/e

21 February 2022 shivshankarrajput@acropolis.in 5

21 February 2022 shivshankarrajput@acropolis.in 6

21 February 2022 shivshankarrajput@acropolis.in 8

❖Software costs more to maintain than it does to develop. For

❖Software engineering is concerned with cost-effective software

21 February 2022 shivshankarrajput@acropolis.in 10

21 February 2022 shivshankarrajput@acropolis.in 11

21 February 2022 shivshankarrajput@acropolis.in 12

21 February 2022 shivshankarrajput@acropolis.in 13

21 February 2022 shivshankarrajput@acropolis.in 14

21 February 2022 shivshankarrajput@acropolis.in 15

❖It is usually cheaper, in the long run, to use software engineering

21 February 2022 shivshankarrajput@acropolis.in 16

Computer programs, data structures and associated documentation.

Good software should deliver the required functionality and performance to

Software engineering is an engineering discipline that is concerned with all

Computer science focuses on theory and fundamentals; software

System engineering is concerned with all aspects of computer-based

21 February 2022 shivshankarrajput@acropolis.in 17

Software dependability includes a range of characteristics including reliability, security

21 February 2022 shivshankarrajput@acropolis.in 18

21 February 2022 shivshankarrajput@acropolis.in 19

21 February 2022 shivshankarrajput@acropolis.in 20

21 February 2022 shivshankarrajput@acropolis.in 22

21 February 2022 shivshankarrajput@acropolis.in 23

⮚Agile process models emphasize project “agility” and follow a set of

21 February 2022 shivshankarrajput@acropolis.in 25

21 February 2022 shivshankarrajput@acropolis.in

21 February 2022 shivshankarrajput@acropolis.in 27

21 February 2022 shivshankarrajput@acropolis.in 28

21 February 2022 shivshankarrajput@acropolis.in 29

❖1: The Reason It All Exists: provide values to users

Hooker’s General Principles for Software Engineering Practice:

21 February 2022 shivshankarrajput@acropolis.in 33

21 February 2022 shivshankarrajput@acropolis.in 33

21 February 2022 shivshankarrajput@acropolis.in 34

21 February 2022 shivshankarrajput@acropolis.in 35

21 February 2022 shivshankarrajput@acropolis.in 36

21 February 2022 shivshankarrajput@acropolis.in 37

21 February 2022 shivshankarrajput@acropolis.in 38

21 February 2022 shivshankarrajput@acropolis.in 39

21 February 2022 shivshankarrajput@acropolis.in 40

21 February 2022 shivshankarrajput@acropolis.in 41

21 February 2022 shivshankarrajput@acropolis.in 42

21 February 2022 shivshankarrajput@acropolis.in 43

21 February 2022 shivshankarrajput@acropolis.in 44