1

Software Engineering
Nature of Software
Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is called
software product.
Defining software:
Software is:
(1) instructions (computer programs) that when executed provide de
sired features, function, and performance;
(2) data structures that enable the programs to adequately manipulate information, and
(3) descriptive information in both hard copy and virtual forms that describes the operation and use of
the programs.
Software does not wear out but deteriorates? Explain.
Software is a logical rather than a physical system element. Therefore, software has one fundamental
characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”

The picture shows how often hardware fails over time. This pattern is called the "bathtub curve." At first,
hardware fails more often because of problems in design or how it was made. These problems are usually
fixed, and the failure rate goes down. For a while, the hardware works well and fails less often. But after
some time, the failure rate starts to go up again. This happens because the hardware gets old and is affected
by things like dust, shaking, rough use, hot or cold temperatures, and other damage. Simply put, the
hardware wears out over time.

Software doesn’t get damaged by things like heat, dust, or shaking—unlike hardware. So, in theory,
software should not "wear out" over time. The failure rate for software usually starts out high because of
hidden bugs or mistakes in the code. But as these bugs are found and fixed, the failure rate drops and levels
off.

This smooth, flat line (called the "idealized curve") is a simple way to show how software failure might
happen. In real life, it’s more complicated. But the main idea is this: Software doesn’t wear out like
hardware—but it deteriorates if it’s not updated or managed well.
 2

Characteristics of good software

The characteristics of software play a critical role in determining its success and impact. Whether it’s a
mobile app, a web application, or an enterprise software solution, understanding and prioritizing these
characteristics are vital to creating high-quality software that fulfills the requirements.
Software characteristics are the key qualities that define the behavior, performance, and usability of
software. These characteristics evaluate and measure the holistic quality of software systems.
1. Functionality
Functionality is the primary characteristic of software that determines its ability to perform the tasks or
functions it is designed for.It involves the features, capabilities, and behaviors that enable users to
accomplish their goals using the software or mobile app. It should meet the specified requirements and
provide the desired functionality to address user needs effectively.By focusing on functionality, software
engineers can ensure that the software aligns with its intended purpose and delivers value to its users.
2. Usability(user friendly):
Usability refers to how easily and efficiently users can interact with the software to achieve their
objectives.A user-friendly interface, intuitive navigation, and clear instructions contribute to the usability
of the software.
By considering the target users and their needs, software engineers can design interfaces that are intuitive,
visually appealing, and easy to navigate. Good usability enhances user satisfaction, reduces training time,
and increases productivity, ultimately leading to the software’s success.
3. Efficiency:
Efficiency is a crucial characteristic that measures how well the software utilizes system resources to
perform its functions. Efficient software executes tasks promptly and utilizes minimal system resources
such as CPU, memory, and disk space.
4. Reliability:
Reliability is a critical characteristic that ensures the software’s ability to perform consistently and
accurately under various conditions.
Reliable software minimizes the occurrence of errors, crashes, or unexpected behavior. Users rely on
software to work as intended, and any unexpected downtime or data loss can have severe consequences.
5. Maintainability:
Maintainability is the ease with which software can be modified, debugged, and enhanced throughout its
life-cycle.
 3

Well-maintained software is easier to fix, update, and adapt to changing requirements. This characteristic
includes writing clean and modular code, providing comprehensive documentation, and following well-
defined development practices.
6. Portability:
Portability refers to the software’s ability to run on different platforms or environments without significant
modifications.
With the increasing diversity of devices and operating systems, software developers must ensure that their
applications can be easily deployed and executed across various platforms. Portable software enables wider
adoption, reduces development costs, and allows users to choose the platform that best suits their needs.
7. Integrity:
Data integrity is one aspect that involves maintaining the accuracy and consistency of data throughout its
cycle. By ensuring data integrity, software engineers can guarantee that the information processed and
stored by the software remains reliable and trustworthy.
Implementation of such mechanisms is essential to ensure data prevention and corruption – error-checking
algorithms, checksums, and data validation techniques.

Types of Software:
System Software: Includes operating systems and utilities that manage computer resources at a low
level.
Application Software: Designed to help users perform specific tasks, such as word processing, web
browsing, and data management.
Embedded Software: Resides within devices to perform dedicated functions, such as in medical
devices, automobiles, and household appliances.

Software Engineering
Software engineering is an engineering branch associated with development of software product
using well-defined scientific principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product.
Key Principles
1. Modularity: Breaking down software into smaller, manageable components that can be
developed and tested independently.
 4

2. Abstraction: Hiding the complex implementation details and exposing only the necessary
functionalities to users and other components.
3. Encapsulation: Bundling the data and methods that operate on the data within a single unit
(class), protecting the internal state from external interference.
4. Reusability: Designing components that can be reused across different projects to save time
and resources.
5. Maintenance: Regularly updating software to fix bugs, add features, and improve
performance.
6. Testing: Ensuring that the software meets its requirements and is free of defects
through various testing methodologies.
Need of Software Engineering
The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working. Following are some of the needs stated:
 Large software
It is easier to build a wall than a house or building, likewise, as the size of the software becomes large,
engineering has to step to give it a scientific process.
 Scalability
If the software process were not based on scientific and engineering concepts, it would be easier to re-
create new software than to scale an existing one.
 Cost
As hardware industry has shown its skills and huge manufacturing has lower down the price of computer
and electronic hardware. But, cost of the software remains high if proper process is not adapted.
 Dynamic Nature
Always growing and adapting nature of the software hugely depends upon the environment in which the
user works. If the nature of software is always changing, new enhancements need to be done in the
existing one. This is where the software engineering plays a good role.
 Quality Management
Better process of software development provides better and quality software product.

Software Engineering Ethics

