Unit - I

Unit -I SOFTWARE ENGINEERING Lecture Notes
Unit - I
INTRODUCTION
Software engineering concepts – Development activities – Software lifecycle models - Classical

waterfall – Iterative waterfall – Prototyping – Evolutionary - Spiral – Software project
management – Project planning – Estimation –Scheduling–Risk management–Software
configuration management.
1.1 Software engineering concepts
The term software engineering is the product of two words, software, and engineering.
Software is a program or set of programs containing instructions that provide desired

functionality. and Engineering is the process of designing and building something that serves a
particular purpose and finds a cost-effective solution to problems.
Software engineering is the process of designing, developing, testing, and maintaining

software. It is a systematic and disciplined approach to software development that aims to create
high-quality, reliable, and maintainable software. Software engineering includes a variety of
techniques, tools, and methodologies, including requirements analysis, design, testing, and
maintenance.
Key principles of software engineering include:
1. Modularity: Breaking the software into smaller, reusable components that can be
developed and tested independently.
2. Abstraction: Hiding the implementation details of a component and exposing only the
necessary functionality to other parts of the software.
3. Encapsulation: Wrapping up the data and functions of an object into a single unit, and
protecting the internal state of an object from external modifications.
4. Reusability: Creating components that can be used in multiple projects, which can save
time and resources.
5. Maintenance: Regularly updating and improving the software to fix bugs, add new
features, and address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is free of bugs.
7. Design Patterns: Solving recurring problems in software design by providing templates
for solving them.
8. Agile methodologies: Using iterative and incremental development processes that focus on
customer satisfaction, rapid delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating the code changes and
deploying them into the production environment.
Software engineering is a rapidly evolving field, and new tools and technologies are constantly
being developed to improve the software development process. By following the principles of
software engineering and using the appropriate tools and methodologies, software developers
can create high-quality, reliable, and maintainable software that meets the needs of its users.
1
Software Engineering is mainly used for large projects based on software systems rather than
single programs or applications. The main goal of software Engineering is to develop software
application for improving the quality, budget and time efficiency. Software Engineering
ensures that the software that has to build should be consistent, correct, also on budget, on time
and within the required requirements. There are Four Main Attributes of Software
Engineering: -
 Efficiency
 Reliability
 Robustness
 Maintainability
Objectives / Characteristics of Software Engineering:
1. Maintainability
It should be feasible for the software to evolve to meet changing requirements.
2. Efficiency
The software should not make wasteful use of computing devices such as memory,
processor cycles, etc.
3. Correctness
A software product is correct if the different requirements as specified in the SRS
document have been correctly implemented.
4. Reusability
A software product has good reusability if the different modules of the product can easily
be reused to develop new products.
5. Testability
Here software facilitates both the establishment of test criteria and the evaluation of the
software with respect to those criteria.
6. Reliability
It is an attribute of software quality. The extent to which a program can be expected to
perform its desired function, over an arbitrary time period.
7. Portability
In this case, the software can be transferred from one computer system or environment to
another.
8. Adaptability
In this case, the software allows differing system constraints and the user needs to be
satisfied by making changes to the software.
9. Interoperability – Capability of 2 or more functional units to process data cooperatively.
1.1.1 Layers of Software Development

1. Quality Focus
2. Process
3. Methods
4. Tools
2
A Quality Focus
Software engineering must rest on an organizational commitment to quality. Total quality
management and similar philosophies foster a continuous process improvement culture, and this
culture ultimately leads to the development of increasingly more mature approaches to software
engineering. The bedrock that supports software engineering is a quality focus.
Process
The foundation for software engineering is the process layer. Process defines a framework for a
set of Key Process Areas (KPAs) that must be established for effective delivery of software
engineering technology. Consequently, this establishes the context in which technical methods
are applied, work products such as models, documents, data, reports, forms, etc. are produced,
milestones are established, quality is ensured, and change is properly managed.
Methods
Software engineering methods provide the technical how-to’s for building software. Methods
will include requirements analysis, design, program construction, testing, and support. This
relies on a set of basic principles that govern each area of the technology and include modeling
activities and other descriptive techniques.
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.
1.1.2 Generic view of Process :
Framework is a Standard way to build and deploy applications.
Software Process Framework is the foundation of complete software engineering process.
Software process framework includes set of all umbrella activities. It also includes number of
framework activities that are applicable to all software projects.
3
A generic process framework encompasses five activities which are given below one by one:
1. Communication:
In this activity, heavy communication with customers and other stakeholders, as well as
requirement gathering is done.
2. Planning:
In this activity, we discuss the technical related tasks, work schedule, risks, required
resources, etc.
3. Modeling:
Modeling is about building representations of things in the ‘real world’. In modeling
activity, a product’s model is created in order to better understand the requirements.
4. Construction:
In software engineering, construction is the application of set of procedures that are
needed to assemble the product. In this activity, we generate the code and test the
product in order to make better product.
5. Deployment:
In this activity, a complete or non-complete product or software is represented to the
customers to evaluate and give feedback. On the basis of their feedback, we modify the
product for supply of better product.
Umbrella activities include:
 Risk Management
 Software Quality Assurance (SQA)
 Software Configuration Management (SCM)
 Measurement
 Formal Technical Reviews (FTR)
1.2 Software Processes
The term software specifies to the set of computer programs, procedures and associated

documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used.
4
A software process is the set of activities and associated outcome that produce a software
product. Software engineers mostly carry out these activities. These are four key process
activities, which are common to all software processes. These activities are:
1. Software specifications: The functionality of the software and constraints on its

operation must be defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what the
customer wants.
4. Software evolution: The software must evolve to meet changing client needs.
The Software Process Model
A software process model is a specified definition of a software process, which is presented from
a particular perspective. Models, by their nature, are a simplification, so a software process
model is an abstraction of the actual process, which is being described. Process models may
contain activities, which are part of the software process, software product, and the roles of
people involved in software engineering. Some examples of the types of software process
models that may be produced are:
1. A workflow model: This shows the series of activities in the process along with their
inputs, outputs and dependencies. The activities in this model perform human actions.
2. 2. A dataflow or activity model: This represents the process as a set of activities, each
of which carries out some data transformations. It shows how the input to the process,
such as a specification is converted to an output such as a design. The activities here may
be at a lower level than activities in a workflow model. They may perform
transformations carried out by people or by computers.
3. 3. A role/action model: This means the roles of the people involved in the software
process and the activities for which they are responsible.
There are several various general models or paradigms of software development:
1. The waterfall approach: This takes the above activities and produces them as separate
process phases such as requirements specification, software design, implementation,
testing, and so on. After each stage is defined, it is "signed off" and development goes
onto the following stage.
2. Evolutionary development: This method interleaves the activities of specification,
development, and validation. An initial system is rapidly developed from a very abstract
specification.
5
3. Formal transformation: This method is based on producing a formal mathematical

