Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET

Department of CSE - Degree 5th sem.

Software Engineering - 3150711

Unit 1: Introduction to Software Engineering

The Evolving Role of Software

Software Evolution is a term that refers to the process of developing software
initially, and then timely updating it for various reasons, i.e., to add new features
or to remove obsolete functionalities, etc.
What is Software Evolution?
The software evolution process includes fundamental activities of change
analysis, release planning, system implementation, and releasing a system to
customers.
1. The cost and impact of these changes are accessed to see how much
the system is affected by the change and how much it might cost to
implement the change.
2. If the proposed changes are accepted, a new release of the software
system is planned.
3. During release planning, all the proposed changes (fault repair,
adaptation, and new functionality) are considered.
4. A design is then made on which changes to implement in the next
version of the system.
5. The process of change implementation is an iteration of the
development process where the revisions to the system are designed,
implemented, and tested.

Necessity of Software Evolution

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 1

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Software evaluation is necessary just because of the following reasons:

1. Change in requirement with time: With time, the organization’s

needs and modus Operandi of working could substantially be changed

so in this frequently changing time the tools(software) that they are
using need to change to maximize the performance.
2. Environment change: As the working environment changes the

things(tools) that enable us to work in that environment also changes

proportionally. The same happens in the software world as the
working environment changes then, the organizations require
reintroduction of old software with updated features and functionality
to adapt to the new environment.
3. Errors and bugs: As the age of the deployed software within an

organization increases, their preciseness or impeccability decrease and

the efficiency to bear the increasing complexity workload also
continually degrades. So, in that case, it becomes necessary to avoid
the use of obsolete and aged software. All such obsolete Pieces of
software need to undergo the evolution process in order to become
robust as per the workload complexity of the current environment.
4. Security risks: Using outdated software within an organization may

lead you to be at the verge of various software-based cyberattacks and

could expose your confidential data illegally associated with the
software that is in use. So, it becomes necessary to avoid such security
breaches through regular assessment of the security patches/modules

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 2

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

used within the software. If the software isn’t robust enough to bear
the current occurring Cyber attacks so it must be changed (updated).
5. For having new functionality and features: In order to increase the

performance and fast data processing and other functionalities, an

organization needs to continuously evaluate the software throughout
its life cycle so that stakeholders & clients of the product could work
efficiently.

Laws used for Software Evolution

1. Law of Continuing Change

This law states that any software system that represents some real-world reality
undergoes continuous change or becomes progressively less useful in that
environment.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 3

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

2. Law of Increasing Complexity

As an evolving program changes, its structure becomes more complex unless

effective efforts are made to avoid this phenomenon.

3. Law of Conservation of Organization Stability

Over the lifetime of a program, the rate of development of that program is

approximately constant and independent of the resource devoted to system
development.

4. Law of Conservation of Familiarity

This law states that during the active lifetime of the program, changes made in
the successive releases are almost constant.

Software: A Crisis on the Horizon and Software Myths

Unlike ancient myths, software myths propagate misinformation and confusion

that have caused serious problems for managers, technical people and
customers.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 4

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Management Myths :
● Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they
need to know?
● Reality: The book of standards may very well exist, but is it used? Is it
complete? In many cases, the answer is no.
● Myth: If we get behind schedule, we can add more programmers and
catch up.
● Reality: Software development is not a mechanistic process like
manufacturing.
● Myth: If we decide to outsource the software project to a third party, I can
just relax and let that firm build it.
● Reality: If an organization does not understand how to manage and
control software projects internally, it will invariably struggle when it
outsourced software projects.

Customer Myths

● Myth: Project requirements continually change, but change can be

easily accommodated because software is flexible.
● Reality: It is true that software requirements do change, but the
impact of change varies with the time at which it is introduced.
● Myth: A general statement of objectives is sufficient to begin
writing programs we can fill in the details later.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 5

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

● Reality: Although a comprehensive and stable statement of

requirements is not always possible, an ambiguous statement of
objectives is a recipe for disaster.

Practitioner’s Myths

● Myth: Once we write the program and get it to work our job is done.
● Reality: “The sooner you begin writing code, the longer it’ll take you to
get done.” Industry data indicate that between 60 and 80 percent of all
effort expended on software will be expended after it is delivered to the
customer for the first time.
● Myth: Until I get the program running, I have no way of assessing its
quality.
● Reality: One of the most effective software quality assurance mechanisms
can be applied from the inception of a project-the formal technical
review.
● Myth: The only deliverable work product for a successful project is the
working program.
● Reality: A working program is only one part of a software configuration
that includes many elements.
● Myth: Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us down.
● Reality: Software engineering is not about creating documents. It is about
creating quality. Better quality leads to reduced rework.

Software Engineering: A Layered Technology

Layered technology is an architectural pattern that separates a software system

into separate logical layers. It is sometimes referred to as layered architecture or
layered design. Every layer is in charge of a certain component of the
functionality of the program and it mostly communicates with the layers that are
just above and below it. This division of responsibilities encourages modularity
which improves extensibility and maintainability.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 6

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

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.

Layered technology is divided into four parts:

1. A 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.
2. Process: It is the foundation or base layer of software engineering. It is key
that binds all the layers together which enables the development of software
before the deadline or on time. Process defines a framework that must be
established for the effective delivery of software engineering technology. The
software process covers all the activities, actions, and tasks required to be
carried out for software development.
Process activities are listed below:-

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 7

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

● Communication: It is the first and foremost thing for the

development of software. Communication is necessary to know the
actual demand of the client.
● Planning: It basically means drawing a map to reduce the
complication of development.
● Modeling: In this process, a model is created according to the client
for better understanding.
● Construction: It includes the coding and testing of the problem.
● Deployment:- It includes the delivery of software to the client for
evaluation and feedback.

3. Method: During the process of software development the answers to all

“how-to-do” questions are given by method. It has the information of all the
tasks which includes communication, requirement analysis, design modeling,
program construction, testing, and support.
4. Tools: Software engineering tools provide a self-operating system for
processes and methods. Tools are integrated which means information created
by one tool can be used by another.

Software Process Models:

Software Processes is a coherent set of activities for specifying, designing,

implementing and testing software systems. A software process model is an

abstract representation of a process that presents a description of a process from

some particular perspective. There are many different software processes but all

involve:

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 8

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

● Specification – defining what the system should do;

● Design and implementation – defining the organization of the system and

implementing the system;