As a software engineer, you work within a social and legal framework that requires ethical and moral
responsibility beyond technical skills. Upholding honesty and integrity is crucial, and your actions
should reflect positively on the profession. Key areas of ethical responsibility include:

1. Confidentiality: Respect the confidentiality of employers or clients, even without formal

agreements.
 5

2. Competence: Accurately represent your skills and avoid work beyond your capabilities.
3. Intellectual Property: Protect the intellectual property rights of employers and
clients, adhering to local laws.
4. Computer Misuse: Avoid using your skills for unethical purposes, from trivial misuse to
serious cyber offenses.

Software Paradigms
 Software paradigms refer to the methods and steps, which are taken while designing the
software. There are many methods proposed and are implemented. But we need to see where in
the software engineering concept, these paradigms stand. These can be combined into various
categories, though each of them is contained in one another:

Programming paradigm is a subset of Software design paradigm which is further a subset of Software
development paradigm.
Software Development Paradigm
This paradigm is known as software engineering paradigms; where all the engineering concepts pertaining
to the development of software are applied. It includes various researches and requirement gathering
which helps the software product to build. It consists of –
 Requirement gathering
 Software design
 Programming
Software Design Paradigm
This paradigm is a part of Software Development and includes –
 Design
 Maintenance
 Programming
Programming Paradigm
This paradigm is related closely to programming aspect of software development. This includes –
 Coding
 Testing
 Integration
 6

Professional Software Development

Professional software development is a structured activity where software is created for business purposes,
for inclusion in other devices, or as a product (e.g., information systems, CAD systems). Unlike
personal or amateur programming, professional software is typically used by others and often
developed by teams.

Software engineering supports professional development, focusing on program specification, design,

and evolution, which are not typically relevant to personal software projects.

Software Components:
 7

 Software is not just the code but also includes associated documentation, libraries, support
websites, and configuration data that make the software functional and user-friendly.
 Professional software systems often consist of multiple programs, configuration files, and
extensive documentation for both users and developers.

Types of Software Products:

1. Generic Products:

 Stand-alone systems sold on the open market.

 Examples: mobile apps, PC software (databases, word processors), vertical applications
(library systems, accounting systems).
 The developing organization controls the software specification.

2. Customized (Bespoke) Software:

 Tailored systems developed for specific customers.

 Examples: control systems for devices, business process software, air traffic control systems.
 The customer controls the software specification.

Blurring Lines:

 The distinction between generic and customized software is becoming less clear. Many systems
now use generic products as a base, which are then adapted to meet specific customer needs (e.g.,
ERP systems from SAP, Oracle).

Quality in Professional Software:

 Quality considerations extend beyond what the software does to include its behavior,
structure, and documentation.
 Non-functional attributes, such as response time and code understandability, are critical
to professional software.
 The required quality attributes depend on the application: safety for aircraft control
systems, responsiveness for games, reliability for telephone systems, etc.

Software Engineering Practice

Software engineering practice involves applying principles, methods, and tools to achieve high-
quality software development and maintenance. It is a disciplined approach to producing software
systems that are reliable, efficient, and meet user requirements. Here are key aspects of software
engineering practice:

Best Practices in Software Engineering

1. Choose the Right SDLC Model:

 8

Selecting an appropriate Software Development Life Cycle (SDLC) model, such as Agile, Scrum, or
Waterfall, is crucial for aligning project requirements with development processes. Agile is ideal for
projects with evolving requirements and frequent stakeholder feedback, while Waterfall may suit
projects with well-defined and static requirements.

2. Coding Standards:

Adhering to coding best practices is vital for maintaining a clean and efficient codebase. This includes
writing readable code, following naming conventions, and ensuring that code is well- structured to
facilitate maintenance and collaboration. Inline comments and thorough code documentation
further enhance code clarity.

3. Testing Practices:

Implementing rigorous testing methodologies, including unit testing, automated testing, behavior- driven
development (BDD), and test-driven development (TDD), ensures that the software functions correctly
and meets quality standards. Regular code reviews and continuous testing help identify potential issues
early in the development process.

4. Documentation:

Comprehensive documentation is essential for maintaining clarity about the software's functionality and
design. This includes both technical documentation for developers and user documentation for end-
users. Documentation aids in on-boarding new team members, supports future development, and
provides an audit trail for compliance and quality assurance.

5. Version Control:

Utilizing version control systems (like Git) is critical for managing changes to the codebase,
facilitating collaboration among team members, and maintaining a history of code modifications.
Employing branching strategies, such as Git Flow, and ensuring regular, descriptive commits can
further streamline development.

6. Continuous Integration/Continuous Deployment (CI/CD):

Implementing CI/CD practices allows for automated testing and deployment of software, enhancing
efficiency and reducing the risk of errors during the release process. Setting up a CI/CD pipeline
early in the project is essential for seamless integration and delivery.

7. Microservices Architecture:

Adopting a microservices architecture can improve scalability and maintainability by decoupling

components of the application, allowing for independent development and deployment. Clear API
contracts and robust monitoring are crucial for managing inter-service communication and handling
potential failures.

8. Ethical Considerations:

Software engineers should adhere to ethical standards, including the ACM Code of Ethics, which
emphasizes acting in the public interest, maintaining integrity, and ensuring the highest professional
 9

standards. Additionally, privacy and security considerations should be integral to the development
process, adhering to legal requirements and industry standards.

Importance of Best Practices

Following these best practices not only improves the quality of the software but also enhances team
collaboration, reduces errors, and increases overall productivity. By building a strong foundation
based on these principles, software engineers can effectively respond to evolving user needs and
technological advancements, ensuring their projects are successful and sustainable in the long term.

Software Engineering:

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

Software Engineering is a layered technology:

Software engineering is a fully layered technology, to develop software we need to go from one layer to
another. All the layers are connected and each layer demands the fulfillment of the previous layer.
Just as software engineering requires progressing through interconnected layers to build robust software,
advancing your skills in software testing also involves a step-by-step approach.