system specification and transforming this specification, using mathematical methods to
a program. These transformations are 'correctness preserving.' This means that you can
be sure that the developed programs meet its specification.
4. System assembly from reusable components: This method assumes the parts of the
system already exist. The system development process target on integrating these parts
rather than developing them from scratch.
Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the consumer
product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products defects
after putting into use due to ineffective testing technique. For example, Software testing
typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop and the
money involved. For example, Development of the FAA's Advanced Automation System
cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the software takes
longer than the estimated time to develop, which in turn leads to cost shooting up. For
example, one in four large-scale development projects is never completed.
Program vs. Software
Software is more than programs. Any program is a subset of software, and it becomes software
only if documentation & operating procedures manuals are prepared.
There are three components of the software as shown in fig:
6
1. Program: Program is a combination of source code & object code.
2. Documentation: Documentation consists of different types of manuals. Examples of

documentation manuals are: Data Flow Diagram, Flow Charts, ER diagrams, etc.
4. Operating Procedures: Operating Procedures consist of instructions to set up and use

the software system and instructions on how react to the system failure. Example of
operating system procedures manuals is: installation guide, Beginner's guide, reference
guide, system administration guide, etc.
7
1.3 Software Development Life Cycle (SDLC)
A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods required
to make a software product transit through its life cycle stages. It also captures the structure in
which these methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on a software product
from its inception to retirement. Different life cycle models may plan the necessary development
activities to phases in different ways. Thus, no element which life cycle model is followed, the
essential activities are contained in all life cycle models though the action may be carried out in
distinct orders in different life cycle models. During any life cycle stage, more than one activity
may also be carried out.
Need of SDLC
The development team must determine a suitable life cycle model for a particular plan and then
observe to it.
Without using an exact life cycle model, the development of a software product would not be in
a systematic and disciplined manner. When a team is developing a software product, there must
be a clear understanding among team representative about when and what to do. Otherwise, it
would point to chaos and project failure. This problem can be defined by using an example.
Suppose a software development issue is divided into various parts and the parts are assigned to
the team members. From then on, suppose the team representative is allowed the freedom to
develop the roles assigned to them in whatever way they like. It is possible that one
representative might start writing the code for his part, another might choose to prepare the test
documents first, and some other engineer might begin with the design phase of the roles assigned
to him. This would be one of the perfect methods for project failure.
A software life cycle model describes entry and exit criteria for each phase. A phase can begin
only if its stage-entry criteria have been fulfilled. So without a software life cycle model, the
8
entry and exit criteria for a stage cannot be recognized. Without software life cycle models, it
becomes tough for software project managers to monitor the progress of the project.
Proper planning and execution are the key components of a successful software development
process. The entire software development process includes 6 stages. Software Development Life
Cycle (SDLC) is the common term to summarize these 6 stages.
SDLC specifies the task(s) to be performed at various stages by a software engineer/developer. It
ensures that the end product is able to meet the customer’s expectations and fits in the overall
budget. Hence, it’s vital for a software developer to have prior knowledge of this software
development process.
These 6 stages are discussed below.
 Stage-1: Planning And Requirement Analysis:

Planning is the crucial step in everything and so as in software development. In this same
stage, requirement analysis is also performed by the developers of the organization. This is
attained from the inputs from the customers, sales department/market surveys.
The information from this analysis forms the building block of a basic project. The quality
proof of the project is a result of planning. Thus, in this stage, the basic project is designed
with all the available information.

 Stage-2: Defining Requirements:

In this stage, all the requirements for the target software are specified. These requirements
get approval from the customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification) . This is a sort of
9
document that specifies all those things that need to be defined and created during the
entire project cycle.

 Stage-3: Designing Architecture:
SRS is a reference for software designers to come out with the best architecture for the
software. Hence, with the requirements defined in SRS, multiple designs for the product
architecture are present in the Design Document Specification (DDS).
This DDS is assessed by market analysts and stakeholders. After evaluating all the possible
factors, the most practical and logical design is chosen for the development.

 Stage-4: Developing Product:
At this stage, the fundamental development of the product starts. For this, developers use a
specific programming code as per the design in the DDS. Hence, it is important for the
coders to follow the protocols set by the association. Conventional programming tools like
compilers, interpreters, debuggers, etc. are also put into use at this stage. Some popular
languages like C/C++, Python, Java, etc. are put into use as per the software regulations.

 Stage-5: Product Testing and Integration:
After the development of the product, testing of the software is necessary to ensure its
smooth execution. Although, minimal testing is conducted at every stage of SDLC.
Therefore, at this stage, all the probable flaws are tracked, fixed, and retested. This ensures
that the product confronts the quality requirements of SRS.

 Documentation, Training and support:

Software documentation is an essential part of the software
development life cycle. A well-written document acts as a tool and means to information
repository necessary to know about software processes, functions and maintenance.
Documentation also provides information about how to use the product. Thoroughly-
written documentation should involve the required documentation. Software architecture
documentation, technical documentation and user documentation. Training in an attempt
to improve the current or future employee performance by increasing an employee’s ability
to work through learning, usually by changing his attitude and developing his skills and
10
understanding.

 Stage 6: Deployment and Maintenance Of Product:
After detailed testing, the conclusive product is released in phases as per the organization’s
strategy. Then it is tested in a real industrial environment. Because it is important to ensure
its smooth performance. If it performs well, the organization sends out the product as a
whole. After retrieving beneficial feedback, the company releases it as it is or with
auxiliary improvements to make it further helpful for the customers. However, this alone is
not enough. Therefore, along with the deployment, the product’s supervision.
1.3.1 SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management that
defines the stages include in an information system development project, from an initial
feasibility study to the maintenance of the completed application.
There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique to its type
to ensure success in the step of software development.
Here, are some important phases of SDLC life cycle:
11
1.3.1.1 Classical waterfall
The classical waterfall model is the basic software development life cycle model. It is very
simple but idealistic. Earlier this model was very popular but nowadays it is not used. But it is
very important because all the other software development life cycle models are based on the
classical waterfall model.
Use of Waterfall Model:

The waterfall model is a software development model used in the context of large, complex
projects, typically in the field of information technology. It is characterized by a structured,
sequential approach to project management and software development.
The waterfall model is useful in situations where the project requirements are well-defined and
the project goals are clear. It is often used for large-scale projects with long timelines, where
there is little room for error and the project stakeholders need to have a high level of
confidence in the outcome.
Features of the Waterfall Model

1. Sequential Approach: The waterfall model involves a sequential approach to software
development, where each phase of the project is completed before moving on to the next
one.
2. Document-Driven: The waterfall model relies heavily on documentation to ensure that the
project is well-defined and the project team is working towards a clear set of goals.
3. Quality Control: The waterfall model places a high emphasis on quality control and
testing at each phase of the project, to ensure that the final product meets the requirements
and expectations of the stakeholders.
4. Rigorous Planning: The waterfall model involves a rigorous planning process, where the
project scope, timelines, and deliverables are carefully defined and monitored throughout
the project lifecycle.
Overall, the waterfall model is used in situations where there is a need for a highly structured
and systematic approach to software development. It can be effective in ensuring that large,
complex projects are completed on time and within budget, with a high level of quality and
customer satisfaction.
12
Phases of Classical Waterfall Model:

Waterfall Model is a classical software development methodology that was first introduced by
Winston W. Royce in 1970. It is a linear and sequential approach to software development that
consists of several phases that must be completed in a specific order. The phases include:
1. Requirements Gathering and Analysis: The first phase involves gathering requirements

from stakeholders and analyzing them to understand the scope and objectives of the
project.
2. Design: Once the requirements are understood, the design phase begins. This involves
creating a detailed design document that outlines the software architecture, user interface,
and system components.
3. Implementation: The implementation phase involves coding the software based on the
design specifications. This phase also includes unit testing to ensure that each component
of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves
fixing any issues that arise after the software has been deployed and ensuring that it
continues to meet the requirements over time.
The classical waterfall model divides the life cycle into a set of phases. This model considers
that one phase can be started after the completion of the previous phase. That is the output of
one phase will be the input to the next phase. Thus the development process can be considered
as a sequential flow in the waterfall. Here the phases do not overlap with each other. The
different sequential phases of the classical waterfall model are shown in the below figure.
13
Let us now learn about each of these phases in detail.
1. Feasibility Study
 The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software.
 The feasibility study involves understanding the problem and then determining the various
possible strategies to solve the problem. These different identified solutions are analyzed
based on their benefits and drawbacks, The best solution is chosen and all the other phases
are carried out as per this solution strategy.
2. Requirements Analysis and Specification

The aim of the requirement analysis and specification phase is to understand the exact
requirements of the customer and document them properly. This phase consists of two
different activities.
 Requirement gathering and analysis: Firstly all the requirements regarding the software
are gathered from the customer and then the gathered requirements are analyzed. The goal
of the analysis part is to remove incompleteness (an incomplete requirement is one in
which some parts of the actual requirements have been omitted) and inconsistencies (an
inconsistent requirement is one in which some part of the requirement contradicts some
other part).
 Requirement specification: These analyzed requirements are documented in a software
requirement specification (SRS) document. SRS document serves as a contract between the
14
development team and customers. Any future dispute between the customers and the
developers can be settled by examining the SRS document.
3. Design
The goal of this phase is to convert the requirements acquired in the SRS into a format that can
be coded in a programming language. It includes high-level and detailed design as well as the
overall software architecture. A Software Design Document is used to document all of this
effort (SDD)
4. Coding and Unit Testing
In the coding phase software design is translated into source code using any suitable
programming language. Thus each designed module is coded. The aim of the unit testing phase
is to check whether each module is working properly or not.
5. Integration and System testing

Integration of different modules is undertaken soon after they have been coded and unit tested.
Integration of various modules is carried out incrementally over a number of steps. During
each integration step, previously planned modules are added to the partially integrated system
and the resultant system is tested. Finally, after all the modules have been successfully
integrated and tested, the full working system is obtained and system testing is carried out on
this.
System testing consists of three different kinds of testing activities as described below.
 Alpha testing: Alpha testing is the system testing performed by the development team.
 Beta testing: Beta testing is the system testing performed by a friendly set of customers.
 Acceptance testing: After the software has been delivered, the customer performed
acceptance testing to determine whether to accept the delivered software or reject it.
6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop a full software. There are basically
three types of maintenance.
 Corrective Maintenance: This type of maintenance is carried out to correct errors that

were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
15
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the software

to work in a new environment such as working on a new computer platform or with a new
operating system.
Advantages of the Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered the basis for other software development life cycle models.
Below are some of the major advantages of this SDLC model.
 Easy to Understand: Classical Waterfall Model is very simple and easy to understand.

 Individual Processing: Phases in the Classical Waterfall model are processed one at a
time.
 Properly Defined: In the classical waterfall model, each stage in the model is clearly
defined.
 Clear Milestones: Classical Waterfall model has very clear and well-understood
milestones.
 Properly Documented: Processes, actions, and results are very well documented.
 Reinforces Good Habits: Classical Waterfall Model reinforces good habits like define-
before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and projects where
requirements are well understood.
Disadvantages of the Classical Waterfall Model

The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it in
real projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model.
 No Feedback Path: In the classical waterfall model evolution of software from one phase
to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.
 Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customer’s requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.
16
 No Overlapping of Phases: This model recommends that a new phase can start only after
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase efficiency and reduce cost, phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software