● Validation – checking that it does what the customer wants;

● Evolution – changing the system in response to changing customer needs.

The Linear Sequential Model:

It is also called a linear sequential model, classic life cycle or waterfall model. It
suggests a systematic, sequential approach to Software Development that
begins at a systematic level and progresses through communication, planning,
modeling, construction, and deployment.

GATHERING REQUIREMENTS

The first and foremost step is to know thoroughly about the demands of
customers and other stakeholders. It is to assure all the necessary information is

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 9

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

gathered. The client is also made aware of the Software Development Process.
Penning down all requirements decides about the specific development process.

If you are not so sure about your client’s requirements, then probably you would
end up in developing a product which is not going to satisfy your customer. This
is not only a loss but also a time-wasting activity. Probably you would need to
restart with developing the product from the start.

In today’s world, satisfying the customer is one of the fundamental goals to

achieve. If your customer has positive feedback to your performance, only then
you can have good respect in the present global market. Of course, your new
customers would be reviewing your profile and the remarks of your former
customers to assure your working capability.

It is the most important step of waterfall methodology because there is no

retrieval or stepping back to alterations once the development has been started.
The Waterfall methodology is most appropriate for projects which have a very
clear picture until the last stage. It does not lend itself particularly well to
projects where the requirements are not clearly understood at the outset.

PLANNING

This development step contains the making of the idea, gathering suggestions,
deciding timelines, technical procedures and working schedules. It demands the
proper research about the product value, the targeted audience of the product,
and its symmetry to your client’s business requirements.

Linear sequential model of Software Development is the best option for

smaller projects. Thorough planning is the demand of waterfall methodology. If
the issue raises, there might be chances of restarting the development process
from scratch.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 10

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

To assure the marketing efficiency of the product is also part of the planning. Of
course, you don’t want to build a product which has no compatibility with
market demands and earning no return on investment.

By keeping your customer’s demands and market value of the product can help
you in creating a milestone for your project. Be clear about the planning and
time schedule to keep your development team on track so you can have a
fruitful implementation and in meeting the deadline.

As a way to proceed with the start-up phase, the project should make sure that
all individuals directly and indirectly connected to the project (like the
independent reviewer) clearly understand the goals of the project and the effect
it is going to have upon them.

MODELING

At this step, there is a need for a proper map to Project Development. Having
all requirements, info, and ingredients to construct the product, then it’s time for
you to have a timeline to better understand the demands and design to achieve
these requirements. This stage will help you to choose the employment of the
technologies and services you will be needing in the development process.

The central focus behind this road map is to have the understanding to build a
robust infrastructure and user-friendly application. A mock-up model of the
project will guide you with the vision about the inner structure and the user
interface of the product. It will also help you in choosing the user-friendly and
attractive design of the application to target the maximum relative audience.
Effective and healthy planning is an essential step to plan out how time and
money is going to be spent on the project.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 11

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

DEVELOPING:

The entire process is broken into sequential stages. It’s vital to finish each phase
successfully as a way to move onto the next one. All kinds of testing methods
are essentially carried out during the validation approach.

TESTING

Software Testing is a procedure of finding defects to guarantee that the system

being developed meets the requirements. This process assures quality and
optimized efficiency. You need to run tests on every form, every script, run a
spell-checking software to remove every possible typo. Use code validators to
examine if the code follows the latest web standards. The valid code is
important, for example, if cross-browser compatibility is important for your
website.

After the continuous testing, it’s the right time to upload it to the server. The file
transfer protocol software is used to achieve the purpose. After the successful
deployment of the files, you need to run another test to assure all files are
installed accurately.

The Prototyping Model:

The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built. A prototype is a
toy implementation of the system. A prototype usually turns out to be a very
crude version of the actual system, possibly exhibiting limited functional
capabilities, low reliability, and inefficient performance as compared to actual
software. 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 information regarding the input to the system, the
processing needs, and the output requirement, the prototyping model may be
employed.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 12

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision

3. Build a Prototype

4. Assessment or User Evaluation

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 13

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

5. Prototype Refinement

6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted

3. Regular visible process aids management

4. Support early product marketing

5. Reduce Maintenance cost.

6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final

product.

2. Require extensive customer collaboration

○ Costs customer money

○ Needs committed customer

○ Difficult to finish if customer withdraw

○ May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 14

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

5. Prototyping tools are expensive.

6. Special tools & techniques are required to build a prototype.

7. It is a time-consuming process.

The RAD Model:

RAD is a linear sequential software development process model that

emphasizes a concise development cycle using an element based construction
approach. If the requirements are well understood and described, and the project
scope is a constraint, the RAD process enables a development team to create a
fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be

developed faster and of higher quality through:

○ Gathering requirements using workshops or focus groups

○ Prototyping and early, reiterative user testing of designs

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 15

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

○ The re-use of software components

○ A rigidly paced schedule that refers design improvements to the next

product version

○ Less formality in reviews and other team communication

The various phases of RAD are as follows:

1. Business Modelling: The information flow among business functions is

defined by answering questions like what data drives the business process, what
data is generated, who generates it, where does the information go, who
processes it and so on.

2. Data Modeling: The data collected from business modeling is refined into a
set of data objects (entities) that are needed to support the business. The
attributes (character of each entity) are identified, and the relation between these
data objects (entities) is defined.

3. Process Modeling: The information objects defined in the data modeling

phase are transformed to achieve the data flow necessary to implement a
business function. Processing descriptions are created for adding, modifying,
deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction

of the software; even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already

been tested since RAD emphasis reuse. This reduces the overall testing time.
But the new part must be tested, and all interfaces must be fully exercised.

When to use the RAD Model?

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 16

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

○ When the system should need to create the project that modularizes in a
short span time (2-3 months).

○ When the requirements are well-known.

○ When the technical risk is limited.

○ When there's a necessity to make a system, which is modularized in 2-3

months of period.

○ It should be used only if the budget allows the use of automatic code
generating tools.

Advantage of RAD Model

○ This model is flexible for change.

○ In this model, changes are adoptable.

○ Each phase in RAD brings highest priority functionality to the customer.

○ It reduced development time.

○ It increases the reusability of features.

Disadvantage of RAD Model

○ It required highly skilled designers.

○ All applications are not compatible with RAD.

○ For smaller projects, we cannot use the RAD model.

○ On the high technical risk, it's not suitable.