Methods:

Software engineering methods are step-by-step ways to help people build software the right way. These
methods include many different tasks, like talking with users, figuring out what the software should do,
planning and designing it, writing the code, testing it, and keeping it working after it's done.

These methods follow some basic rules and ideas that help guide each part of the work. They also use
drawings and models to show how the software will look and work.
 10

Tools:

Software engineering tools provide automated or semi-automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the
support of software development, called computer-aided software engineering, is established.

Process:

A process is a collection of activities, actions, and tasks that are performed when some work product is to
be created.

* An activity is a task that tries to reach a big goal (for example, talking with the people involved in the
project). This task is important no matter what kind of software is being made, how big the project is, how
hard it is, or how strictly the rules of software engineering are followed.

*Action: An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural model).

*task: A task focuses on a small, but well-defined objective (e.g.,conducting a unit test) that produces a
tangible outcome.

*quality focus: it defines the continuous process improvement principles of software. It provides
integrity that means providing security to the software so that data can be accessed by only an authorized
person, no outsider can access the data. It also focuses on maintainability and usability.

Software Process structure:

The software process is represented schematically, each framework activity is populated by a set of
software engineering actions.

Process flow:

describes how the framework activities and the actions and tasks that occur within each framework
activity are organized with respect to sequence and time.

Linear process flow:

A linear process flow executes each of the five framework activities in sequence, beginning with
communication and culminating with deployment.

Iterative Process flow:

An iterative process fl ow repeats one or more of the activities before proceeding to the next.
 11

Evolutionary process flow:

An evolutionary process fl ow executes the activities in a “circular” manner. Each circuit through the five
activities leads to a more complete version of the software.

Parallel process flow:

A parallel process flow executes one or more activities in parallel with other activities (e.g.,modeling for
one aspect of the software might be executed in parallel with construction of another aspect of the
software).
 12

Software Process Structure

Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) is a well-defined, structured sequence of stages in
software engineering that ensures the efficient development of a software product. It provides a
framework that guides the entire software development process, from initial concept to deployment
and maintenance.

SDLC Activities

1. Communication

The first step in the SDLC involves initial communication between the client and the service
provider. This phase includes brainstorming, understanding the high-level objectives, and discussing
the scope of the project. The client submits a formal request for the desired software product, and
both parties work to establish a mutual understanding of the project's goals.

2. Requirement Gathering
 13

In this phase, the software development team engages with various stakeholders to gather detailed
information about the requirements. These requirements are categorized into user requirements,
system requirements, and functional requirements. The team employs various techniques such as
studying existing systems, conducting interviews, and using questionnaires. The gathered
information is then documented clearly to ensure all stakeholders have a common understanding of
what needs to be developed.

3. Feasibility Study
 14

After gathering requirements, the team conducts a feasibility study to analyze whether the software
can be designed to meet the user’s needs. This analysis includes technical, operational, and economic
feasibility. The team assesses if the project is financially viable, technically feasible, and practically
achievable within the given constraints.

4. System Analysis

During system analysis, developers create a roadmap and select the most suitable software model
for the project. This phase involves understanding system limitations, identifying potential changes
to existing systems, and analyzing the project's impact on the organization. The team uses various
models, such as use case diagrams and data flow diagrams, to map out system interactions and
ensure all aspects are considered.

5. Software Design

In the software design phase, the knowledge gathered during the requirement gathering and system
analysis phases is translated into a detailed design. This phase is divided into high-level design,
which defines the architecture, and detailed design, which defines specific modules and their
interactions. The output includes logical and physical designs, data dictionaries, and pseudo-codes.
Design reviews are conducted to ensure the design aligns with the project requirements.

6. Coding

The coding phase, also known as programming, is where the software design is implemented through
writing program code. Developers follow coding standards, use version control systems, and conduct
peer reviews to ensure the code is clean, efficient, and consistent. The goal is to produce error-free,
executable programs that align with the software design.

7. Testing

Testing is a critical phase that ensures the software functions as intended. It includes various levels
of testing such as unit testing, integration testing, system testing, and acceptance testing. Automated
testing tools are often used to improve efficiency and reliability. Early identification and resolution
of errors are crucial to maintaining the software's quality and dependability.

8. Integration

This stage involves integrating the software with external entities like libraries, databases, and other
programs. Continuous integration tools are commonly used to automate the process, enabling regular
integration of code changes and automated testing. This helps in identifying and resolving integration
issues promptly.

9. Implementation

Implementation involves installing the software on user machines and configuring it for different
environments. This phase may include user training and providing comprehensive documentation to
ensure smooth adoption and operation of the software. The software is tested for portability,
adaptability, and any integration-related issues are addressed.

10. Operation and Maintenance

 15

The operation and maintenance phase ensures that the software continues to operate efficiently with
minimal errors. Ongoing monitoring, regular updates, and user feedback are essential during this
phase. Users are supported with documentation and training as needed. This phase also involves
addressing hidden bugs and making necessary adjustments as real-world conditions evolve.

Conclusion

The SDLC provides a structured approach to software development, ensuring that each phase is
carefully planned and executed. By following this systematic process, software engineers can
develop high-quality, reliable software that meets user needs, adapts to changes, and remains
sustainable in the long term.

Software Process Models

A software process (sometimes called a Software Development Life Cycle or SDLC model) is a set
of related activities that leads to the production of a software system. There are many different types
of software systems, and there is no universal software engineering method that is applicable to all of
them. Consequently, there is no universally applicable software process. The process used in
different companies depends on the type of software being developed, the requirements of the
software customer, and the skills of the people writing the software.

A model will define the following:

 The tasks to be performed

 The input and output of each task
 The pre and post-conditions for each task
 The flow and sequence of each task