development, which means that it is not well-suited for projects with changing or uncertain
requirements. Once a phase has been completed, it is difficult to make changes or go back
to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of the
project (requirements gathering and analysis) but may not be involved in the later
phases (implementation, testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done toward the end of
the development process. This means that defects may not be discovered until late in the
development process, which can be expensive and time-consuming to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex
projects, as the linear and sequential nature of the model can make it difficult to manage
multiple dependencies and interrelated components.
Applications of Classical Waterfall Model

 Large-scale Software Development Projects: The Waterfall Model is often used for
large-scale software development projects, where a structured and sequential approach is
necessary to ensure that the project is completed on time and within budget.
 Safety-Critical Systems: The Waterfall Model is often used in the development of safety-
critical systems, such as aerospace or medical systems, where the consequences of errors or
defects can be severe.
 Government and Defense Projects: The Waterfall Model is also commonly used in
government and defense projects, where a rigorous and structured approach is necessary to
ensure that the project meets all requirements and is delivered on time.
17
 Projects with well-defined Requirements: The Waterfall Model is best suited for projects
with well-defined requirements, as the sequential nature of the model requires a clear
understanding of the project objectives and scope.
 Projects with Stable Requirements: The Waterfall Model is also well-suited for projects
with stable requirements, as the linear nature of the model does not allow for changes to be
made once a phase has been completed.
1.3.1.2 Iterative waterfall
In a practical software development project, the classical waterfall model is hard to use. So,
the Iterative waterfall model can be thought of as incorporating the necessary changes to the
classical waterfall model to make it usable in practical software development projects. It is
almost the same as the classical waterfall model except some changes are made to increase the
efficiency of the software development.
The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
When errors are detected at some later phase, these feedback paths allow for correcting errors
committed by programmers during some phase. The feedback paths allow the phase to be
reworked in which errors are committed and these changes are reflected in the later phases.
18
But, there is no feedback path to the stage – feasibility study, because once a project has been
taken, does not give up the project easily.
It is good to detect errors in the same phase in which they are committed. It reduces the effort
and time required to correct the errors.
The Iterative Waterfall Model is a software development approach that combines the
sequential steps of the traditional Waterfall Model with the flexibility of iterative design. It
allows for improvements and changes to be made at each stage of the development process,
instead of waiting until the end of the project.
Real-life example: Iterative Waterfall Model could be building a new website for a small
business. The process might look like this:
Requirements gathering: This is the first stage where the business owners and developers
meet to discuss the goals and requirements of the website.
Design: In this stage, the developers create a preliminary design of the website based on the
requirements gathered in stage 1.
Implementation: In this stage, the developers begin to build the website based on the design
created in stage 2.
Testing: Once the website has been built, it is tested to ensure that it meets the requirements
and functions properly.
Deployment: The website is then deployed and made live to the public.
Review and improvement: After the website has been live for a while, the business owners
and developers review its performance and make any necessary improvements.
This process is repeated until the website meets the needs and goals of the business. Each
iteration builds upon the previous one, allowing for continuous improvement and iteration
until the final product is complete.
Phase Containment of Errors: The principle of detecting errors as close to their points of

commitment as possible is known as Phase containment of errors.
Collaboration: Throughout each stage of the process, there is collaboration between the
business owners and developers. This ensures that the website meets the needs of the business
and that any issues or concerns are addressed in a timely manner.
19
Flexibility: The iterative waterfall model allows for flexibility in the development process. If
changes or new requirements arise, they can be incorporated into the next iteration of the
website.
Testing and feedback: The testing stage of the process is important for identifying any issues
or bugs that need to be addressed before the website is deployed. Additionally, feedback from
users or customers can be gathered and used to improve the website in subsequent iterations.
Scalability: The iterative waterfall model is scalable, meaning it can be used for projects of
various sizes and complexities. For example, a larger business may require more iterations or
more complex requirements, but the same process can still be followed.
Maintenance: Once the website is live, ongoing maintenance is necessary to ensure it
continues to meet the needs of the business and its users. The iterative waterfall model can be
used for maintenance and improvement cycles, allowing the website to evolve and stay up-to-
date.

Advantages of Iterative Waterfall Model:
 Feedback Path –
In the classical waterfall model, there are no feedback paths, so there is no mechanism for
error correction. But in the iterative waterfall model feedback path from one phase to its
preceding phase allows correcting the errors that are committed and these changes are
reflected in the later phases.
 Simple –
Iterative waterfall model is very simple to understand and use. That’s why it is one of the
most widely used software development models.
 Cost-Effective –
It is highly cost-effective to change the plan or requirements in the model. Moreover, it is
best suited for agile organizations.
 Well-organized –
In this model, less time is consumed on documenting and the team can spend more time on
development and designing.
 Risk Reduction: The iterative approach allows for early identification and mitigation of
risks, reducing the likelihood of costly errors later in the development process.
 Quality Assurance: The iterative approach promotes quality assurance by providing
opportunities for testing and feedback throughout the development process. This results in
a higher-quality end product.
20
 Improved Customer Satisfaction: The iterative approach allows for customer

involvement and feedback throughout the development process, resulting in a final product
that better meets the needs and expectations of the customer.
 Predictable Outcomes: The phased approach of the iterative waterfall model allows for
more predictable outcomes and greater control over the development process, ensuring that
the project stays on track and within budget.
 Faster Time to Market: The iterative approach allows for faster time to market as small
and incremental improvements are made over time, rather than waiting for a complete
product to be developed.
 Easy to Manage: The iterative waterfall model is easy to manage as each phase is well-
defined and has a clear set of deliverables. This makes it easier to track progress, identify
issues, and manage resources.

Drawbacks of Iterative Waterfall Model :
 Difficult to incorporate change requests –
The major drawback of the iterative waterfall model is that all the requirements must be
clearly stated before starting the development phase. Customers may change requirements
after some time but the iterative waterfall model does not leave any scope to incorporate
change requests that are made after the development phase starts.

 Incremental delivery not supported –
In the iterative waterfall model, the full software is completely developed and tested before
delivery to the customer. There is no scope for any intermediate delivery. So, customers
have to wait a long for getting the software.

 Overlapping of phases not supported –
Iterative waterfall model assumes that one phase can start after completion of the previous
phase, But in real projects, phases may overlap to reduce the effort and time needed to
complete the project.

 Risk handling not supported –
Projects may suffer from various types of risks. But, the Iterative waterfall model has no
mechanism for risk handling.

21
 Limited customer interactions –

Customer interaction occurs at the start of the project at the time of requirement gathering
and at project completion at the time of software delivery. These fewer interactions with
the customers may lead to many problems as the finally developed software may differ
from the customers’ actual requirements.
1.3.1.3 Prototyping Model
Prototyping is defined as the process of developing a working replication of a product or

system that has to be engineered. It offers a small-scale facsimile of the end product and is
used for obtaining customer feedback. The Prototyping concept is described below:
The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customers do not know the exact project
requirements beforehand. In this model, a prototype of the end product is first developed,
tested, and refined as per customer feedback repeatedly till a final acceptable prototype is
achieved which forms the basis for developing the final product.
In this process model, the system is partially implemented before or during the analysis phase
thereby giving the customers an opportunity to see the product early in the life cycle. The
process starts by interviewing the customers and developing the incomplete high-level paper
model. This document is used to build the initial prototype supporting only the basic
functionality as desired by the customer. Once the customer figures out the problems, the
22
prototype is further refined to eliminate them. The process continues until the user approves
the prototype and finds the working model to be satisfactory.
Steps Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a
prototype model. In this phase, users are asked about what they expect or what they want from
the system.
Step 2: Quick Design: This is the second step in Prototyping Model. This model covers the
basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strength and
weaknesses of the design, which was sent to the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here program
is run regularly to prevent failures.
23
Types of Prototyping Models

There are four types of Prototyping Models, which are described below.
 Rapid Throwaway Prototyping

 Evolutionary Prototyping
 Incremental Prototyping
 Extreme Prototyping
1. Rapid Throwaway Prototyping
This technique offers a useful method of exploring ideas and getting customer feedback for
each of them. In this method, a developed prototype need not necessarily be a part of the
24
ultimately accepted prototype. Customer feedback helps in preventing unnecessary design

faults and hence, the final prototype developed is of better quality.
2. Evolutionary Prototyping
In this method, the prototype developed initially is incrementally refined on the basis of
customer feedback till it finally gets accepted. In comparison to Rapid Throwaway
Prototyping, it offers a better approach that saves time as well as effort. This is because
developing a prototype from scratch for every iteration of the process can sometimes be very
frustrating for the developers.
3. Incremental Prototyping
In this type of incremental Prototyping, the final expected product is broken into different
small pieces of prototypes and developed individually. In the end, when all individual pieces
are properly developed, then the different prototypes are collectively merged into a single final
product in their predefined order. It’s a very efficient approach that reduces the complexity of
the development process, where the goal is divided into sub-parts and each sub-part is
developed individually. The time interval between the project’s beginning and final delivery is
substantially reduced because all parts of the system are prototyped and tested simultaneously.
Of course, there might be the possibility that the pieces just do not fit together due to some
lack of ness in the development phase – this can only be fixed by careful and complete plotting
of the entire system before prototyping starts.
4. Extreme Prototyping
This method is mainly used for web development. It consists of three sequential independent
phases:
1. In this phase, a basic prototype with all the existing static pages is presented in HTML
format.
2. In the 2nd phase, Functional screens are made with a simulated data process using a
prototype services layer.
3. This is the final step where all the services are implemented and associated with the final
prototype.
This Extreme Prototyping method makes the project cycling and delivery robust and fast and
keeps the entire developer team focused and centralized on product deliveries rather than
discovering all possible needs and specifications and adding un necessitated features.
25
Advantages of Prototyping Model

 The customers get to see the partial product early in the life cycle. This ensures a greater
level of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
 The developed prototype can be reused by the developer for more complicated projects in
the future.
 Flexibility in design.
 Early feedback from customers and stakeholders can help guide the development process
and ensure that the final product meets their needs and expectations.
 Prototyping can be used to test and validate design decisions, allowing for adjustments to
be made before significant resources are invested in development.
 Prototyping can help reduce the risk of project failure by identifying potential issues and
addressing them early in the process.
 Prototyping can facilitate communication and collaboration among team members and
stakeholders, improving overall project efficiency and effectiveness.
 Prototyping can help bridge the gap between technical and non-technical stakeholders by
providing a tangible representation of the product.
Disadvantages of the Prototyping Model

 Costly with respect to time as well as money.
 There may be too much variation in requirements each time the prototype is evaluated by
the customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for developers to accommodate all the changes demanded by the
customer.
 There is uncertainty in determining the number of iterations that would be required before
the prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal solutions.
26
 The customer might lose interest in the product if he/she is not satisfied with the initial
prototype.
 The prototype may not be scalable to meet the future needs of the customer.
 The prototype may not accurately represent the final product due to limited functionality or
incomplete features.
 The focus on prototype development may shift the focus away from the final product,
leading to delays in the development process.
 The prototype may give a false sense of completion, leading to the premature release of the
product.
 The prototype may not consider technical feasibility and scalability issues that can arise
during the final product development.
 The prototype may be developed using different tools and technologies, leading to
additional training and maintenance costs.
 The prototype may not reflect the actual business requirements of the customer, leading to
dissatisfaction with the final product.
Applications of Prototyping Model
 The Prototyping Model should be used when the requirements of the product are not
clearly understood or are unstable.
 The prototyping model can also be used if requirements are changing quickly.
 This model can be successfully used for developing user interfaces, high-technology
software-intensive systems, and systems with complex algorithms and interfaces.
 The prototyping Model is also a very good choice to demonstrate the technical feasibility
of the product.
For more software engineering models, you can refer to Classical Waterfall Model , Spiral
Model, and Iterative Waterfall Model .
1.3.1.4 Evolutionary Model
Evolutionary model is a combination of Iterative and Incremental model of software

development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial requirements and
architecture envisioning need to be done. It is better for software products that have their
feature sets redefined during development because of user feedback and other factors. The
Evolutionary development model divides the development cycle into smaller, incremental
27
waterfall models in which users are able to get access to the product at the end of each cycle.
Feedback is provided by the users on the product for the planning stage of the next cycle and
the development team responds, often by changing the product, plan or process. Therefore, the
software product evolves with time. All the models have the disadvantage that the duration of
time from start of the project to the delivery time of a solution is very high. Evolutionary
model solves this problem in a different approach.
Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them
and then delivering those chunks to the customer one by one. The number of chunks is huge
and is the number of deliveries made to the customer. The main advantage is that the
customer’s confidence increases as he constantly gets quantifiable goods or services from the
beginning of the project to verify and validate his requirements. The model allows for
changing requirements as well as all work is broken down into maintainable work chunks.
Application of Evolutionary Model:
1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants to start
using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because the
system can be easily portioned into units in terms of objects.
28
Necessary conditions for implementing this model:-

 Customer needs are clear and been explained in deep to the developer team.
 There might be small changes required in separate parts but not a major change.
 As it requires time, so there must be some time left for the market constraints.
 Risk is high and continuous targets to achieve and report to customer repeatedly.
 It is used when working on a technology is new and requires time to learn.
Advantages:
 In evolutionary model, a user gets a chance to experiment partially developed system.
 It reduces the error because the core modules get tested thoroughly.
Disadvantages:
 Sometimes it is hard to divide the problem into several versions that would be acceptable
to the customer which can be incrementally implemented and delivered.
1.3.1.5 Spiral Model
Spiral model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral
with many loops. The exact number of loops of the spiral is unknown and can vary from
project to project. Each loop of the spiral is called a Phase of the software development
process. The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks. As the project manager dynamically
determines the number of phases, so the project manager has an important role to develop a
product using the spiral model.
The Spiral Model is a software development life cycle (SDLC) model that provides a
systematic and iterative approach to software development. It is based on the idea of a spiral,
with each iteration of the spiral representing a complete software development cycle, from
requirements gathering and analysis to design, implementation, testing, and maintenance.
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through
multiple iterations of the software development process. It consists of the following phases:
1. Planning: The first phase of the Spiral Model is the planning phase, where the scope of the
project is determined and a plan is created for the next iteration of the spiral.
29
2. Risk Analysis: In the risk analysis phase, the risks associated with the project are identified
and evaluated.
3. Engineering: In the engineering phase, the software is developed based on the requirements
gathered in the previous iteration.
4. Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
5. Planning: The next iteration of the spiral begins with a new planning phase, based on the
results of the evaluation.
6. The Spiral Model is often used for complex and large software development projects, as it
allows for a more flexible and adaptable approach to software development. It is also well-
suited to projects with significant uncertainty or high levels of risk.
The Radius of the spiral at any point represents the expenses(cost) of the project so far, and
the angular dimension represents the progress made so far in the current phase.
The below diagram shows the different phases of the Spiral Model: –
Each phase of the Spiral Model is divided into four quadrants as shown in the above figure.
The functions of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are gathered

from the customers and the objectives are identified, elaborated, and analyzed at the start
30
of every phase. Then alternative solutions possible for the phase are proposed in this
quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the
so far developed version of the software. In the end, planning for the next phase is started.
Risk Handling in Spiral Model: A risk is any adverse situation that might affect the
successful completion of a software project. The most important feature of the spiral model is
handling these unknown risks after the project has started. Such risk resolutions are easier
done by developing a prototype. The spiral model supports coping up with risks by providing
the scope to build a prototype at every phase of the software development.
The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life project risk
may occur after the development work starts, in that case, we cannot use the Prototyping
Model. In each phase of the Spiral Model, the features of the product dated and analyzed, and
the risks at that point in time are identified and are resolved through prototyping. Thus, this
model is much more flexible compared to other SDLC models.
Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For
example, a single loop spiral actually represents the Iterative Waterfall Model . The spiral
model incorporates the stepwise approach of the Classical Waterfall Model . The spiral model
uses the approach of the Prototyping Model by building a prototype at the start of each phase
as a risk-handling technique. Also, the spiral model can be considered as supporting
the Evolutionary model – the iterations along the spiral can be considered as evolutionary
levels through which the complete system is built.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
31
1. Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.
5. Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and adaptability in
response to changing requirements or unexpected events.
6. Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.
7. Improved Communication: The Spiral Model provides for regular evaluations and reviews,
which can improve communication between the customer and the development team.
8. Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project is
very much dependent on Risk Analysis. Without very highly experienced experts, it is
going to be a failure to develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
5. Complexity: The Spiral Model can be complex, as it involves multiple iterations of the
software development process.
32
6. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple

evaluations and reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a significant
investment in planning, risk analysis, and evaluations .
1.4 Software project management
A Software Project is the complete procedure of software development from requirement

gathering to testing and maintenance, carried out according to the execution methodologies, in a
specified period of time to achieve intended software product.
1.4.1 Need of software project management
Software is said to be an intangible product. Software development is a kind of all new stream in
world business and there’s very little experience in building software products. Most software
products are tailor made to fit client’s requirements. The most important is that the underlying
technology changes and advances so frequently and rapidly that experience of one product may
not be applied to the other one. All such business and environmental constraints bring risk in
software development hence it is essential to manage software projects efficiently.
The image above shows triple constraints for software projects. It is an essential part of software
organization to deliver quality product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled. There are several factors, both internal and external, which
may impact this triple constrain triangle. Any of three factor can severely impact the other two.
Therefore, software project management is essential to incorporate user requirements along with
budget and time constraints.
1.4.2 Software Project Manager
A software project manager is a person who undertakes the responsibility of executing the
software project. Software project manager is thoroughly aware of all the phases of SDLC that
33
the software would go through. Project manager may never directly involve in producing the end
product but he controls and manages the activities involved in production.
A project manager closely monitors the development process, prepares and executes various
plans, arranges necessary and adequate resources, maintains communication among all team
members in order to address issues of cost, budget, resources, time, quality and customer
satisfaction.
Let us see few responsibilities that a project manager shoulders -
Managing People
 Act as project leader
 Liaison with stakeholders
 Managing human resources
 Setting up reporting hierarchy etc.
Managing Project
 Defining and setting up project scope
 Managing project management activities
 Monitoring progress and performance
 Risk analysis at every phase
 Take necessary step to avoid or come out of problems
 Act as project spokesperson
1.4.3 Software Management Activities
Software project management comprises of a number of activities, which contains planning of

project, deciding scope of software product, estimation of cost in various terms, scheduling of
tasks and events, and resource management. Project management activities may include:
 Project Planning
 Scope Management
 Project Estimation
1.4.3.1 Project Planning
Software project planning is task, which is performed before the production of software actually
starts. It is there for the software production but involves no concrete activity that has any
direction connection with software production; rather it is a set of multiple processes, which
facilitates software production. Project planning may include the following:
34
1.4.3.2 Scope Management
It defines the scope of project; this includes all the activities, process need to be done in order to
make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what would
not be done. This makes project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun.
During Project Scope management, it is necessary to -
 Define the scope

 Decide its verification and control
 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope
1.4.3.3 Project Estimation
For an effective management accurate estimation of various measures is a must. With correct
estimation managers can manage and control the project more efficiently and effectively.
Project estimation may involve the following:
 Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding
practices and Function points vary according to the user or software requirement.
 Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour required
to produce the software. For effort estimation software size should be known. This can
either be derived by managers’ experience, organization’s historical data or software size
can be converted into efforts by using some standard formulae.
 Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks are
divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS).
The tasks are scheduled on day-to-day basis or in calendar months.
35
The sum of time required to complete all tasks in hours or days is the total time invested
to complete the project.
 Cost estimation