○ Required user involvement.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 17

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Evolutionary Process Models:

Evolutionary process model resembles the iterative enhancement model. The

same phases are defined for the waterfall model that occurs here in a cyclical
fashion. This model differs from the iterative enhancement model in the sense
that this does not require a useful product at the end of each cycle. In
evolutionary development, requirements are implemented by category rather
than by priority.

For example, in a simple database application, one cycle might implement the
graphical user Interface (GUI), another file manipulation, another queries and
another updates. All four cycles must be completed before there is a working
product available. GUI allows the users to interact with the system, file
manipulation allows the data to be saved and retrieved, queries allow users to
get out of the system, and updates allow users to put data into the system.

Benefits of Evolutionary Process Model

● EPM can reduce costs by providing a structured, disciplined avenue for

experimentation.
● EPM allows the marketing department access to early deliveries,
facilitating the development of documentation and demonstration.
● Better fit the product to user needs and market requirements.
● Manage project risk with the definition of early cycle content.
● Uncover key issues early and focus attention appropriately.
● Increase the opportunity to hit market windows.

Agile Process Model:

The meaning of Agile is swift or versatile."Agile process model" refers to a

software development approach based on iterative development. Agile methods
break tasks into smaller iterations, or parts do not directly involve long term
planning. The project scope and requirements are laid down at the beginning of
the development process. Plans regarding the number of iterations, the duration
and the scope of each iteration are clearly defined in advance.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 18

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Each iteration is considered as a short time "frame" in the Agile process model,
which typically lasts from one to four weeks. The division of the entire project
into smaller parts helps to minimize the project risk and to reduce the overall
project delivery time requirements. Each iteration involves a team working
through a full software development life cycle including planning, requirements
analysis, design, coding, and testing before a working product is demonstrated
to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering

2. Design the requirements

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 19

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

3. Construction/ iteration

4. Testing/ Quality assurance

5. Deployment

6. Feedback

1. Requirements gathering: In this phase, you must define the requirements.

You should explain business opportunities and plan the time and effort needed
to build the project. Based on this information, you can evaluate technical and
economic feasibility.

2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the
high-level UML diagram to show the work of new features and show how it
will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of
improvement, so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the
team receives feedback about the product and works through the feedback.

Component-Based Development:

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 20

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Component based development is a software system development methodology

where the system is developed using reusable software components. Component
based development aims at improved efficiency, performance and quality of the
system by recycling components.

ELEMENTS OF COMPONENT BASED DEVELOPMENT

Component based development is a software system development
methodology where the system is developed using reusable software
components. The elements of component based development include the
following:

· Reuse of software components

· Buy, don’t develop
. “Commercial off-the-shelf” (COTS)
· Shift of attention.
. From programming to composing
. From design to selection
· Speed of development
· Cost efficient

ORIGIN CBD (OR CBSE)

Component-based software engineering (CBSE) is a general approach to

software development that is based on software reuse. It emerged from the
failure of object-oriented development to support effective reuse. Single object

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 21

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

classes are too detailed and specific. Components are more abstract than object
classes and can be considered to be stand-alone service providers.
“Component Based Software Engineering (CBSE) is changing the way software
systems are developed. CBSE embodies the ‘buy, don’t build’
philosophy…CBSE shifts the emphasis from programming software to
composing software systems.
Implementation has given way to integration as the focus. At its foundation is
the assumption that there is sufficient commonality in many large software
systems to justify developing reusable components to exploit and satisfy that
commonality”

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 22

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Product:
In the context of software engineering, Product includes any software
manufactured based on the customer’s request. This can be a problem solving
software or computer based system. It can also be said that this is the result of a
project.
Process:
Process is a set of sequence steps that have to be followed to create a project.
The main purpose of a process is to improve the quality of the project. The
process serves as a template that can be used through the creation of its
examples and is used to direct the project.
The main difference between a process and a product is that the process is a set
of steps that guide the project to achieve a convenient product. while on the
other hand, the product is the result of a project that is manufactured by a wide
variety of people.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 23

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Unit 2: Agile Development

Agility and Agile Process model:

Agile Development is a set of principles for software development under which

requirements and solutions evolve through the collaborative effort of
self-organizing and cross-functional teams. The Agile Manifesto outlines four
key values:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agility in software development refers to the ability of a team to adapt to

changes, deliver high-quality software quickly, and meet customer needs
effectively.

Agile Model:

The meaning of Agile is swift or versatile."Agile process model" refers to a

software development approach based on iterative development. Agile methods
break tasks into smaller iterations, or parts do not directly involve long term
planning. The project scope and requirements are laid down at the beginning of
the development process. Plans regarding the number of iterations, the duration
and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model,
which typically lasts from one to four weeks. The division of the entire project
into smaller parts helps to minimize the project risk and to reduce the overall
project delivery time requirements. Each iteration involves a team working
through a full software development life cycle including planning, requirements
analysis, design, coding, and testing before a working product is demonstrated
to the client.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 24

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering

2. Design the requirements

3. Construction/ iteration

4. Testing/ Quality assurance

5. Deployment

6. Feedback

1. Requirements gathering: In this phase, you must define the requirements.

You should explain business opportunities and plan the time and effort needed

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 25

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

to build the project. Based on this information, you can evaluate technical and
economic feasibility.

2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the
high-level UML diagram to show the work of new features and show how it
will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of
improvement, so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the
team receives feedback about the product and works through the feedback.

Extreme Programming:

Extreme Programming (XP) is an Agile software development methodology

that emphasizes technical excellence and customer satisfaction. It aims to
improve software quality and responsiveness to changing customer
requirements through frequent releases in short development cycles. Here are
some key aspects of XP:

Core Practices of XP:

1. Planning Game: Involves two types of planning: release planning, where

high-level requirements are defined, and iteration planning, where tasks
for the next iteration are detailed.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 26

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

2. Small Releases: Frequently releasing small, functional versions of the