The goal of a software process model is to provide guidance for controlling and
coordinating the tasks to achieve the end product and objectives as effectively as possible

Factors in choosing a software process

Choosing the right software process model for your project can be difficult. If you know your requirements
well, it will be easier to select a model that best matches your needs. You need to keep the following
factors in mind when selecting your software process model:

Project requirements

Before you choose a model, take some time to go through the project requirements and clarify them
alongside your organization’s or team’s expectations. Will the user need to specify requirements in detail
after each iterative session? Will the requirements change during the development process?

Project size

Consider the size of the project you will be working on. Larger projects mean bigger teams, so you’ll need
more extensive and elaborate project management plans.
 16

Project complexity

Complex projects may not have clear requirements. The requirements may change often, and the cost of
delay is high. Ask yourself if the project requires constant monitoring or feedback from the client.

Cost of delay

Is the project highly time-bound with a huge cost of delay, or are the timelines flexible?

Customer involvement

Do you need to consult the customers during the process? Does the user need to participate in all phases?

Familiarity with technology

This involves the developers’ knowledge and experience with the project domain, software tools, language,
and methods needed for development.

Project resources

This involves the amount and availability of funds, staff, and other resources.
 17

Waterfall Model
The first published model of the software development process was derived from engineering
process models used in large military systems engineering (Royce 1970). It presents the software
development process as a number of stages, as shown in Figure. Because of the cascade from one
phase to another, this model is known as the waterfall model or software life cycle. It follows a
linear and sequential approach, where each phase must be completed before the next begins. It is
also known as classic lifecycle.

Phases:
1. Requirements analysis and definition
The system’s services, constraints, and goals are established by consultation with system users.
They are then defined in detail and serve as a system specification.
2. System and software design
The systems design process allocates the requirements to either hardware or software systems. It
establishes an overall system architecture. The system’s architecture is designed based on the
requirements. This phase produces a blueprint for the system.
3. Implementation and unit testing
During this stage, the software design is realized as a set of programs or program units. Unit testing
involves verifying that each unit meets its specification.
4. Integration and system testing
The individual program units or programs are integrated and tested as a complete system to ensure
that the software requirements have been met. After testing, the software system is delivered to the
customer.
5. Operation and maintenance
 18

Normally, this is the longest life-cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle,
improving the implementation of system units, and enhancing the system’s services as new
requirements are discovered.
Advantages:
 Simple and easy to understand and use.
 Phases are processed and completed one at a time.
 Suitable for smaller projects with well-understood requirements.
Disadvantages:
 Inflexible; it is difficult to accommodate changes after the process has started.
 Poor model for long and ongoing projects.
 Not suitable for complex projects or projects with changing requirements.
Applications of Waterfall Model

 Large-scale Software Development Projects

 Saftey critical systems
 Government and defence project
 Projects with well defined requirements
 Projects with stable requirements

Incremental Model (successive version model)

Incremental development is based on the idea of developing an initial implementation, getting
feedback from users and others, and evolving the software through several versions until the required
system has been developed (Figure 2.2). Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback across activities.

Phases:

1. Outline Description
 19

The process starts with an initial idea or requirement, called the "Outline Description." This is a
high-level understanding of what the system should do, encompassing key objectives, features, and
constraints.

The outline provides a basis for the first version of the software, guiding the development of the initial
implementation.
 20

Concurrent Activities

In the Incremental Model, the main activities—Specification, Development, and Validation—occur

concurrently and interactively.

1. Specification

This involves defining and refining the system's requirements. Specifications are not fully detailed at
the start but evolve as the development progresses.

Process

 Initial specifications are derived from the outline description.

 As feedback is received from each increment, the requirements may be adjusted or
expanded to better meet user needs and system goals.
 The specification process is ongoing, allowing for adaptability as new information or
changes emerge.
2. Development

Development is the actual coding and building of the software based on the specifications. This is
done in increments, with each increment building upon the previous one.

Process:

 The first increment might implement core functionalities, creating a basic version of
the software.
 Subsequent increments add new features, enhancements, or fixes to the previous version.
 Development is iterative, meaning that new versions of the software are produced at
regular intervals, incorporating feedback from users and stakeholders.
3. Validation:

Validation ensures that each increment of the software meets the required specifications and
performs as expected. This includes testing, reviewing, and getting feedback.

Process:

 After each development cycle, the increment is tested to verify that it meets the requirements.
 Feedback from testing, users, and stakeholders is used to improve the next increment.
 Validation can involve unit testing, integration testing, system testing, and user
acceptance testing, ensuring the software increment is functional and meets user
expectations.

Feedback Loops:

Interactions: There are feedback loops between the Specification, Development, and Validation
activities. This means:
 21

 As development progresses, the need for specification changes may become apparent, leading to
refinement of requirements.
 Validation may reveal issues or suggest enhancements, influencing both ongoing development
and the specification for future increments.
 The feedback loops enable rapid adjustment to the software as new insights and requirements are
discovered, ensuring the software remains aligned with user needs and expectations.

Outputs: The process produces several versions of the software, each representing a more advanced
stage of the system.

i. Initial Version:

This is the first working version of the software. It may have limited functionality but provides a
foundation upon which further increments can be built.

The initial version is often used to gather early user feedback and ensure the core architecture is
sound.

ii. Intermediate Versions:

These are successive versions that incorporate new features, improvements, or fixes based on
feedback and ongoing development.

Each intermediate version is more complete than the previous one, gradually moving closer to the
final product.

iii. Final Version:

The final version is the completed software product, which incorporates all required features and
meets the final specifications.

After multiple iterations and feedback cycles, this version is considered fully functional and ready
for deployment.

Advantages:
 Allows partial implementation of the system and gets some functionality into the hands of
users quickly.
 Flexibility to make changes during development.
 Risk of failure is reduced as more critical functionalities are delivered first.