This might be considered as the most difficult of all because it depends on more elements
than any of the previous ones. For estimating project cost, it is required to consider -
o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support
1.4.4 Project Estimation Techniques
We discussed various parameters involving project estimation such as size, effort, time and cost.
Project manager can estimate the listed factors using two broadly recognized techniques –
Decomposition Technique
This technique assumes the software as a product of various compositions.
There are two main models -
 Line of Code Estimation is done on behalf of number of line of codes in the software

product.
 Function Points Estimation is done on behalf of number of function points in the
software product.
Empirical Estimation Technique
This technique uses empirically derived formulae to make estimation.These formulae are based
on LOC or FPs.
 Putnam Model
This model is made by Lawrence H. Putnam, which is based on Norden’s frequency
distribution (Rayleigh curve). Putnam model maps time and efforts required with
software size.
36
 COCOMO
COCOMO stands for COnstructive COst MOdel, developed by Barry W. Boehm. It
divides the software product into three categories of software: organic, semi-detached and
embedded.
1.4.5 Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity. Project managers tend to define various tasks, and
project milestones and arrange them keeping various factors in mind. They look for tasks lie in
critical path in the schedule, which are necessary to complete in specific manner (because of task
interdependency) and strictly within the time allocated. Arrangement of tasks which lies out of
critical path are less likely to impact over all schedule of the project.
For scheduling a project, it is necessary to -
 Break down the project tasks into smaller, manageable form

 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Calculate total time required for the project from start to finish