software to ensure that progress is visible and feedback is received early.
3. System Metaphor: Using a simple, shared story of how the system
works to ensure team members understand and communicate about the
system effectively.
4. Simple Design: Focusing on designing the simplest possible solution that
works, avoiding over-engineering.
5. Testing: Writing tests before coding (Test-Driven Development or TDD)
and continuously running tests to ensure the system works as intended.
6. Refactoring: Continuously improving the design of existing code without
changing its behavior, ensuring that the code remains clean and adaptable.
7. Pair Programming: Two developers work together at one workstation,
with one writing the code while the other reviews it, leading to higher
quality and shared knowledge.
8. Collective Code Ownership: Encouraging all team members to
contribute to any part of the codebase, promoting responsibility and
flexibility.
9. Continuous Integration: Integrating and testing code frequently, ideally
several times a day, to catch issues early and ensure the system is always
in a releasable state.
10.40-Hour Week: Promoting sustainable work hours to avoid burnout and
maintain productivity and creativity.
11. On-Site Customer: Having a real customer or a representative available
to provide immediate feedback and clarify requirements.
12. Coding Standards: Adopting a common coding style to ensure
consistency and readability across the team.

Benefits of XP:

● High Quality Software: Emphasis on testing and continuous integration

leads to fewer bugs and higher reliability.
● Flexibility: Ability to adapt to changing requirements due to short
development cycles and frequent releases.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 27

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

● Improved Communication: Practices like pair programming and

collective code ownership enhance knowledge sharing and collaboration.
● Customer Satisfaction: Continuous feedback from the customer ensures
that the product meets their needs and expectations.
● Sustainable Pace: The focus on a sustainable work schedule helps
maintain a high level of productivity over the long term.

XP Artifacts:

● User Stories: Short descriptions of functionality told from the

perspective of the user, used to capture requirements.
● Release Plan: A high-level plan outlining which user stories will be
delivered and when.
● Iteration Plan: A detailed plan for the upcoming iteration, including
specific tasks and their estimated effort.
● Acceptance Tests: Tests defined by the customer to validate that the
system meets their requirements.

XP Roles:

● Customer: Provides requirements, prioritizes user stories, and gives

feedback on the product.
● Developer: Writes code, creates tests, and works on delivering user
stories.
● Tracker: Monitors the progress of the team, ensuring that tasks are
completed on time.
● Coach: Guides the team in following XP practices and improving their
processes.

Extreme Programming is particularly well-suited for projects with highly

dynamic requirements and those that need to deliver high-quality software
quickly. By focusing on technical excellence and continuous feedback, XP helps
teams build software that is both robust and flexible.

Other process models of Agile Development and Tools:

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 28

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

In addition to Extreme Programming (XP), there are several other process

models within Agile Development. Each model has its own set of practices and
principles, catering to different types of projects and team dynamics. Here are
some of the most commonly used Agile methodologies and the tools that
support them:

Agile Process Models:

1. Scrum:
○ Description: Scrum is a framework that uses fixed-length
iterations called sprints, typically lasting 2-4 weeks. It includes
roles like Scrum Master, Product Owner, and Development Team,
and ceremonies such as Daily Standups, Sprint Planning, Sprint
Review, and Sprint Retrospective.
○ Artifacts: Product Backlog, Sprint Backlog, Increment, Burndown
Chart.
○ Roles: Scrum Master, Product Owner, Development Team.
2. Kanban:
○ Description: Kanban is a visual approach to managing work as it
moves through a process. It emphasizes continuous delivery
without overburdening the team, with work items represented
visually on a Kanban board.
○ Principles: Visualize Work, Limit Work in Progress (WIP),
Manage Flow, Make Process Policies Explicit, Implement
Feedback Loops.
○ Artifacts: Kanban Board, Cumulative Flow Diagram.
3. Lean Software Development:
○ Description: Lean focuses on creating more value for customers
with fewer resources by optimizing the flow of work, eliminating
waste, and improving quality.
○ Principles: Eliminate Waste, Build Quality In, Create Knowledge,
Defer Commitment, Deliver Fast, Respect People, Optimize the
Whole.
○ Artifacts: Value Stream Mapping, Lean Canvas.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 29

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

4. Crystal:
○ Description: Crystal is a family of methodologies (e.g., Crystal
Clear, Crystal Orange) that focus on people and their interactions
rather than processes and tools. It is adaptable to the size and
criticality of the project.
○ Principles: Frequent Delivery, Reflective Improvement, Osmotic
Communication, Personal Safety, Focus, Easy Access to Expert
Users.
○ Artifacts: Reflective Workshops, Project Charter.
5. Feature-Driven Development (FDD):
○ Description: FDD is an iterative and incremental development
methodology focusing on designing and building features. It
follows a model-driven approach and includes five main activities:
develop an overall model, build a features list, plan by feature,
design by feature, and build by feature.
○ Principles: Domain Object Modeling, Developing by Feature,
Individual Class Ownership, Regular Builds, Inspections.
○ Artifacts: Feature List, Domain Model.

Agile Tools:

1. JIRA: A popular tool for tracking and managing Agile projects. Supports
Scrum and Kanban boards, sprint planning, backlog grooming, and
reporting.
2. Trello: A visual project management tool that uses boards, lists, and cards
to organize tasks. Suitable for Kanban and other lightweight Agile
practices.
3. Asana: A work management tool that helps teams organize, track, and
manage their work. Supports task assignments, project timelines, and
collaboration.
4. Azure DevOps: A set of development tools that support Agile practices,
including boards for tracking work items, repositories, CI/CD pipelines,
and test plans.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 30

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

5. Rally (CA Agile Central): An Agile project management tool that helps
teams track work, plan sprints, and visualize progress through various
dashboards and reports.
6. VersionOne: An Agile project management tool that supports Scrum,
Kanban, XP, and other Agile methodologies. It provides features for
planning, tracking, and reporting.
7. Pivotal Tracker: A story-based project management tool that helps teams
prioritize, deliver, and iterate on their product's development.
8. Miro: An online collaborative whiteboard platform that supports
brainstorming, planning, and visual project management, often used for
Agile ceremonies and workshops.
9. [Link]: A work operating system that allows teams to create their
workflows, manage tasks, and collaborate in a visual and flexible
environment.
10. Targetprocess: A visual project management tool designed to help scale
Agile across the organization, supporting various Agile frameworks and
providing comprehensive reporting and visualization capabilities.

Each Agile methodology and tool has its strengths and is suited to different
types of projects and team dynamics. Choosing the right combination depends
on the specific needs and context of the project.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 31

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Unit 3: Managing Software Project

Software Project Management (SPM) is a proper way of planning and leading

software projects. It is a part of project management in which software projects
are planned, implemented, monitored, and controlled.

Software is a non-physical product. Software development is a new stream in

