Software Engineering – Module 1

Module – 1

SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering:

Software:
Definition:
Software is a set of instructions, data, or programs that tell a computer how
to perform specific tasks. It encompasses various applications, scripts, and
programs that run on a computer or device.
Examples: Operating systems (like Windows or macOS), applications (like web
browsers or word processors), games, and mobile apps.
Engineering:
Definition:
The creative application of scientific and mathematical principles to design,
build, and improve systems, processes, and products for practical use.

Software Engineering:
Software engineering is the systematic and disciplined approach to
designing, developing, testing, and maintaining software. It applies engineering
principles and practices to create high-quality software products.
Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system specification through
to maintaining the system after it has gone into use.
In this definition, there are two key phrases:
1. Engineering discipline: Engineers make things work. They apply theories,
methods, and tools where these are appropriate. However, they use them
selectively and always try to discover solutions to problems even when there are no
applicable theories and methods
2. All aspects of software production: Software engineering is not just concerned
with the technical processes of software development. It also includes activities
such as software project management and the development of tools, methods, and
theories to support software production.

Page | 1
Software Engineering – Module 1
There are two kinds of software products:
1. Generic products
2. Customized products
1. Generic products:
These are stand-alone systems that are produced by a development
organization and sold on the open market to any customer who is able to buy
them.
Examples of this type of product include software for PCs such as
databases, word processors, drawing packages, and project-management
tools.
2. Customized (or bespoke) products:
These are systems that are commissioned by a particular customer. A
software contractor develops the software especially for that customer.
Examples of this type of software include control systems for electronic
devices, systems written to support a particular business process, and air
traffic control systems.
An important difference between these types of software is that, in generic products,
the organization that develops the software controls the software specification. For
custom products, the specification is usually developed and controlled by the
organization that is buying the software. The software developers must work to that
specification.

Essential attributes of good software: -

• Maintainability: Software should be written in such a way so that it can
evolve to meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a changing business
environment.
• Dependability and security: Software dependability includes a range of
characteristics including reliability, security, and safety. Dependable software
should not cause physical or economic damage in the event of system failure.
Malicious users should not be able to access or damage the system.
• Efficiency: Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilization, etc.
• Acceptability: Software must be acceptable to the type of users for which it
is designed. This means that it must be understandable, usable, and
compatible with other systems that they use.

Page | 2
Software Engineering – Module 1
Software engineering diversity:
Software engineering is a systematic approach to the production of software
that takes into account practical cost, schedule, and dependability issues, as well
as the needs of software customers and producers.
How this systematic approach is actually implemented varies dramatically
depending on the organization developing the software, the type of software, and
the people involved in the development process. There are no universal software
engineering methods and techniques that are suit-able for all systems and all
companies.
There are many different types of application including:
1. Stand-alone applications: These are application systems that run on a local
computer, such as a PC. They include all necessary functionality and do not
need to be connected to a network. Examples of such applications are office
applications on a PC, CAD programs, photo manipulation software, etc.
2. Interactive transaction-based applications: These are applications that
execute on a remote computer and that are accessed by users from their own
PCs or terminals. Obviously, these include web applications such as e-
commerce applications where you can interact with a remote system to buy
goods and services. This class of application also includes business systems,
where a business provides access to its systems through a web browser or
special-purpose client program and cloud-based services, such as mail and
photo sharing. Interactive applications often incorporate a large data store
that is accessed and updated in each transaction.
3. Embedded control systems: These are software control systems that
control and manage hardware devices. Numerically, there are probably more
embedded systems than any other type of system. Examples of embedded
systems include the software in a mobile (cell) phone, software that controls
anti-lock braking in a car, and software in a microwave oven to control the
cooking process.
4. Batch processing systems: These are business systems that are designed
to process data in large batches. They process large numbers of individual
inputs to create corresponding outputs. Examples of batch
systems include periodic billing systems, such as phone billing systems, and
salary payment systems.
5. Entertainment systems: These are systems that are primarily for personal
use and which are intended to entertain the user. Most of these systems are
games of one kind or another. The quality of the user interaction offered is the
most important distinguishing characteristic of entertainment systems.