1.4.6 Resource management
All elements used to develop a software product may be assumed as resource for that project.
This may include human resource, productive tools and software libraries.
The resources are available in limited quantity and stay in the organization as a pool of assets.
The shortage of resources hampers the development of project and it can lag behind the
schedule. Allocating extra resources increases development cost in the end. It is therefore
necessary to estimate and allocate adequate resources for the project.
Resource management includes -
 Defining proper organization project by creating a project team and allocating

responsibilities to each team member
 Determining resources required at a particular stage and their availability
37
 Manage Resources by generating resource request when they are required and de-
allocating them when they are no more needed.
1.4.7 Project Risk Management
Risk management involves all activities pertaining to identification, analyzing and making
provision for predictable and non-predictable risks in the project. Risk may include the
following:
 Experienced staff leaving the project and new staff coming in.
 Change in organizational management.
 Requirement change or misinterpreting requirement.
 Under-estimation of required time and resources.
 Technological changes, environmental changes, business competition.
1.4.8 Risk Management Process
There are following activities involved in risk management process:
 Identification - Make note of all possible risks, which may occur in the project.
 Categorize - Categorize known risks into high, medium and low risk intensity as per
their possible impact on the project.
 Manage - Analyze the probability of occurrence of risks at various phases. Make plan to
avoid or face risks. Attempt to minimize their side-effects.
 Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the