business and there is very little experience in building software products. Most
of the software products are made to fit clients’ requirements. The most
important is that basic technology changes and advances so frequently and
rapidly that the experience of one product may not be applied to the other one.
Such types of business and environmental constraints increase risk in software
development hence it is essential to manage software projects efficiently.

Software Metrics (Process, Product and Project Metrics)

A metric is a measurement of the level at which any impute belongs to a system

product or process. Software metrics are a quantifiable or countable assessment
of the attributes of a software product. There are 4 functions related to software
metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 32

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Product Metrics: Product metrics are used to evaluate the state of the
product, tracing risks and undercover prospective problem areas. The
ability of the team to control quality is evaluated. Examples include lines
of code, cyclomatic complexity, code coverage, defect density, and code
maintainability index.

Process Metrics: Process metrics pay particular attention to enhancing the

long-term process of the team or organization. These metrics are used to
optimize the development process and maintenance activities of software.
Examples include effort variance, schedule variance, defect injection rate,
and lead time.

Project Metrics: The project metrics describe the characteristics and

execution of a project. Examples include effort estimation accuracy,
schedule deviation, cost variance, and productivity. Usually measures-i

a. Number of software developer

b. Staffing patterns over the life cycle of software
c. Cost and schedule
d. Productivity

Advantages of Software Metrics:

1. Reduction in cost or budget.

2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product.
6. It helps to determine the complexity of the code and to test the code
with resources.
7. It helps in providing effective planning, controlling and managing of
the entire product.

Disadvantages of Software Metrics:

1. It is expensive and difficult to implement the metrics in some cases.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 33

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

2. Performance of the entire team or an individual from the team can’t be

determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measuring unwanted data which is a waste of time.
5. Measuring the incorrect data leads to wrong decision making.

Software Project Estimations:

Software project estimation approaches assist project managers in effectively

estimating critical project parameters such as cost and scope. PMs can then use
these estimation strategies to give clients more accurate projections as well as
budget the funds and resources they’ll require for a project’s success.

Project estimation is a complex process that revolves around predicting the

time, cost, and scope that a project requires to be deemed finished. But in terms
of software development or software engineering, it also takes the experience of
the software outsourcing company, the technique they have to utilize, the
process they need to follow in order to finish the project (Software
Development Life Cycle). Project Estimation requires the use of complex tools
& good mathematics as well as knowledge about planning.
In most cases, the whole estimation process would cost the company
considerable cost & time at the very first stage of developing a brand new
website, app, or software. However, this will act as the stepping stone to make
the final result more credible, realistic, and customer-satisfying.
Whether big or small, every project is advised to employ project estimation as a
crucial step to avoid unpredictable failure in the future.
Cost:
In project management, cost is one of the three primary constraints. The project
will fail if you do not have sufficient funds to complete it. You can help set
client expectations and ensure you have enough money to complete the work if
you can accurately estimate project costs early on. Estimating costs entails
determining how much money you’ll need and when you’ll need it.
Time

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 34

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Another of the project’s three main constraints is the lack of time. It is critical
for project planning to be able to estimate both the overall project duration and
the timing of individual tasks.
You can plan for people and resources to be available when you need them if
you estimate your project schedule ahead of time. It also enables you to manage
client expectations for key deliverables.
Size Or Scope
The third major project constraint is scope. The project scope refers to all of the
tasks that must be completed in order to complete the project or deliver a
product. You can ensure that you have the right materials and expertise on the
project by estimating how much work is involved and exactly what tasks must
be completed.
Three sides of a triangle are often used to describe the three main constraints.
This is because any changes to one constraint will inevitably have an effect on
the other two. You need to know the scope and schedule to accurately estimate
the budget. If one of the three estimates turns out to be higher or lower than you
anticipated, the other two are likely to be off as well.
Risk
Any unforeseen event that could positively or negatively impact your project is
referred to as project risk. Estimating risk entails predicting what events will
occur during the project’s life cycle and how serious they will be.
You can better plan for potential issues and create risk management plans if you
estimate what risks could affect your project and how they will affect it.
Resources
The assets you’ll need to complete the project are known as project resources.
Tools, people, materials, subcontractors, software, and other resources are all
examples of resources. Resource management ensures that you have all of the
resources you require and make the best use of them.
It’s challenging to plan how you’ll manage resources without knowing what
you’ll need and when. This can result in people sitting around doing nothing or
materials arriving weeks after you need them.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 35

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Quality
Quality is concerned with the completion of project deliverables. Products that
must adhere to stringent quality standards, such as environmental regulations,
may require more money, time, and other resources than those with lower
standards.
Estimating the level of quality required by the customer aids in the planning and
estimating the remaining five aspects of your project. Because all six project
factors are interconnected, forecasts for one can have an impact on forecasts for
the other five.
As a result, applying the same software project estimation techniques to all six
areas can help you improve your accuracy.

Software Project Planning (MS Project Tool)

A Software Project is the complete methodology of programming advancement

from requirement gathering to testing and support, completed by the execution
procedures, in a specified period to achieve the intended software product.

Need of Software Project Management

Software development is a sort of all new stream in world business, and there's
next to no involvement in structure programming items. Most programming
items are customized to accommodate customer's necessities. The most
significant is that the underlying technology changes and advances so generally
and rapidly that experience of one element may not be connected to the other
one. All such business and ecological imperatives bring risk in software
development; hence, it is fundamental to manage software projects efficiently.

Software Project Manager

Software manager is responsible for planning and scheduling project

development. They manage the work to ensure that it is completed to the
required standard. They monitor the progress to check that the event is on time
and within budget. The project planning must incorporate the major issues like

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 36

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

size & cost estimation scheduling, project monitoring, personnel selection

evaluation & risk management. To plan a successful software project, we must
understand:

○ Scope of work to be completed

○ Risk analysis

○ The resources mandatory

○ The project to be accomplished

○ Record of being followed

Software Project planning starts before technical work starts. The various steps
of planning activities are:

The size is the crucial parameter for the estimation of other activities. Resources
requirements are required based on cost and development time. Project schedule
may prove to be very useful for controlling and monitoring the progress of the
project. This is dependent on resources & development time.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 37

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Project Scheduling & Tracking:

Project Planning is an important activity performed by Project Managers.

Project Managers can use the tools and techniques to develop, monitor, and
control project timelines and schedules. The tracking tools can automatically
produce a pictorial representation of the project plan. These tools also instantly
update time plans as soon as new information is entered and produce automatic
reports to control the project. Scheduling tools also look into Task breakdown
and Risk management also with greater accuracy and ease of monitoring the
reports. It also provides a good GUI to effectively communicate with the
stakeholders of the project.