Page | 3
Software Engineering – Module 1
6. Systems for modeling and simulation: These are systems that are
developed by scientists and engineers to model physical processes or
situations, which include many, separate, interacting objects. These are often
computationally intensive and require high-performance parallel systems for
execution.
7. Data collection systems: These are systems that collect data from their
environment using a set of sensors and send that data to other systems for
processing. The software has to interact with sensors and often is installed in
a hostile environment such as inside an engine or in a remote location.
8. Systems of systems: These are systems that are composed of a number of
other software systems. Some of these may be generic software products,
such as a spreadsheet program. Other systems in the assembly may be
specially written for that environment.

Software engineering ethics:

Like other engineering disciplines, software engineering is carried out within
a social and legal framework that limits the freedom of people working in that area.
As a software engineer, you must accept that your job involves wider responsibilities
than simply the application of technical skills. You must also behave in an ethical
and morally responsible way if you are to be respected as a professional engineer.
Some of these are:
1. Confidentiality: You should normally respect the confidentiality of your
employers or clients irrespective of whether or not a formal confidentiality
agreement has been signed.
2. Competence: You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your competence.
3. Intellectual property rights: You should be aware of local laws governing
the use of intellectual property such as patents and copyright.
You should be careful to ensure that the intellectual property of employers
and clients is protected.
4. Computer misuse: You should not use your technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine, say) to extremely serious (dissemination
of viruses or other malware).

Page | 4
Software Engineering – Module 1
IEEE/ ACM code of software engineering ethics:
ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and
Professional Practices.
PREAMBLE:
The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples and
details of how these aspirations change the way we act as software engineering
professionals. Without the aspirations, the details can become legalistic and
tedious; without the details, the aspirations can become high sounding but empty;
together, the aspirations and the details form a cohesive code.
Software engineers shall commit themselves to making the analysis, specification,
design, development, testing and maintenance of software a beneficial and
respected profession. In accordance with their commitment to the health, safety and
welfare of the public, software engineers shall adhere to the following Eight
Principles:
1. PUBLIC — Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that
is in the best interests of their client and employer consistent with the public
interest.
3. PRODUCT — Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT — Software engineers shall maintain integrity and
independence in their professional judgment.
5. MANAGEMENT — Software engineering managers and leaders shall
subscribe to and promote an ethical approach to the management of software
development and maintenance.
6. PROFESSION — Software engineers shall advance the integrity and
reputation of the profession consistent with the public interest.
7. COLLEAGUES — Software engineers shall be fair to and supportive of their
colleagues.
8. SELF— Software engineers shall participate in lifelong learning regarding the
practice of their profession and shall promote an ethical approach to the
practice of the profession.

Page | 5
Software Engineering – Module 1

Case studies:
1. An embedded system: This is a system where the software controls a hardware
device and is embedded in that device. Issues in embedded systems typically
include physical size, responsiveness, power management, etc. The example of an
embedded system that I use is a software system to control a medical device.
2. An information system: This is a system whose primary purpose is to manage
and provide access to a database of information. Issues in information systems
include security, usability, privacy, and maintaining data integrity. The example of an
information system that I use is a medical records system.
3. A sensor-based data collection system: This is a system whose primary
purpose is to collect data from a set of sensors and process that data in some way.
The key requirements of such systems are reliability, even in hostile environmental
conditions, and maintainability. The example of a data collection system that I use
is a wilderness weather station.

Software Process:
A software process is a set of related activities that leads to the production of
a software product. These activities may involve the development of software from
scratch in a standard programming language like Java or C.
There are many different software processes but all must include four activities that
are fundamental to software engineering:
1. Software specification: The functionality of the software and constraints on
its operation must be defined.
2. Software design and implementation: The software to meet the
specification must be produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing customer
needs.

Page | 6
Software Engineering – Module 1
Process Activities
The four basic process activities of specification, development, validation, and
evolution are organized differently in different development processes

1. Software Specification
• It is the process of understanding and defining what services are required
from the system and identifying the constraints on the system’s operation and
development.
• The requirements engineering process aims to produce an agreed
requirements document that specifies a system satisfying stakeholder
requirements.
• Requirements are usually presented at two levels of detail.
• End-users and customers need a high-level statement of the requirements;
system developers need a more detailed system specification.

The Requirements Engineering Process

There are four main activities in the requirements engineering process:

1. Feasibility Study:
• An estimate is made of whether the identified user needs may be
satisfied using current software and hardware technologies.
• The study considers whether the proposed system will be cost-effective
from a business point of view and if it can be developed within existing
budgetary constraints.
2. Requirements Elicitation and Analysis:
• Process of deriving the system requirements through observation of
existing systems, discussions with potential users and procurers, task
analysis, and so on.
• May involve the development of one or more system models and
prototypes.
Page | 7
Software Engineering – Module 1
3. Requirements Specification:
• It is the activity of translating the information gathered during the
analysis activity into a document that defines a set of requirements.
• Two types of requirements may be included in this document.
• User requirements are abstract statements of the system requirements
for the customer and end-user of the system; system requirements are
a more detailed description of the functionality to be provided.
4. Requirements Validation:
• This activity checks the requirements for realism, consistency, and
completeness.
• During this process, errors in the requirements document are inevitably
discovered. It must then be modified to correct these problems.

2. Software Design and Implementation

• The implementation stage of software development is the process of
converting a system specification into an executable system.
• A software design is a description of the structure of the software to be
implemented, the data models and structures used by the system, the
interfaces between system components and, sometimes, the algorithms
used.
• Figure shows an abstract model of this process showing the inputs to the
design process, process activities, and the documents produced as outputs
from this process.
• It shows four activities that may be part of the design process for information
systems:

General model of the design process

Page | 8
Software Engineering – Module 1
1. Architectural design, where you identify the overall structure of the
system, the principal components (sometimes called sub-systems or
modules), their relationships, and how they are distributed.
2. Interface design, where you define the interfaces between system
components. This interface specification must be unambiguous. With a
precise interface, a component can be used without other components
having to know how it is implemented. Once interface specifications are
agreed, the components can be designed and developed concurrently.
3. Component design, where you take each system component and
design how it will operate. This may be a simple statement of the
expected functionality to be implemented, with the specific design left to
the programmer. The design model may be used to automatically
generate an implementation.
4. Database design, where you design the system data structures and
how these are to be represented in a database. Again, the work here
depends on whether an existing database is to be reused or a new
database is to be created.

3. Software Validation
• Software validation or, more generally, verification and validation (V&V) is
intended to show that a system both conforms to its specification and that it
meets the expectations of the system customer.
• Program testing, where the system is executed using simulated test data, is
the principal validation technique.
• Validation may also involve checking processes, such as inspections and
reviews, at each stage of the software process from user requirements
definition to program development.
• Figure shows a three-stage testing process in which system components are
tested then the integrated system is tested and, finally, the system is tested
with the customer’s data.

Stages of testing

The stages in the testing process are:

1. Development Testing:
• The components making up the system are tested by the people
developing the system.

Page | 9
Software Engineering – Module 1
• Each component is tested independently, without other system
components.
• Components may be simple entities such as functions or object classes,
or may be coherent groupings of these entities.
2. System Testing:
• System components are integrated to create a complete system.
• This process is concerned with finding errors that result from
unanticipated interactions between components and component
interface problems.
• It is also concerned with showing that the system meets its functional
and non-functional requirements, and testing the emergent system
properties.
3. Acceptance Testing:
• This is the final stage in the testing process before the system is
accepted for operational use.
• The system is tested with data supplied by the system customer rather
than with simulated test data. Acceptance testing may reveal errors and
omissions in the system requirements definition, because the real data
exercise the system in different ways from the test data.

4. Software Evolution
• The flexibility of software systems is one of the main reasons why more and
more software is being incorporated in large, complex systems.
• Once a decision has been made to manufacture hardware, it is very
expensive to make changes to the hardware design.

System Evolution

• However, changes can be made to software at any time during or after the
system development.
• Even extensive changes are still much cheaper than corresponding changes
to system hardware.

Page | 10
Software Engineering – Module 1
Software Development Life cycle (SDLC):
• A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software process.
• It describes entry and exit criteria for each phase.
• Without SDLC it becomes tough for software project mangers to monitor the
progress of the project.
• It aims to produce successful software products.
• Each process model follows a series of phase unique to its type to ensure
success in the steps of software development.
Need of SDLC
• When a team is developing a software product, there must be a clear
understanding among team representative about when and what to do.
Otherwise, it would point to chaos and project failure.
• Software life cycle model describes entry and exit criteria for each phase.
• A phase can begin only if its stage-entry criteria have been fulfilled. So without
a software life cycle model, the entry and exit criteria for a stage cannot be
recognized.
• Without software life cycle models, it becomes tough for software project
managers to monitor the progress of the project.
Six phases in software development life cycle model
There are following six phases in every Software development life cycle model
1. Requirement gathering and analysis
2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance

Page | 11
Software Engineering – Module 1
Stage1: Requirement gathering and analysis
• Requirement Analysis is the most important and necessary stage in SDLC.
• Business requirements are gathered in this phase.
• This phase is the main focus of the project managers and stake holders.
• Meetings with managers, stake holders and users are held in order to
determine the requirements like
➢ Who is going to use the system?
➢ How will they use the system?
➢ What data should be input into the system?
➢ What data should be output by the system?
• These are general questions that get answered during a requirement
gathering phase.
• After requirement gathering these requirements are analyzed for their validity
• Finally, a Software Requirement Specification (SRS) document is created
which serves the purpose of guideline for the next phase of the model.
Stage2: Design
• In this phase the system and software design is prepared from the
requirement specifications which were studied in the first phase.
• System Design helps in specifying hardware and system requirements helps
in defining overall system architecture.
• The system design specifications serve as input for the next phase of the
model.
Stage 3: Implementation / Coding
• On receiving system design documents, the work is divided in modules/units
and actual coding is started.
• In this phase the code is produced so it is the main focus for the developer.
• This is the longest phase of the software development life cycle.
Stage 4: Testing
• After the code is developed it is tested against the requirements to make sure
that the product is actually solving the needs addressed and gathered during
the requirements phase.
• During this phase
➢ unit testing,
➢ integration testing,
➢ system testing,
➢ acceptance testing is done.

Page | 12
Software Engineering – Module 1
Stage 5: Deployment
• After successful testing the product is delivered / deployed to the customer
for their use.
Stage 6: Maintenance
• Once when the customers start using the developed system then the actual
problems come up and needs to be solved from time to time.
• This process where the care is taken for the developed product is known as
maintenance.

Software Process Models

Waterfall Model:
• The waterfall model, called the classic life cycle,
• This classic life cycle suggests a systematic, sequential approach to
software development
• The waterfall Model illustrates the software development process in a
linear sequential flow. This means that any phase in the development
process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.
• In this Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.

The sequential phases in Waterfall model are:

• Requirement Gathering and analysis − All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification document.
• System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system

Page | 13
Software Engineering – Module 1
design helps in specifying hardware and system requirements and helps
in defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality, which is
referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post
integration the entire system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing
is done; the product is deployed in the customer environment or released
into the market.
• Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also, to enhance
the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment.
Application
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
Advantages
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Disadvantages
• The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.

Page | 14
Software Engineering – Module 1
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.

V – Model
• A variation in the representation of the waterfall model is called the V-model
• It is also known as Verification and Validation model
• V-model describes the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
• Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moves down the left side.
• In reality, there is no fundamental difference between the classic life cycle and
the V-model.
• The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.

Page | 15
Software Engineering – Module 1
Verification Phases
Verification: It involves a static analysis method (review) done without executing
code. It is the process of evaluation of the product development process to find
whether specified requirements meet.
• Business Requirement Analysis
➢ This is the first phase in the development cycle where the product
requirements are understood from the customers perspective.
➢ This phase involves detailed communication with the customer to
understand his expectations and exact requirement.
➢ This is a very important activity and needs to be managed well, as most
of the customers are not sure about what exactly they need.
➢ The acceptance test design planning is done at this stage as business
requirements can be used as an input for acceptance testing.
• System Design
➢ Once you have the clear and detailed product requirements, it is time to
design the complete system.
➢ The system design will have the understanding and detailing the
complete hardware and communication setup for the product under
development.
➢ The system test plan is developed based on the system design. Doing
this at an earlier stage leaves more time for the actual test execution
later.
• Architectural Design
➢ Architectural specifications are understood and designed in this phase.
➢ Usually more than one technical approach is proposed and based on
the technical and financial feasibility the final decision is taken.
➢ The system design is broken down further into modules taking up
different functionality. This is also referred to as High Level Design
(HLD).
➢ The data transfer and communication between the internal modules and
with the outside world (other systems) is clearly understood and defined
in this stage.
➢ With this information, integration tests can be designed and
documented during this stage.
• Module Design
➢ In this phase, the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD).