Disadvantages:
 Requires good planning and design to decide the increments.
 Each increment must be independently tested.
 The total cost might exceed the cost of using the Waterfall model.
When to use incremental model:
1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. .Requires good planning and design.
5. The total cost is not lower.
6. Well-defined module interfaces are required.
 22

3. Prototyping Model
The Prototyping Model is a software development approach that involves creating an early, working
version of the software system—called a prototype—with limited functionality. This model is
particularly useful when user requirements are not well-understood at the outset. The main goal is to
gather and refine requirements through continuous user feedback, allowing the development team to
better understand user needs and expectations before moving on to full-scale development.

Phases:
1. Requirement Analysis:
The first step involves gathering initial requirements for the system. These requirements are typically
not fully detailed, focusing on the aspects that are currently understood.
Since the understanding of requirements is incomplete at this stage, the focus is on capturing enough
information to build a meaningful prototype.
2. Quick Design:
The second phase could consist of a preliminary design or a quick design. During this stage, the
system’s basic design is formed. However, it is not a complete design. It provides the user with a
quick overview of the system.
3. Prototype Construction:
Based on the quick design, a working prototype is developed. The prototype has minimal
functionality but provides a tangible version of the system for users to interact with.
The prototype may include only the most critical features and a basic user interface, focusing on
those areas that need clarification or validation.
4. User Evaluation:
The prototype is presented to users for evaluation. Users interact with the prototype and provide
feedback on its functionality, usability, and overall alignment with their needs.
 23

The development team observes how users interact with the prototype, noting any difficulties or
misunderstandings.
5. Refinement:
The prototype is refined through several iterations based on the feedback gathered during user
evaluation. This phase continues until the final system requirements are clear and well-defined.
Each iteration aims to bring the prototype closer to the users' expectations and the final product.
6. Full-Scale Development:
Once the requirements are stabilized and well-understood, the final system is developed following a
suitable software development model, such as the Waterfall or Incremental model.
The prototype is discarded, and the actual system is built from scratch using the finalized
requirements. The development team follows a structured approach to ensure that the system meets
all specified requirements and quality standards.
The fully developed and tested software system, ready for deployment and use.
Advantages:
 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.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily.
Disadvantages:
 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.
 The cost of developing prototypes can be high, especially for complex systems.

Software Prototyping - Types

There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely −
 Throwaway/Rapid Prototyping
Throwaway prototyping is also called as rapid or close ended prototyping. This type of prototyping
uses very little efforts with minimum requirement analysis to build a prototype. Once the actual
requirements are understood, the prototype is discarded and the actual system is developed with a
much clear understanding of user requirements.
 24

 Evolutionary Prototyping
Evolutionary prototyping also called as breadboard prototyping is based on building actual
functional prototypes with minimal functionality in the beginning. The prototype developed forms
the heart of the future prototypes on top of which the entire system is built. By using evolutionary
prototyping, the well-understood requirements are included in the prototype and the requirements are
added as and when they are understood.
 Incremental Prototyping
Incremental prototyping refers to building multiple functional prototypes of the various sub-systems
and then integrating all the available prototypes to form a complete system.
 Extreme Prototyping
Extreme prototyping is used in the web development domain. It consists of three sequential phases.
First, a basic prototype with all the existing pages is presented in the HTML format. Then the data
processing is simulated using a prototype services layer. Finally, the services are implemented and
integrated to the final prototype. This process is called Extreme Prototyping used to draw attention
to the second phase of the process, where a fully functional UI is developed with very little regard to
the actual services.

4. Spiral Model
The Spiral Model is a risk-driven software development process model that combines the iterative
development (prototyping) with the systematic aspects of the Waterfall model. It was proposed by
Barry Boehm in 1986. It is risk-driven and emphasizes the identification and reduction of risks at
each iteration. The Spiral Model is particularly well-suited for large, complex, and high-risk projects.

Key Features:

1. Risk Management: The Spiral Model is unique in its focus on identifying and managing
risks throughout the project. Each phase in the spiral involves risk assessment and resolution
activities to mitigate potential issues.
2. Iterative Development: The project passes through multiple iterations (or spirals), each
encompassing the steps of planning, risk analysis, engineering, and evaluation. With each
loop in the spiral, the system becomes completer and more refined.
3. Flexibility: The model allows for changes and refinements at each stage,
accommodating evolving requirements and reducing the risk of project failure.
 25

Phases
1. Objective Identification (Planning):
In the initial phase, requirements are gathered, and a plan is created. This involves defining the
project’s goals, considering various alternatives, and understanding any constraints. It's a critical step to
set a clear direction for the project.
2. Risk Management (Analysis & Risk Evaluation):
During this phase, potential risks are identified, and strategies are developed to manage or mitigate
them. A thorough risk analysis is conducted to identify challenges related to cost, time, technical
difficulties, and user acceptance. Prototyping and simulations may be employed to explore areas of
high risk, ensuring that the project can move forward with a clearer understanding of potential
pitfalls.
3. Prototyping (Engineering & Development):
Prototypes are developed and tested with stakeholders, providing a tangible model to refine requirements
and system design. This phase involves not only the creation of a working prototype or partial system
but also coding, testing, and integration activities. Through iterative refinement, the prototype evolves
based on feedback, bringing the system closer to the desired final product.
4. User Evaluation (Customer Evaluation & Verification):
 26