Features of Project Scheduling Tools

● Time management: The project scheduling tools keep projects running

the way it is planned. There will be proper time management and
better scheduling of the tasks.
● Resource allocation: It provides the resources required for project
development. There will be proper resource allocation and it helps to
make sure that proper permissions are given to different individuals
involved in the project. It helps to monitor and control all resources in
the project.
● Team collaboration: The project scheduling tool improves team
collaboration and communication. It helps to make it easy to comment
and chat within the platform without relying on external software.
● User-friendly interface: Good project scheduling tools are designed to
be more user-friendly to enable teams to complete projects in a better
and more efficient way.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 38

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Benefits of Project Scheduling Tools

● Defines work tasks: The project scheduling tool defines the work tasks
of a project.
● Time and resource management: It helps to keep the project on track
with respect to the time and plan.
● Cost management: It helps in determining the cost of the project.
● Improved projectivity: It enables greater productivity in teams as it
helps in smarter planning, better scheduling, and better task
delegation.
● Increased efficiency: The project scheduling tool increases speed and
efficiency in project development.

Criteria for Selecting Project Scheduling Tools

● Capability to handle multiple projects: The scheduling tool must

handle multiple projects at a time.
● User-friendly: It should be easy to use and must have a user-friendly
interface.
● Budget friendly: The tool should be of low cost and should be within
the development budget.
● Security features: The tool must be secured and risk-free from
vulnerable threats.

Top 10 Project Scheduling Tools

1. Microsoft Project

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 39

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

2. Daily Activity Reporting and Tracking (DART)

3. [Link]
4. [Link]
5. SmartTask
6. ProofHub
7. Asana
8. Wrike
9. GanttPRO
10. Zoho Projects

Risk Analysis & Management (Risk Identification, Risk Projection. Risk

Refinement , Risk Mitigation).

A risk is a probable problem; it might happen, or it might not. There are two
main characteristics of risk.

Uncertainty: the risk may or may not happen which means there are no 100%
risks.

Loss: If the risk occurs in reality, undesirable results or losses will occur.

Risk Management is a systematic process of recognizing, evaluating, and

handling threats or risks that have an effect on the finances, capital, and overall
operations of an organization. These risks can come from different areas, such
as financial instability, legal issues, errors in strategic planning, accidents, and
natural disasters.

Why is risk management important?

Risk management is important because it helps organizations to prepare for
unexpected circumstances that can vary from small issues to major crises. By
actively understanding, evaluating, and planning for potential risks,
organizations can protect their financial health, continued operation, and overall
survival.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 40

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Let’s Understand why risk management is important with an example.

Suppose In a software development project, one of the key developers
unexpectedly falls ill and is unable to contribute to the product for an extended
period.
One of the solutions that organizations may have , The team uses collaborative
tools and procedures, such as shared work boards or project management
software, to make sure that each member of the team is aware of all tasks and
responsibilities, including those of their teammates.
An organization must focus on providing resources to minimize the negative
effects of possible events and maximize positive results in order to reduce risk
effectively. Organizations can more effectively identify, assess, and mitigate
major risks by implementing a consistent, systematic, and integrated approach
to risk management.
The risk management process
Risk management is a sequence of steps that help a software team to
understand, analyze, and manage uncertainty. Risk management process
consists of
● Risk Identification.
● Risk Assessment.
● Risk Planning.
● Risk Monitoring

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 41

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Risk Identification
Risk identification refers to the systematic process of recognizing and
evaluating potential threats or hazards that could negatively impact an
organization, its operations, or its workforce. This involves identifying various
types of risks, ranging from IT security threats like viruses and phishing attacks
to unforeseen events such as equipment failures and extreme weather
conditions.
Risk analysis
Risk analysis is the process of evaluating and understanding the potential impact
and likelihood of identified risks on an organization. It helps determine how
serious a risk is and how to best manage or mitigate it. Risk Analysis involves
evaluating each risk’s probability and potential consequences to prioritize and
manage them effectively.
Risk Planning

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 42

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Risk planning involves developing strategies and actions to manage and

mitigate identified risks effectively. It outlines how to respond to potential risks,
including prevention, mitigation, and contingency measures, to protect the
organization’s objectives and assets.
Risk Monitoring
Risk monitoring involves continuously tracking and overseeing identified risks
to assess their status, changes, and effectiveness of mitigation strategies. It
ensures that risks are regularly reviewed and managed to maintain alignment
with organizational objectives and adapt to new developments or challenges.
Understanding Risks in Software Projects
A computer code project may be laid low with an outsized sort of risk. To be
ready to consistently establish the necessary risks that could affect a computer
code project, it’s necessary to group risks into completely different categories.
The project manager will then examine the risks from every category square
measure relevant to the project.
There are mainly 3 classes of risks that may affect a computer code project:
● Project Risks:
Project risks concern various sorts of monetary funds, schedules,
personnel, resources, and customer-related issues. A vital project risk is
schedule slippage. Since computer code is intangible, it’s tough to
observe and manage a computer code project. It’s tough to manage one
thing that can not be seen. For any producing project, like producing cars,
the project manager will see the merchandise taking form.
For example, see that the engine is fitted, at the moment the area of the
door unit is fitted, the automotive is being painted, etc. so he will simply
assess the progress of the work and manage it. The physical property of
the merchandise being developed is a vital reason why several computer
codes come to suffer from the danger of schedule slippage.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 43

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

● Technical Risks:
Technical risks concern potential style, implementation, interfacing,
testing, and maintenance issues. Technical risks conjointly embody
ambiguous specifications, incomplete specifications, dynamic
specifications, technical uncertainty, and technical degeneration. Most
technical risks occur thanks to the event team’s lean information
concerning the project.
● Business Risks:
This type of risk embodies the risks of building a superb product that
nobody needs, losing monetary funds or personal commitments, etc.

Classification of Risk in a project

Example: Let us consider a satellite-based mobile communication project. The

project manager can identify many risks in this project. Let us classify them
appropriately.
● What if the project cost escalates and overshoots what was estimated?
– Project Risk
● What if the mobile phones that are developed become too bulky to
conveniently carry? Business Risk
● What if the call hand-off between satellites becomes too difficult to
implement? Technical Risk