Page | 16
Software Engineering – Module 1
➢ It is important that the design is compatible with the other modules in
the system architecture and the other external systems.
➢ The unit tests are an essential part of any development process and
helps eliminate the maximum faults and errors at a very early stage.
➢ These unit tests can be designed at this stage based on the internal
module designs.
• Coding Phase
➢ The actual coding of the system modules designed in the design phase
is taken up in the Coding phase.
➢ The best suitable programming language is decided based on the
system and architectural requirements.
➢ The coding is performed based on the coding guidelines and standards.
➢ The code goes through numerous code reviews and is optimized for
best performance before the final build is checked into the repository.
Validation Phases
Validation: It involves dynamic analysis method (functional, non-functional), testing
is done by executing code. Validation is the process to classify the software after
the completion of the development process to determine whether the software
meets the customer expectations and requirements.
• Unit Testing
➢ Unit tests designed in the module design phase are executed on the
code during this validation phase.
➢ Unit testing is the testing at code level and helps eliminate bugs at an
early stage, though all defects cannot be uncovered by unit testing.
• Integration Testing
➢ Integration testing is associated with the architectural design phase.
➢ Integration tests are performed to test the coexistence and
communication of the internal modules within the system.
• System Testing
➢ System testing is directly associated with the system design phase.
➢ System tests check the entire system functionality and the
communication of the system under development with external
systems.
➢ Most of the software and hardware compatibility issues can be
uncovered during this system test execution.
• Acceptance Testing
➢ Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user environment.

Page | 17
Software Engineering – Module 1
➢ Acceptance tests uncover the compatibility issues with the other
systems available in the user environment.
➢ It also discovers the non-functional issues such as load and
performance defects in the actual user environment.
V- Model Application
• Requirements are well defined, clearly documented and fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the project team.
• There are no ambiguous or undefined requirements.
• The project is short.
Advantages of the V-Model
• This is a highly-disciplined model and Phases are completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
Disadvantages of the V-Model
• High risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing.
• Once an application is in the testing stage, it is difficult to go back and change
a functionality.
• No working software is produced until late during the life cycle.

Incremental Process model

• Incremental development is based on the idea of developing an initial
implementation, exposing this to user comment and evolving it through
several versions until an adequate system has been developed.
• This model combines elements of both linear sequential model with the
iterative philosophy of prototyping.

Page | 18
Software Engineering – Module 1
• The incremental model applies linear sequence in a staggered fashion as
calendar time progresses. Each linear sequences produces a deliverable
“increment” of the software.
➢ Incremental model
➢ RAD model
Incremental model:
The Incremental Process Model is a method of software development where the
system is built step by step. Instead of delivering the whole system at once, it is
developed and delivered in small parts called increments. Each increment builds
upon the previous one by adding new functionality, until the complete system is
finished.

• Requirement Analysis
The first step in the Incremental Model is understanding what the software
needs to do. The team gathers the requirements from the product experts and
clearly defines the system’s functional needs. This phase is important
because it sets the foundation for everything else in the development process.

Page | 19
Software Engineering – Module 1
• Design & Development
Next, the team focuses on designing how the software will function and starts
developing it. They work on adding new features and making sure the system
works as expected. The design and development steps go hand-in-hand to
build the functionality of the software.
• Testing
Once a feature is developed, it goes through testing. The testing phase
checks how the software performs, including both new and existing features.
The team uses different testing methods to make sure everything is working
correctly.
• Implementation
This phase involves writing the final code based on the design and
development steps. After testing the functionality, the team verify that
everything is working as planned. By the end of this phase, the product is
gradually improved and updated until it becomes the final working version.
For example:
• word-processing software developed using the incremental paradigm might
deliver basic file management, editing, and document production functions in
the first increment
• more sophisticated editing and document production capabilities in the
second increment
• spelling and grammar checking in the third increment
• advanced page layout capability in the fourth increment
• It should be noted that the process flow for any increment can incorporate the
prototyping paradigm.
When we use the Incremental Model?
• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.
Advantage of Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.

Page | 20
Software Engineering – Module 1
• The Client gets important functionality early.
Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.

Rapid Application Development (RAD):

• RAD is an incremental software development process model.
• It emphasizes short development cycle
• "high speed" adaptation of linear sequential model in which rapid application
is achieved by using component-based construction.
• If requirements are well understood and project scope is constrained, the RAD
process enables a development team to create a "fully functional system"
within very short time periods (e.g., 60 to 90 days)
The phases are
➢ Business modeling
➢ Data modeling
➢ Process modeling
➢ Application generation
➢ Testing & turnover

• Business modeling:
The information flow among business functions is modelled in a way that
answers the following questions:
➢ What information drives the business process?
➢ What information is generated?
➢ Who generates it?