Feedback from users and stakeholders is crucial at this stage to validate the system's current version.
Users interact with the prototype or partial system, offering insights into functionality, performance,
and design. This feedback is then used to guide further iterations in the spiral process, ensuring that
the system meets user needs.
5. Refinement (Engineering & Implementation):
The system undergoes continuous development and refinement throughout each spiral, gradually
incorporating detailed design, coding, testing, and integration. With each iteration, the system moves
closer to meeting the final set of requirements, evolving into a completer and more robust product.
6. Next Phase Planning (Review & Planning for the Next Spiral):
After each iteration, the current state of the project is reviewed, and plans are made for the next
phase. This includes re-assessing risks, refining the project plan, and updating objectives and
schedules to ensure the project stays on track.
7. Release (Final System Delivery & Maintenance):
Once all spiral iterations are complete, the fully developed and tested system is delivered to the
customer. A maintenance plan is established to ensure the system remains functional and up-to-date,
allowing for ongoing improvements based on user feedback and evolving needs.

Advantages of the Spiral Model:

 Risk Reduction: The focus on risk management helps identify and mitigate risks early in the
development process, reducing the chances of project failure.
 Flexibility: The iterative nature of the Spiral Model allows for changes and refinements at
each stage, accommodating evolving requirements and reducing rework.
 Customer Involvement: Regular feedback from users and stakeholders ensures that
the system meets their needs and expectations, leading to a higher quality final product.

Disadvantages of the Spiral Model:

 Complexity: The Spiral Model is complex and can be difficult to manage, especially
for smaller projects or teams with limited resources.
 High Cost: The iterative nature of the model, combined with the focus on risk management,
can lead to higher costs compared to simpler models.
 Requires Expertise: Successful implementation of the Spiral Model requires experienced
project managers and developers who can effectively manage risks and iterations.

When to Use the Spiral Model:

 Large and Complex Projects: The Spiral Model is ideal for large, complex projects with
significant risks and uncertainties.
 High-Risk Projects: The model is well-suited for projects with high risks, such as those
involving new technologies or uncertain requirements.
 Iterative Development: The model is suitable for projects that benefit from iterative
development, where requirements may evolve over time based on user feedback.

Types of Risks Managed in the Spiral Model

 27

 Operational Risks: Issues with team dynamics, like personnel changes or

miscommunication. The model focuses on engaging stakeholders to identify and
address these risks early.
 Technical Risks: Problems with technology choices, such as untested tech or integration
challenges. Iterative prototypes help assess and resolve these issues before full
implementation.
 External Risks: Risks from outside the project, like market changes or regulatory shifts. The
model's flexibility allows adjustments to project goals and strategies based on these external
factors.
 Requirement Risks: Challenges from unclear or changing requirements. User feedback
and iterative refinement help ensure the software meets user needs.
 Schedule Risks: Delays due to unforeseen issues. Continuous monitoring and adjustment of
schedules help keep the project on track.
 Cost Risks: Budget overruns from mismanaged resources or unexpected complexities. Risk
analysis and mitigation strategies at each spiral phase help manage costs effectively.

5. RAD Model (Rapid Application Development)

The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself involves
the planning required for developing the product.
Rapid Application Development focuses on gathering customer requirements through workshops or
focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the
existing prototypes (components), continuous integration and rapid delivery.
 28

Phases:

1. Requirement Planning

In this phase, users, stakeholders, and developers collaborate to discuss and finalize the project
requirements. The goal is to establish a clear understanding of what needs to be developed but within
a condensed timeframe compared to traditional methods. This phase is focused on quickly
identifying key requirements and setting expectations rather than detailed planning.

2. User Design

This phase involves taking user feedback and building prototypes using developer tools. It includes
the re-examination and validation of data collected in the Requirement Planning phase. The iterative
nature of this phase means that prototypes are continuously refined based on user input, allowing for
frequent adjustments and improvements. This cyclical process helps ensure that the final system
closely aligns with user needs and expectations.

3. Construction

During the Construction phase, developers build the actual system based on the refined prototypes.
This phase involves coding, system integration, and testing of individual components using powerful
automated tools. Because of the extensive work done during the User Design phase, the Construction
phase can focus on speed and accuracy in transforming prototypes into the final product.

4. Cutover (Implementation)

In the Cutover phase, the final product is implemented, tested, and delivered to users. This phase
includes completing any remaining data conversion tasks, providing user training, and managing the
system changeover. The goal is to ensure that the system is fully functional, user-ready, and
seamlessly integrated into the existing environment.

Advantages:

 Fast delivery of software due to minimized planning and prototype reuse.

 Strong user involvement ensures that the system meets the user’s needs.
 Reduces the complexity of large projects by breaking them down into smaller, manageable
pieces.

Disadvantages:

 Requires a highly skilled development team.

 Not suitable for all types of projects, especially those with complex, non-modular
architectures.
 Heavy user involvement can be demanding on client resources and time.
 29

WINWIN spiral model:

WINWIN spiral model:
Spiral Model generally shows the repetitive nature of the prototyping model and control proper well-
defined approaches of the linear sequential model. The spiral model is also known to be a meta-model
because all the other process models are included in the spiral model.
The waterfall model is also represented by the single loop of the spiral model. To develop the prototype
before the establishment of the actual product, the prototyping approach is used by the spiral model.
The evolutionary model is also supported by the spiral model as iterations along the spiral represent
evolutionary levels, using which a complete system can be built. Risk reduction can be done in a spiral
model using a prototyping approach. From the waterfall model, the systematic proper development
approach is adopted.
For obtaining the project requirements, customer communication is very important and essential in the
spiral model, the WIN-WIN model also suggests and supports well and proper communication with the
customer. In actual practice, the process of negotiation which simply means to compromise has to be
faced by the customers and developers. When both sides agree, only then successful negotiation occurs.
This is called the WIN-WIN situation.

 Customer’s win means –

Obtaining the system that fulfill most of the requirements of customers.

 Developer’s win means –

Getting the work done by fulfilling the realistic requirements of customers in a given deadline and
achievable budgets.
At the beginning of each pass of the spiral, the negotiation activities are carried
out in a WIN-WIN spiral model.
Various activities that can be carried out in a WIN-WIN spiral model are shown in the following diagram
–