effects of steps taken to mitigate or avoid them.
1.4.9 Project Execution & Monitoring
In this phase, the tasks described in project plans are executed according to their schedules.
Execution needs monitoring in order to check whether everything is going according to the plan.
Monitoring is observing to check the probability of risk and taking measures to address the risk
or report the status of various tasks.
These measures include -
 Activity Monitoring - All activities scheduled within some task can be monitored on
day-to-day basis. When all activities in a task are completed, it is considered as complete.
38
 Status Reports - The reports contain status of activities and tasks completed within a
given time frame, generally a week. Status can be marked as finished, pending or work-
in-progress etc.
 Milestones Checklist - Every project is divided into multiple phases where major tasks
are performed (milestones) based on the phases of SDLC. This milestone checklist is
prepared once every few weeks and reports the status of milestones.
1.4.10 Project Communication Management
Effective communication plays vital role in the success of a project. It bridges gaps between
client and the organization, among the team members as well as other stake holders in the
project such as hardware suppliers.
Communication can be oral or written. Communication management process may have the
following steps:
 Planning - This step includes the identifications of all the stakeholders in the project and
the mode of communication among them. It also considers if any additional
communication facilities are required.
 Sharing - After determining various aspects of planning, manager focuses on sharing
correct information with the correct person on correct time. This keeps every one
involved the project up to date with project progress and its status.
 Feedback - Project managers use various measures and feedback mechanism and create
status and performance reports. This mechanism ensures that input from various
stakeholders is coming to the project manager as their feedback.
 Closure - At the end of each major event, end of a phase of SDLC or end of the project
itself, administrative closure is formally announced to update every stakeholder by
sending email, by distributing a hardcopy of document or by other mean of effective
communication.
After closure, the team moves to next phase or project.
Configuration Management
Configuration management is a process of tracking and controlling the changes in software in

terms of the requirements, design, functions and development of the product.
39
IEEE defines it as “the process of identifying and defining the items in the system, controlling
the change of these items throughout their life cycle, recording and reporting the status of items
and change requests, and verifying the completeness and correctness of items”.
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as there is
a possibility of cost and time overrun.
Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines
completeness of a phase. A phase is baselined when all activities pertaining to it are finished and
well documented. If it was not the final phase, its output would be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of

occurrence of any change (process, requirement, technological, strategical etc.) after a phase is
baselined. CM keeps check on any changes done in software.
Change Control
Change control is function of configuration management, which ensures that all changes made to
software system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps -
 Identification - A change request arrives from either internal or external source. When
change request is identified formally, it is properly documented.
 Validation - Validity of the change request is checked and its handling procedure is
confirmed.
 Analysis - The impact of change request is analyzed in terms of schedule, cost and
required efforts. Overall impact of the prospective change on system is analyzed.
 Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is
incorporated into the system. It is decided if the change is worth incorporation or not. If it
is not, change request is refused formally.
 Execution - If the previous phase determines to execute the change request, this phase
take appropriate actions to execute the change, does a thorough revision if necessary.
40
 Close request - The change is verified for correct implementation and merging with the
rest of the system. This newly incorporated change in the software is documented
properly and the request is formally is closed.
1.4.11 Project Management Tools
The risk and uncertainty rises multifold with respect to the size of the project, even when the
project is developed according to set methodologies.
There are tools available, which aid for effective project management. A few are described -
Gantt Chart
Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to
time periods. It is a horizontal bar chart with bars representing activities and time scheduled for
the project activities.
PERT Chart
PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network
diagram. It is capable of graphically representing main events of project in both parallel and
consecutive way. Events, which occur one after another, show dependency of the later event
over the previous one.
41
Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence
of tasks in the project.
Resource Histogram
This is a graphical tool that contains bar or chart representing number of resources (usually
skilled staff) required over time for a project event (or phase). Resource Histogram is an
effective tool for staff planning and coordination.
Critical Path Analysis
This tools is useful in recognizing interdependent tasks in the project. It also helps to find out the
shortest path or critical path to complete the project successfully. Like PERT diagram, each
event is allotted a specific time frame. This tool shows dependency of event assuming an event
can proceed to next only if the previous one is completed.
42
The events are arranged according to their earliest possible start time. Path between start and end
node is critical path which cannot be further reduced and all events require to be executed in
same order.
1.5 Software configuration management
System Configuration Management (SCM) is an arrangement of exercises which controls