Page | 21
Software Engineering – Module 1
➢ Where does the information go?
➢ Who processes it?
• Data modeling:
The information flow defined as part of the business modeling phase is refined
into a set of data objects that are needed to support the business. The
characteristics (called attributes) of each object are identified and the
relationships between these objects defined.
• Process modeling:
The data objects defined in the data modeling phase are transformed to
achieve the information flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.
• Application generation:
RAD assumes the use of fourth generation techniques. Rather than creating
software using conventional third generation programming languages the
RAD process works to reuse existing program components (when possible)
or create reusable components (when necessary). In all cases, automated
tools are used to facilitate construction of the software.
• Testing and turnover:
Since the RAD process emphasizes reuse, many of the program components
have already been tested. This reduces overall testing time. However, new
components must be tested and all interfaces must be fully exercised.
Application
• RAD should be used only when a system can be modularized to be delivered
in an incremental manner.
• It should be used if there is a high availability of designers for Modelling.
• It should be used only if the budget permits use of automated code generating
tools.
• RAD SDLC model should be chosen only if domain experts are available with
relevant business knowledge.
• Should be used where the requirements change during the project and
working prototypes are to be presented to customer in small iterations of 2-3
months.
The advantages of the RAD Model
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.

Page | 22
Software Engineering – Module 1
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
The disadvantages of the RAD Model
• Dependency on technically strong team members for identifying business
requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on Modelling skills.
• Inapplicable to cheaper projects as cost of Modelling and automated code
generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.

Coping with Change

Prototyping
• A prototype is an initial version of a software system that is used to
demonstrate concepts, try out design options, and find out more about the
problem and its possible solutions
• A software prototype can be used in a software development process to help
anticipate changes that may be required:
1. In the requirements engineering process, a prototype can help with the
elicitation and validation of system requirements.
2. In the system design process, a prototype can be used to explore particular
software solutions and to support user interface design.
• Multiple iterations are used
• After each iteration the result is evaluated by the customer
• The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built.
• In many instances, the client only has a general view of what is expected from
the software product. In such a scenario where there is an absence of detailed

Page | 23
Software Engineering – Module 1
information regarding the input to the system, the processing needs, and the
output requirement, the prototyping model may be employed.
Steps of Prototype Model
➢ Requirement Gathering and Analyst
➢ Quick Decision
➢ Build a Prototype
➢ Assessment or User Evaluation
➢ Prototype Refinement
➢ Engineer Product

• Communication: The process begins with communication, likely involving

gathering requirements and understanding the project's goals.
• Quick Plan: A brief plan is created based on the initial communication.
• Modeling/Quick Design: This stage involves creating a model or a quick
design, which may be a visual representation or a basic structure.
• Construction of Prototype: A prototype is built based on the design.
• Deployment, Delivery, & Feedback: The prototype is deployed, delivered,
and feedback is collected. This feedback loop leads back to the initial
communication stage to refine the process.

Applications of prototype model

• The Prototyping Model should be used when the requirements of the product
are not clearly understood or are unstable.
• The prototyping model can also be used if requirements are changing quickly.

Page | 24
Software Engineering – Module 1
• This model can be successfully used for developing user interfaces, high-
technology software-intensive systems, and systems with complex algorithms
and interfaces.
• The prototyping Model is also a very good choice to demonstrate the technical
feasibility of the product.
Advantages of the Prototyping Model
• Increased user involvement in the product even before its implementation.
• Since a working model of the system is displayed, the users get a better
understanding of the system being developed.
• Reduces time and cost as the defects can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
Disadvantages of the Prototyping Model
• Risk of insufficient requirement analysis owing to too much dependency on
the prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the actual system,
even when it is not technically feasible.
• The effort invested in building prototypes may be too much if it is not
monitored properly.

Incremental Delivery
• ▪ Incremental delivery is an approach to software development where some
of the developed increments are delivered to the customer and deployed for
use in an operational environment. In an incremental delivery process,
customers identify, in outline, the services to be provided by the system.
• They identify which of the services are most important and which are least
important to them.