At the beginning of each pass of the spiral, the negotiation activities are carried out in a WIN-WIN spiral
model.
Various activities that can be carried out in a WIN-WIN spiral model are shown in the following diagram
–

1. Identification of ‘stakeholders’.
 30

2. Determination of stakeholders to make great efforts to achieve or obtain a win condition.

3. Negotiations of stakeholders struggling vigorously for win condition. Software project team conciliate
for a win-win result with concern. Then determine next level objectives, constraints, and alternatives.

4. Evaluation of the process and product and then analyzing and resolving or reducing the risks to make
it easy.

5. Defining the next level of product and process for proper working.

6. Validation of process and product definitions is must.

7. Reviewing of the product and giving the necessary and important comments on it.

Concurrent model:
The concurrent Development Model is a type of software development that enables the different phases
of the development life cycle including designing, coding, and testing to be worked on at the same time.
This model helps teams to stay fluid and responsive, they can solve problems and adapt to changes with
one planning phase needing to finish before the next begins.
When to use it:
it is best suited to projects in which delivery to stakeholders, review, and re-delivery are frequent, which
makes it a crucial approach in contemporary software development.

Features of the Concurrent Development Model

 Parallel Workflow: Several phases start and run concurrently like the design phase, development
phase, and the testing phase allowing completion of a project more expediently.
 Real-time Communication: Everyone gets repeated feedback hence the team works and solutions
together to ensure the common goal is achieved.
 Flexibility: Stakeholders can incorporate new changes and improvements easily since one phase
operates in tangent to another.
 Iterative Development: The model is also suitable for iterative activities in which input and testing
are received continually, and prototypes are revised.
 Reduced Time-to-Market: The work is divided between the tasks and stages, making the project
faster since many tasks are done concurrently.
Stages in the Concurrent Development Model
 System Requirements Gathering: The first involves defining the project manager the general
requirements concerning the project. As opposed to such models where requirements cannot be
changed through recessive phases, requirements, in general, can be modified here and now.
 Design and Prototyping: Design is concurrent with other phases for example the coding and testing
phase. Distinct facets of design such as architectural and system are made and checked at the same
time by using and integrating feedback.
 Development and Coding: Development teams attend to different modules altogether, writing a
certain code for features that will be developed in parallel with design and testing teams. This
concurrency is useful for the implementation of changes and feedback in the design phase.
 Integration and Testing: Testing is approached as an agile process and it is done in parallel to
development. Every module is tested throughout the development allowing the developer to see the
output and pick any error that may be present. Continuous integration is used here to ensure that the
system does not get disrupted each time new features are included.
 Deployment and Maintenance: The deployment occurs gradually and the components are launched
at different intervals. Maintenance is also continuous since information gathered from the live system
will then be used for the further enhancement of the system in parallel with other parallel activities.
 31

Real-World Applications of the Concurrent Development Model

 Aerospace and defence

 Automatic industry
 Consumer electronics
 Construction and architecture
 Video game development

Component based model:

The component-based assembly model uses object-oriented technologies. In object-oriented

technologies, the emphasis is on the creation of classes. Classes are the entities that encapsulate data and
algorithms. In component-based architecture, classes (i.e., components required to build application) can
be uses as reusable components. This model uses various characteristics of spiral model. This model is
evolutionary by nature. Hence, software development can be done using iterative approach. In CBD
model, multiple classes can be used. These classes are basically the prepackaged components. The model
works in following manner:
 Step-1: First identify all the required candidate components, i.e., classes with the help of application
data and algorithms.
 Step-2: If these candidate components are used in previous software projects then they must be
present in the library.
 Step-3: Such preexisting components can be excited from the library and used for further
development.
 Step-4: But if the required component is not present in the library then build or create the component
as per requirement.
 Step-5: Place this newly created component in the library. This makes one iteration of the system.
 Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of iterations required
to develop the complete application.
Characteristics of Component Assembly Model:
 Uses object-oriented technology.
 Components and classes encapsulate both data and algorithms.
 Components are developed to be reusable.
 Paradigm similar to spiral model, but engineering activity involves components.
 The system produced by assembling the correct components.
Agile Software Development
Agile methodologies are iterative and incremental, which means it’s known for breaking a project
into smaller parts and adjusting to changing requirements.
1. They prioritize flexibility, collaboration, and customer satisfaction.
2. Major companies like Facebook, Google, and Amazon use Agile because of its adaptability
and customer-focused approach.
Characteristics of Agile Software Development
 Iterative Process: Involves repeated cycles of development, allowing for adjustments based
on feedback.
 Customer Collaboration: Engages customers throughout the development process to
ensure their needs are met.

 Flexibility: Adapts to changing requirements and market conditions, reducing the risk of
developing obsolete products.
 Incremental Delivery: Delivers software in small, functional increments, allowing for early user
 32

feedback and continuous improvement.

Core Principles of Agile Software Development

 Customer Satisfaction: Prioritize early and continuous delivery of valuable software to

satisfy customers.
 Welcoming Change: Embrace changes in requirements, even late in development, to maintain
customer competitiveness.
 Frequent Delivery: Deliver working software frequently, preferring shorter timescales.
 Collaboration: Ensure daily collaboration between business and development teams.
 Motivated Individuals: Build projects around motivated individuals and trust them to get the
job done.
 Face-to-Face Communication: Use face-to-face conversation as the most efficient way to
convey information.
 33

 Sustainable Pace: Maintain a consistent development pace indefinitely.

 Measure Progress: Measure progress primarily through working software.
 Technical Excellence: Focus on technical excellence and good design to enhance agility.
 Simplicity: Maximize work efficiency by minimizing unnecessary tasks.
 Self-Organizing Teams: Let the best solutions emerge from self-organizing teams.
 Continuous Improvement: Regularly reflect and adjust to improve team effectiveness.