Risk management standards and frameworks

Risk management standards and frameworks give organizations guidelines on

how to find, evaluate, and handle risks effectively. They provide a structured
way to manage risks, making sure that everyone follows consistent and reliable

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 44

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

practices. Here are some well-known risk management standards and

frameworks:
1. COSO ERM Framework:
COSO ERM Framework was introduced in 2004 and updated in 2017. Its
main purpose is to address the growing complexity of Enterprise Risk
Management (ERM).
● Key Features:
○ 20 principles grouped into five components:
Governance and culture, Strategy and
objective-setting, Performance, Review and revision,
Information, communication, and reporting.
○ It promotes integrating risk into business strategies
and operations.

2. ISO 31000:
ISO 31000 was introduced in 2009, revised in 2018. It provides principles and a
framework for ERM.
Key Features:

○ It offers guidance on applying risk management to operations.

○ It focuses on identifying, evaluating, and mitigating risks.
○ It promotes senior management’s role and integrates risk
management across the organization.

3. BS 31100:
This framework is the British Standard for Risk Management and the latest
version issued in 2001. It offers a structured approach to applying the principles

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 45

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

outlined in ISO 31000:2018, covering tasks like identifying, evaluating, and

addressing risks, followed by reporting and reviewing risk management efforts.
Benefits of risk management

Here are some benefits of risk management:

● Helps protect against potential losses.
● Improves decision-making by considering risks.
● Reduces unexpected expenses.
● Ensures adherence to laws and regulations.
● Builds resilience against unexpected challenges.
● Safeguards company reputation.

Limitation of Risk Management

Here are Some Limitation of Risk Management

● Too much focus on risk can lead to missed opportunities.
● Implementing risk management can be expensive.
● Risk models can be overly complex and hard to understand.
● Having risk controls might make people feel too safe.
● Relies on accurate human judgment and can be prone to mistakes.
● Some risks are hard to predict or quantify.
● Managing risks can take a lot of time and resources.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 46

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Unit 4: Requirement Analysis and Specification

Understanding the Requirement:

What is a 'Requirement'? I believe anything that is a necessity and is

essential for a certain event to take place is a requirement. In the world of
business, it can be a condition that needs to be fulfilled to solve a
business problem or respond to a specific business need.

Requirement analysis is hard:

It's the process of determining user expectations for a new or modified

product. These expectations include functional requirements (what the
software should do) and non-functional requirements (how the software

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 47

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

should perform). In simpler terms, Requirements Analysis is like being a

detective in the software world.

Requirement Engineering:

A systematic and strict approach to the definition, creation, and

verification of requirements for a software system is known as
requirements engineering. To guarantee the effective creation of a
software product, the requirements engineering process entails several
tasks that help in understanding, recording, and managing the demands of
stakeholders.

Requirement Modeling:

Requirements Modeling is a process of documenting, analyzing, and

managing Requirements. Requirements change throughout the project, so
it is important to have a way to track them and make sure everyone
understands them. There are many tools and courses available to help you
with Requirements Modeling. In this article, we will discuss what
Requirements Modeling is, the different processes and tools involved in
Requirements Modeling, as well as some courses that can help you learn
more about Requirements Modeling.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 48

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Requirement Specification (SRS):

The production of the requirements stage of the software

development process is Software Requirements Specifications (SRS)
(also called a requirements document). This report lays a foundation for
software engineering activities and is constructed when entire
requirements are elicited and analyzed. SRS is a formal report, which acts
as a representation of software that enables the customers to review
whether it (SRS) is according to their requirements. Also, it comprises
user requirements for a system as well as detailed specifications of the
system requirements.

The SRS is a specification for a specific software product,

program, or set of applications that perform particular functions in a
specific environment. It serves several goals depending on who is writing
it. First, the SRS could be written by the client of a system. Second, the
SRS could be written by a developer of the system. The two methods
create entirely various situations and establish different purposes for the
document altogether. The first case, SRS, is used to define the needs and
expectations of the users. The second case, SRS, is written for various
purposes and serves as a contract document between customer and
developer.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 49

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements

stated in the SRS. SRS is said to be perfect if it covers all the needs that are
truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality, performance,

design, constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input
data in all available categories of situations.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 50

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict
in the SRS:

(1). The specified characteristics of real-world objects may conflict. For

example,

(a) The format of an output report may be described in one requirement as

tabular but in another as textual.

(b) One condition may state that all lights shall be green while another states
that all lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified
actions. For example,

(a) One requirement may determine that the program will add two inputs, and
another may determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while another
requires that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user input
may be called a "prompt" in one requirement and a "cue" in another. The use of
standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has

only one interpretation. This suggests that each element is uniquely interpreted.
In case there is a method used with multiple definitions, the requirements report
should determine the implications in the SRS so that it is clear and simple to
understand.

5. Ranking for importance and stability: The SRS is ranked for importance
and stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 51

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Typically, all requirements are not equally important. Some prerequisites may
be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear and
explicit. Another way to rank requirements is to distinguish classes of items as
essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be

capable of quickly obtaining changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified

with a cost-effective system to check whether the final software meets those
requirements. The requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is

clear and if it facilitates the referencing of each condition in future development
or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly
referencing its source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a
unique name or reference number.

The forward traceability of the SRS is especially crucial when the software
product enters the operation and maintenance phase. As code and design
documents are modified, it is necessary to be able to ascertain the complete set
of requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple

design alternatives for the final system. More specifically, the SRS should not
contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to

generate test cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her

explicit domain but might not be trained in computer science. Hence, the

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 52

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

purpose of formal notations and symbols should be avoided to as much extent as

possible. The language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements
stage, the details should be explained explicitly. Whereas,for a feasibility study,
fewer analyses can be used. Hence, the level of abstraction modifies according
to the objective of the SRS.

Properties of a good SRS document:

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease
readability and also increase error possibilities.

Structured: It should be well-structured. A well-structured document is simple

to understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the user requirements. Often, user requirements evolve
over a period of time. Therefore, to make the modifications to the SRS
document easy, it is vital to make the report well-structured.

Black-box view: It should only define what the system should do and refrain
from stating how to do these. This means that the SRS document should define
the external behavior of the system and not discuss the implementation issues.
The SRS report should view the system to be developed as a black box and
should define the externally visible behavior of the system. For this reason, the
SRS report is also known as the black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the reader can
merely understand it. Response to undesired events: It should characterize
acceptable responses to unwanted events. These are called system responses to
exceptional conditions.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 53

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Requirement Analysis and Requirement Elicitation:

Requirement analysis is a significant and essential activity after

elicitation. We analyze, refine, and scrutinize the gathered requirements
to make consistent and unambiguous requirements. This activity reviews
all requirements and may provide a graphical view of the entire system.
After the completion of the analysis, it is expected that the
understandability of the project may improve significantly. Here, we may
also use the interaction with the customer to clarify points of confusion
and to understand which requirements are more important than others.

(i) Draw the context diagram: The context diagram is a simple model
that defines the boundaries and interfaces of the proposed systems with
the external world. It identifies the entities outside the proposed system
that interact with the system. The context diagram of student result
management system is given below:

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 54

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

(ii) Development of a Prototype (optional): One effective way to find out

what the customer wants is to construct a prototype, something that looks and
preferably acts as part of the system they say they want.

We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed
system and increase the understanding of the requirements. When developers
and users are not sure about some of the elements, a prototype may help both
the parties to take a final decision.

Some projects are developed for the general market. In such cases, the prototype
should be shown to some representative sample of the population of potential
purchasers. Even though a person who tries out a prototype may not buy the
final system, their feedback may allow us to make the product more attractive to
others.

The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This is
an optional activity.

(iii) Model the requirements: This process usually consists of various

graphical representations of the functions, data entities, external entities, and the
relationships between them. The graphical view may help to find incorrect,

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 55

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

inconsistent, missing, and superfluous requirements. Such models include the

Data Flow diagram, Entity-Relationship diagram, Data Dictionaries,
State-transition diagrams, etc.

(iv) Finalize the requirements: After modeling the requirements, we will have
a better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyzing activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.

Requirement Engineering:

Requirements engineering (RE) refers to the process of defining, documenting,

and maintaining requirements in the engineering design process.

Requirement engineering provides the appropriate mechanism to understand

what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the
specifications and managing the requirements as they are transformed into a
working system. Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 56

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current

technologies, which are needed to accomplish customer requirements
within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 57

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

3. Economic Feasibility - Economic feasibility decides whether the

necessary software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are

identified with the help of customers and existing systems processes, if
available.

Analysis of requirements starts with requirement elicitation. The requirements

are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

○ Getting all, and only, the right people involved.

○ Stakeholders often don't know what they want
○ Stakeholders express requirements in their terms.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 58

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

○ Stakeholders may have conflicting requirements.

○ Requirement change during the analysis process.
○ Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a

software analyst after the requirements collected from the various sources - the
requirement received by the customer written in ordinary language. It is the job
of the analyst to write the requirements in technical language so that they can be
understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.

○ Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a
system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
○ Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements
stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and
terminologies.
○ Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.

4. Software Requirement Validation:

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 59

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

After requirement specifications are developed, the requirements discussed in

this document are validated. The user might demand an illegal, impossible
solution or experts may misinterpret the needs. Requirements can be the check
against the following conditions -

○ If they can practically implement

○ If they are correct and as per the functionality and specially of software
○ If there are any ambiguities
○ If they are full
○ If they can describe

Requirements Validation Techniques

○ Requirements reviews/inspections: systematic manual analysis of the

requirements.
○ Prototyping: Using an executable model of the system to check
requirements.
○ Test-case generation: Developing tests for requirements to check
testability.
○ Automated consistency analysis: checking for the consistency of
structured requirements descriptions.

Software Requirement Management:

● Requirement management is the process of managing changing

requirements during the requirements engineering process and system
development.
● New requirements emerge during the process as business needs a change,
and a better understanding of the system is developed.
● The priority of requirements from different viewpoints changes during the
development process.
● The business and technical environment of the system changes during the
development.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 60

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Software Requirements: Largely software requirements must be categorized

into two categories:

1. Functional Requirements: Functional requirements define a function

that a system or system element must be qualified to perform and must be
documented in different forms. The functional requirements are
describing the behavior of the system as it correlates to the system's
functionality.
2. Non-functional Requirements: These can be the necessities that specify
the criteria that can be used to decide the operation instead of specific
behaviors of the system.
Non-functional requirements are divided into two main categories:
○ Execution qualities like security and usability, which are
observable at run time.
○ Evolution qualities like testability, maintainability, extensibility,
and scalability that are embodied in the static structure of the
software system.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 61

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

Unit 5: Software Design

Design Concepts and Design Principal:

Software Design is also a process to plan or convert the software requirements

into a step that is needed to be carried out to develop a software system. There
are several principles that are used to organize and arrange the structural
components of Software design. Software Designs in which these principles are
applied affect the content and the working process of the software from the
beginning.

Principles of Software Design :

1. Should not suffer from “Tunnel Vision” –
While designing the process, it should not suffer from “tunnel vision”
which means that it should not only focus on completing or achieving
the aim but on other effects also.
2. Traceable to analysis model –
The design process should be traceable to the analysis model which

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 62

 Shri Labhubhai Trivedi Institute of Engineering &Technology - SLTIET
Department of CSE - Degree 5th sem.
Software Engineering - 3150711

means it should satisfy all the requirements that software requires to

develop a high-quality product.
3. Should not “Reinvent The Wheel” –
The design process should not reinvent the wheel, that means it should
not waste time or effort in creating things that already exist. Due to
this, the overall development will increase.
4. Minimize Intellectual distance –
The design process should reduce the gap between real-world
problems and software solutions for that problem meaning it should
simply minimize intellectual distance.
5. Exhibit uniformity and integration –
The design should display uniformity which means it should be
uniform throughout the process without any change. Integration means
it should mix or combine all parts of software i.e. subsystems into one
system.
6. Accommodate change –
The software should be designed in such a way that it accommodates
the change implying that the software should adjust to the change that
is required to be done as per the user’s need.
7. Degrade gently –
The software should be designed in such a way that it degrades
gracefully which means it should work properly even if an error
occurs during the execution.
8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning
that during the evaluation, the quality of the design needs to be
checked and focused on.
9. Review to discover errors –
The design should be reviewed which means that the overall
evaluation should be done to check if there is any error present or if it
can be minimized.
10. Design is not coding and coding is not design –
Design means describing the logic of the program to solve any
problem and coding is a type of language that is used for the
implementation of a design.

Prof. Paresh Chavda, CSE-SLTIET, Rajkot Page 63