Page | 25
Software Engineering – Module 1
• Once the system increments have been identified, the requirements for the
services to be delivered in the first increment are defined in detail and that
increment is developed.
• During development, further requirements analysis for later increments can
take place but requirements changes for the current increment are not
accepted.
Incremental delivery has a number of advantages:
1. Customers can use the early increments as prototypes and gain experience
that informs their requirements for later system increments. Unlike prototypes,
these are part of the real system so there is no re-learning when the complete
system is available.
2. Customers do not have to wait until the entire system is delivered before they
can gain value from it. The first increment satisfies their most critical
requirements so they can use the software immediately.
3. The process maintains the benefits of incremental development in that it
should be relatively easy to incorporate changes into the system.
4. As the highest-priority services are delivered first and increments then
integrated, the most important system services receive the most testing. This
means that customers are less likely to encounter software failures in the most
important parts of the system.
However, there are problems with incremental delivery:
1. Most systems require a set of basic facilities that are used by different parts
of the system. As requirements are not defined in detail until an increment is
to be implemented, it can be hard to identify common facilities that are needed
by all increments.
2. Iterative development can also be difficult when a replacement system is
being developed. Users want all of the functionality of the old system and are
often unwilling to experiment with an incomplete new system. Therefore,
getting useful customer feedback is difficult.
3. In the incremental approach, there is no complete system specification until
the final increment is specified. This requires a new form of contract, which
large customers such as government agencies may find difficult to
accommodate.

Spiral model:
• The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model.
Page | 26
Software Engineering – Module 1
• The spiral model can be adapted to apply throughout the entire life cycle of
an application, from concept development to maintenance.
• The spiral development model is also called as risk -driven process model
• Each phase in spiral model begins with design goal and ends with client
reviewing
• Software is developed in a series of incremental releases.
It has two main distinguishing features.
1. A CYCLIC APPROACH
• The software team performs activities that are implied by a circuit/loop/task
region around the spiral in a clockwise direction, beginning at the centre.
2. A SET OF ANCHOR POINT MILESTONES
• A combination of work products and conditions that are attained along the
path of the spiral are noted for each evolutionary pass.
• the first circuit around the spiral might represent a concept of developing
product specification" that starts at the core of the spiral and continues for
multiple iterations until concept development is complete.
• Second circuit around the spiral might represent a product development
• Third circuit around the spiral might represent a product enhancement
• Fourth circuit around the spiral might represent a System maintenance

Page | 27
Software Engineering – Module 1
1. Objectives Defined
• In first phase of the spiral model, we clarify what the project aims to
achieve, including functional and non-functional requirements.
• Requirements are gathered from the customers and the objectives are
identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this
quadrant.
2. Risk Analysis and Resolving
• In the risk analysis phase, the risks associated with the project are
identified and evaluated.
• During the second quadrant, all the possible solutions are evaluated to
select the best possible solution.
• Then the risks associated with that solution are identified and the risks
are resolved using the best possible strategy.
• At the end of this quadrant, the Prototype is built for the best possible
solution.
3. Develop the next version of the Product
• During the third quadrant, the identified features are developed and
verified through testing.
• At the end of the third quadrant, the next version of the software is
available. In the evaluation phase, the software is evaluated to
determine if it meets the customer's requirements and if it is of high
quality.
4. Review and plan for the next Phase
• In the fourth quadrant, the Customers evaluate the so-far developed
version of the software.
• In the end, planning for the next phase is started.
• The next iteration of the spiral begins with a new planning phase, based
on the results of the evaluation.
When to use spiral model?
• When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough customer
feedback.

Page | 28
Software Engineering – Module 1
• Significant changes are expected in the product during the development
cycle.
Advantages of the Spiral SDLC Model
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
Disadvantages of the Spiral SDLC Model
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small
projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.

Introduction to Agility - Agile process

Agility:
• Agility means effective (rapid and adaptive) response to change, effective
communication among all stakeholder.
• Drawing the customer onto team and organizing a team so that it is in control
of work performed. The Agile process is light-weight methods and
• People-based rather than plan-based methods.
• The agile process forces the development team to focus on software itself
rather than design and documentation.
• The agile process believes in iterative method.
• The aim of agile process is to deliver the working model of software quickly to
the customer
• For example: Extreme programming is the best known of agile process.

What is an Agile Process:

Any agile software process is characterized in a manner that addresses a number
of key assumptions about the majority of software projects:

Page | 29
Software Engineering – Module 1
1. It is difficult to predict (estimate for future change) in advance which
software requirements will persist and which will change.
2. For many types of software, design and construction are performed
simultaneously. It is difficult to predict how much design is necessary
before construction is used to prove the design.
3. Analysis, design, construction, and testing are not expected. (from a
planning point of view)
Agility Principles
12 agility principles for those who want to achieve agility:
• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Welcome changing requirements, even late in development.
• Deliver working software frequently, from a couple of weeks to a couple of
Months.
• stake holders and software engineers must work together daily throughout the
project.
• Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
• Continuous attention to technical excellence and good design
enhances(increases)agility.
• Simplicity—the art of maximizing the amount of work not done—is essential.
• The best architectures, requirements, and designs emerge from self–
organizing teams.
• At regular intervals, the team reflects on how to become more effective and
then adjusts its behaviour accordingly.
Not every agile process model applies these 12 principles with equal weight, and
some models choose to ignore (or at least downplay) the importance of one or more
of the principles.
Extreme Programming:
Extreme programming (XP) is perhaps the best known and most widely used of the
agile methods. The name was coined by Beck (2000) because the approach was
developed by pushing recognized good practice, such as iterative development, to
‘extreme’ levels. For example, in XP, several new versions of a system may be
developed by different programmers, integrated and tested in a day.

Page | 30
Software Engineering – Module 1

In extreme programming, requirements are expressed as scenarios (called user

stories), which are implemented directly as a series of tasks. Programmers work
in pairs and develop tests for each task before writing the code. All tests must be
successfully executed when new code is integrated into the system. There is a
short time gap between releases of the system. Figure illustrates the XP process
to produce an increment of the system that is being developed. Extreme
programming involves a number of practices, summarized in table shown below,
which reflect the principles of agile methods:
• Incremental planning: Requirements are recorded on Story Cards and the
Stories to be included in a release are determined by the time available and
their relative priority. The developers break these Stories into development
Tasks.
• Small releases: The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.
• Simple design: Enough design is carried out to meet the current
requirements and no more.
• Test-first development: An automated unit test framework is used to write tests
for a new piece of functionality before that functionality itself is implemented.
• Refactoring: All developers are expected to refactor the code continuously
as soon as possible code improvements are found. This keeps the code
simple and maintainable.
• Pair programming: Developers work in pairs, checking each other's work
and providing the support to always do a good job
• Collective ownership: The pairs of developers work on all areas of the
system, so that no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
• Continuous integration: As soon as the work on a task is complete, it is
integrated into the whole system. Alter any such integration, all the unit tests
in the system must pass

Page | 31
Software Engineering – Module 1
• Sustainable pace: Large amounts of overtime are not considered acceptable
as the net effect is often to reduce code quality and medium-term productivity
• On-site customer: A representative of the end-user of the system (the
Customer) should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team for
implementation.

The XP (Extreme Programming) Process

XP Process have four framework activities: planning, design, coding, and testing.
Planning: The planning activity begins with listening—a requirements gathering
activity.
• Listening leads to the creation of a set of “stories” (also called user stories)
that describe required output, features, and functionality for software to be
built.
• Each story is written by the customer and is placed on an index card. The
customer assigns a value (i.e., a priority) to the story based on the overall
business value of the feature or function.
• Members of the XP team then assess each story and assign a cost—
measured in development weeks—to it.
• If the story is estimated to require more than three development weeks, the
story into smaller stories and the assignment of value and cost occurs again.
It is important to note that new stories can be written at any time.
• the stories with highest value will be moved up in the schedule and
implemented first.

Design: XP design follows the KIS (keep it simple) principle.

• If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that
portion of the design. Called a spike solution.

Page | 32
Software Engineering – Module 1
• XP encourages refactoring—a construction technique that is also a method
for design optimization.
• Refactoring is the process of changing a software system in a way that it does
not change the external behavior of the code and improves the internal
structure.
Coding: design work is done, the team does not move to code, develops a series
of unit tests for each of the stories that is to be included in the current release
(software increment).
• Once the unit test has been created, the developer is better able to focus on
what must be implemented to pass the test.
• Once the code is complete, it can be unit-tested immediately, and providing
feedback to the developers.
• A key concept during the coding activity is pair programming. i.e., two people
work together at one computer workstation to create code for a story.
• As pair programmers complete their work, the code they develop is integrated
with the work of others.
Testing:
• As the individual unit tests are organized into a “universal testing suite”
integration and validation testing of the system can occur on a daily basis.
• XP acceptance tests, also called customer tests, are specified by the
customer and focus on overall system features and functionality. Acceptance
tests are derived from user stories that have been implemented as part of a
software release.

Page | 33