change by recognizing the items for change, setting up connections between those things,
making/characterizing instruments for overseeing diverse variants, controlling the changes
being executed in the current framework, inspecting and revealing/reporting on the changes
made. It is essential to control the changes in light of the fact that if the changes are not
checked legitimately then they may wind up undermining a well-run programming. In this
way, SCM is a fundamental piece of all project management activities.
Processes involved in SCM – Configuration management provides a disciplined environment
for smooth control of work products. It involves the following activities:
1. Identification and Establishment – Identifying the configuration items from products that
compose baselines at given points in time (a baseline is a set of mutually consistent
Configuration Items, which has been formally reviewed and agreed upon, and serves as the
basis of further development). Establishing relationship among items, creating a
mechanism to manage multiple level of control and procedure for change management
system.
2. Version control – Creating versions/specifications of the existing product to build new
products from the help of SCM system. A description of version is given
below:
43
3. Suppose after some changes, the version of configuration object changes from 1.0 to 1.1.
Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed by a
major update that is object 1.2. The development of object 1.0 continues through 1.3 and
1.4, but finally, a noteworthy change to the object results in a new evolutionary path,
version 2.0. Both versions are currently supported.
4. Change control – Controlling changes to Configuration items (CI). The change control
process is explained in Figure
below:

A change request (CR) is submitted and evaluated to assess technical merit, potential side
effects, overall impact on other configuration objects and system functions, and the
projected cost of the change. The results of the evaluation are presented as a change report,
which is used by a change control board (CCB) —a person or group who makes a final
decision on the status and priority of the change. An engineering change Request (ECR) is
generated for each approved change. Also CCB notifies the developer in case the change is
rejected with proper reason. The ECR describes the change to be made, the constraints that
must be respected, and the criteria for review and audit. The object to be changed is
“checked out” of the project database, the change is made, and then the object is tested
44
again. The object is then “checked in” to the database and appropriate version control
mechanisms are used to create the next version of the software.
5. Configuration auditing – A software configuration audit complements the formal
technical review of the process and product. It focuses on the technical correctness of the
configuration object that has been modified. The audit confirms the completeness,
correctness and consistency of items in the SCM system and track action items from the
audit to closure.
6. Reporting – Providing accurate status and current configuration data to developers, tester,
end users, customers and stakeholders through admin guides, user guides, FAQs, Release
notes, Memos, Installation Guide, Configuration guide etc .
System Configuration Management (SCM) is a software engineering practice that focuses on
managing the configuration of software systems and ensuring that software components are
properly controlled, tracked, and stored. It is a critical aspect of software development, as it
helps to ensure that changes made to a software system are properly coordinated and that the
system is always in a known and stable state.
SCM involves a set of processes and tools that help to manage the different components of a
software system, including source code, documentation, and other assets. It enables teams to
track changes made to the software system, identify when and why changes were made, and
manage the integration of these changes into the final product.
The key objectives of SCM are to:
1. Control the evolution of software systems: SCM helps to ensure that changes to a software
system are properly planned, tested, and integrated into the final product.
2. Enable collaboration and coordination: SCM helps teams to collaborate and coordinate
their work, ensuring that changes are properly integrated and that everyone is working
from the same version of the software system.
3. Provide version control: SCM provides version control for software systems, enabling
teams to manage and track different versions of the system and to revert to earlier versions
if necessary.
4. Facilitate replication and distribution: SCM helps to ensure that software systems can be
easily replicated and distributed to other environments, such as test, production, and
customer sites.
45
5. SCM is a critical component of software development, and effective SCM practices can
help to improve the quality and reliability of software systems, as well as increase
efficiency and reduce the risk of errors.
The main advantages of SCM are:
1. Improved productivity and efficiency by reducing the time and effort required to manage
software changes.
2. Reduced risk of errors and defects by ensuring that all changes are properly tested and
validated.
3. Increased collaboration and communication among team members by providing a central
repository for software artifacts.
4. Improved quality and stability of software systems by ensuring that all changes are
properly controlled and managed.
The main disadvantages of SCM are:
1. Increased complexity and overhead, particularly in large software systems.

2. Difficulty in managing dependencies and ensuring that all changes are properly integrated.
3. Potential for conflicts and delays, particularly in large development teams with multiple
contributors.
46

Unit - I

Uploaded by

Copyright:

Available Formats

You might also like

Unit - I

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit - I

Uploaded by

Copyright:

Available Formats

Unit -I SOFTWARE ENGINEERING Lecture Notes

Software engineering concepts – Development activities – Software lifecycle models - Classical

1.1 Software engineering concepts

The term software engineering is the product of two words, software, and engineering.

Software is a program or set of programs containing instructions that provide desired

Software engineering is the process of designing, developing, testing, and maintaining

Key principles of software engineering include:

Objectives / Characteristics of Software Engineering:

1.1.1 Layers of Software Development

1.2 Software Processes

The term software specifies to the set of computer programs, procedures and associated

1. Software specifications: The functionality of the software and constraints on its

The Software Process Model

There are several various general models or paradigms of software development:

3. Formal transformation: This method is based on producing a formal mathematical

Program vs. Software

There are three components of the software as shown in fig:

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals. Examples of

4. Operating Procedures: Operating Procedures consist of instructions to set up and use

1.3 Software Development Life Cycle (SDLC)

 Stage-1: Planning And Requirement Analysis:

 Stage-2: Defining Requirements:

 Documentation, Training and support:

1.3.1 SDLC Models

Here, are some important phases of SDLC life cycle:

1.3.1.1 Classical waterfall

Use of Waterfall Model:

Features of the Waterfall Model

Phases of Classical Waterfall Model:

1. Requirements Gathering and Analysis: The first phase involves gathering requirements

Let us now learn about each of these phases in detail.

2. Requirements Analysis and Specification

5. Integration and System testing

 Corrective Maintenance: This type of maintenance is carried out to correct errors that

 Adaptive Maintenance: Adaptive maintenance is usually required for porting the software

Advantages of the Classical Waterfall Model

 Easy to Understand: Classical Waterfall Model is very simple and easy to understand.

Disadvantages of the Classical Waterfall Model

 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software

Applications of Classical Waterfall Model

1.3.1.2 Iterative waterfall

Phase Containment of Errors: The principle of detecting errors as close to their points of

 Improved Customer Satisfaction: The iterative approach allows for customer

 Limited customer interactions –

1.3.1.3 Prototyping Model

Prototyping is defined as the process of developing a working replication of a product or

Steps Prototyping Model

Types of Prototyping Models

 Rapid Throwaway Prototyping

ultimately accepted prototype. Customer feedback helps in preventing unnecessary design

Advantages of Prototyping Model

Disadvantages of the Prototyping Model

1.3.1.4 Evolutionary Model

Evolutionary model is a combination of Iterative and Incremental model of software

Necessary conditions for implementing this model:-

1.3.1.5 Spiral Model