Advantages
 Improved Customer Satisfaction: Frequent releases and direct involvement of customers
lead to higher satisfaction levels.
 Adaptability: Agile methodologies allow teams to pivot quickly in response to changing
requirements.
 Early Detection of Issues: Continuous testing and feedback loops help identify defects early
in the development process.
Disadvantages
 Less Predictability: The flexible nature of Agile can lead to challenges in estimating
timelines and budgets.
 Dependency on Customer Involvement: Agile success relies heavily on active
customer participation; a lack of clarity from the customer can derail the project.
 Documentation Challenges: Agile often prioritizes working software over comprehensive
documentation, which can create challenges for new team members or future maintenance.
 34

Agile Process Models

1. Scrum

Scrum Framework Overview

Scrum is an Agile framework for managing and completing complex projects. It is widely used in
software development but can be applied to any project that requires a flexible, iterative approach.
Scrum emphasizes collaboration, accountability, and iterative progress toward a well-defined
goal.Lifecycle of Scrum

Product Backlog: According to the prioritize features the product is organized.

Sprint Planning Meeting: A meeting where the team selects which features from the Product
Backlog will be worked on in the Sprint, defines the Sprint Goal, and creates a detailed plan (Sprint
Backlog) for completing those features.
Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to sprint and
Sprint planning meeting.
Product Assigned Features to Sprint: These are the features or user stories selected from the
Product Backlog to be worked on in the upcoming Sprint.
Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately after the
completion of the previous Sprint.
Sprint Review: If the product still has some non-achievable features, it will be checked in this stage
and then passed to the Sprint Retrospective stage.
Sprint Retrospective: In this stage quality or status of the product is checked.
Release: When the product is completed, it goes to the Release stage.

Key Roles in Scrum

 Product Owner: Defines the product backlog and prioritizes tasks.

 Scrum: A daily meeting of the Scrum team that reviews progress and prioritizes work to be done
that day.
 Scrum Master: Facilitates the process and removes obstacles.
 35

 Development Team: Builds the product increment.

Phases:

 Sprint Planning: Define the goal and tasks for the upcoming sprint.
 Daily Stand-up: Short, daily meetings to discuss progress and challenges.
 Sprint Review: Review and demonstrate the work completed during the sprint.
 Sprint Retrospective: Reflect on the sprint and identify areas for improvement.

Scrum Artifacts

1. Product Backlog: A prioritized list of features or tasks for the product.

2. Sprint Backlog: The selected tasks from the Product Backlog for the current Sprint.
3. Increment: The sum of completed tasks in a Sprint that adds value to the product.

2. Extreme Programming (XP)

 XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop a software.
 Small to medium sized teams that work under vague and rapidly changing
 requirements.
 The five values of XP are communication, simplicity, feedback, courage, and respect
 Follows Object Oriented approach.
 Spike solution: A spike solution is a very simple program to explore potential
solutions. Difficult designs should be modeled using prototype.
 Refactoring: Improves the internal structure of the code but external behavior not affected.
Extreme Programming (XP) enables developers to respond to user stories, adapt, and modify in real
time.
Phases of Extreme Programming
Extreme Programming (XP), highlighting the iterative nature of the process and the flow between its
phases.
 Planning.
 Design.
 Coding.
 Testing.
 Release
 Listening
 36

1. Planning:

In this phase, the team collaborates with the customer to gather requirements in the form of user
stories. The planning also involves setting values, defining acceptance test criteria, and creating an
iteration plan.

2. Design:

The design phase focuses on creating a simple design using tools like CRC cards (Class-
Responsibility-Collaborator cards) and spike solutions or prototypes to explore possible solutions.

3. Coding:

During coding, XP practices such as pair programming are followed, where two developers work
together. The code undergoes continuous integration, and refactoring is done to improve code
quality without altering its functionality. Unit tests are written and executed to ensure the
functionality of the code.

4. Testing:

The testing phase includes acceptance testing to verify that the software meets the customer’s needs.
The project velocity (the rate at which user stories are completed) is computed, which helps in
planning future iterations.

5. Release:
The final phase is the release of a software increment. This refers to the delivery of functional software
that provides value to the customer.
6. .Listening (Integrated Across All Phases):
 37

Listening is an ongoing activity that occurs throughout all phases of XP. The
development team must actively listen to customer feedback, understand their
evolving needs, and make necessary adjustments. This phase ensures the product
remains aligned with customer expectations and allows the team to respond to
changes swiftly.

Industrail xtreme programming:

Joshua Kerievsky describes Industrial Extreme Programming (IXP) as a natural

extension of Extreme Programming (XP). It keeps the core ideas of XP—keeping
things simple, focusing on the customer, and using testing to drive development.
However, IXP stands out by involving management more deeply, giving customers
a bigger role, and improving the technical practices used.

IXP adds six new practices to help ensure XP works well on large projects within big
organizations:

1. Readiness Assessment: The team checks if everyone involved—developers,

managers, stakeholders—is prepared, understands their roles, and has the right
environment and skills for the project.
2. Project Community: The team makes sure the right people with the necessary
skills and training are part of the project. This group includes both tech experts
and other key stakeholders
3. Project Chartering: The team looks at the project’s purpose to make sure it has
a strong business reason and fits with the organization’s overall goals.
4. Test-Driven Management: The team sets clear goals (called "destinations") to
measure progress. It also defines how to check if these goals are being met.
5. Retrospectives: After delivering a part of the software, the team holds a special
review session to look back at what happened, what went well, what didn’t, and
what lessons were learned.
6. Continuous Learning: Team members are encouraged (and sometimes
rewarded) to learn new tools, methods, or techniques that can improve the quality
of the product.

Besides these new practices, IXP also updates and improves several existing XP
practices and redefines some team roles and responsibilities to better fit large,
complex projects.