Unit-1

Introduction: Introduction to Software Engineering, Software Components,

Software Characteristics, Software Crisis, Software Engineering Processes,
Similarity and Differences from Conventional Engineering Processes, Software
Quality Attributes. Software Development Life Cycle (SDLC) Models: Water
Fall Model, Prototype Model, Spiral Model, Evolutionary Development Models,
Iterative Enhancement Models.

Software Components:
Computer programs and associated documentation.

Components of software Software=Program+Documentation+Operating

Procedures.
Software Process :
The software process is the way in which we produce software. Why is it difficult
to improve software process ? • Not enough time • Lack of knowledge.
Difference Between Software Engineering Process and Conventional
Engineering Process
 Conventional Engineering
Software Engineering Process Process

Software Engineering Process is a The conventional Engineering

process that majorly involves Process is a process that majorly
computer science, information involves science, mathematics, and
technology, and discrete mathematics. empirical knowledge.

It is mainly related to computers,

It is about building cars, machines,
programming, and writing codes for
hardware, buildings, etc.
building applications.

In Software Engineering Process In Conventional Engineering

construction and development cost is Process construction and
low. development cost is high.

It can involve the application of new It usually applies only known and
and untested elements in software tested principles to meet product
projects. requirements.

In Software Engineering Process, In Conventional Engineering

most development effort goes into Process, most development efforts
building new designs and features. are required to change old designs.

It majorly emphasizes mass

It majorly emphasizes quality.
production.

Product development develops

Product development develops
tangible products (e.g. bridges,
intangible products (software).
buildings).

Software Quality Attributes:

1. Portability: A software is considered portable if it can seamlessly
function across different operating systems, hardware configurations, and
environments. In other words, it should adapt easily to various contexts.
2. Usability: Usability refers to how well different categories of users (both
experts and novices) can interact with the software. A highly usable
product ensures that users can effortlessly invoke its functions.
 3. Reusability: A software exhibits reusability when its individual modules
can be efficiently reused to develop new products. This attribute promotes
efficiency and reduces redundancy in software development.
4. Correctness: Software is deemed correct if it adheres to the requirements
specified in the Software Requirements Specification (SRS) document. It
must accurately fulfil its intended purpose.
5. Maintainability: A software’s maintainability relates to its ease of
modification, error correction, and addition of new features. A
maintainable product allows developers to make changes without undue
complexity.
6. Reliability: Reliability pertains to the software’s ability to function
without unexpected failures. It depends on the number and type of mistakes
made during development. Rigorous testing and robust error handling
contribute to reliability.
7. Efficiency: Efficient software minimizes resource usage, including CPU
time, memory, disk space, and network bandwidth. While modern
computers are powerful, optimizing efficiency remains essential for cost-
effective operation.
8. Testability: Testability ensures that the software can be effectively tested
to identify defects. Well-designed software facilitates thorough testing,
leading to higher quality.
9. Portability: Lastly, portability (again!) emphasizes the ease with which
software can adapt to different environments, platforms, and devices.

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.

Classical Water Fall Model:

 Feasibility study
The main focus of the feasibility study stage is to determine whether it
would be financially and technically feasible to develop the software.
feasibility study involves carrying out several activities such as collection
of basic information relating to the software such as the different data items
that would be input to the system, the processing required to be carried out
on these data, the output data required to be produced by the system, as
well as various constraints on the development.

Requirement Analysis

The goal of the requirements gathering activity is to collect all relevant

information regarding the software to be developed from the customer with a
view to clearly understand the requirements. For this, first requirements are
gathered from the customer and then the gathered requirements are analysed. The
goal of the requirements analysis activity is to weed out the incompleteness and
inconsistencies in these gathered requirements. Note that a n inconsistent
requirement is one in which some part of the requirement contradicts with some
other part. On the other hand, a n incomplete requirement is one in which some
parts of the actual requirements have been omitted. Requirements specification:
After the requirement gathering and analysis activities are complete, the
identified requirements are documented. This is called a software requirements
specification (SRS) document. The SRS document is written using end-user
terminology. This makes the SRS document understandable to the customer.
Therefore, understandability of the SRS document is an important issue. The SRS
document normally serves as a contract between the development team and the
customer.

Design

The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some
programming language. In technical terms, during the design phase the software
architecture is derived from the SRS document. Two distinctly different design
approaches are popularly being used at present—the procedural and object-
oriented design approaches.

Coding and unit testing

The purpose of the coding and unit testing phase is to translate a software design
into source code and to ensure that individually each function is working
correctly. The coding phase is also sometimes called t h e implementation phase,
since the design is implemented into a workable solution in this phase. Each
component of the design is implemented as a program module. The end-product
of this phase is a set of program modules that have been individually unit tested.

Integration and system testing

Integration of different modules is undertaken soon after they have been coded
and unit tested. During the integration and system testing phase, the different
modules are integrated in a planned manner. Various modules making up a
software are almost never integrated in one shot (can you guess the reason for
this?). Integration of various modules are normally 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.

Maintenance

The total effort spent on maintenance of a typical software during its operation
phase is much more than that required for developing the software itself. Many
studies carried out in the past confirm this and indicate that the ratio of relative
effort of developing a typical software product and the total effort spent on its
maintenance is roughly 40:60.

Shortcomings of the classical waterfall mode:

The classical waterfall model is a very simple and intuitive model. However, it
suffers from several shortcomings. Let us identify some of the important
shortcomings of the classical waterfall model:

No feedback paths: In classical waterfall model, the evolution of a software from

one phase to the next is analogous to a waterfall. Just as water in a waterfall after
having flowed down cannot flow back, once a phase is complete, the activities
carried out in it and any artifacts produced in this phase are final and are closed
for any rework. This requires that all activities during a phase are flawlessly
carried out.

Difficult to accommodate change requests: This model assumes that all

customer requirements can be completely and correctly defined at the beginning
of the project. There is much emphasis on creating an unambiguous and complete
set of requirements.

Inefficient error corrections: This model defers integration of code and testing
tasks until it is very late when the problems are harder to resolve.

No overlapping of phases: This model recommends that the phases be carried

out sequentially new phase can start only after the previous one completes.
However, it is rarely possible to adhere to this recommendation and it leads to a
large number of team members to idle for extended periods.

Iterative Waterfall Model

The main change brought about by the iterative waterfall model to the classical
waterfall model is in the form of providing feedback paths from every phase to
its preceding phases.
Prototype model:

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

or system that must 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 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 the program is run regularly to prevent failures
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.
 • 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.
Spiral Model:
This model gets its name from the appearance of its diagrammatic representation
that looks like a spiral with many loops. The exact number of loops of the spiral
is not fixed and can vary from project to project. Each loop of the spiral is called
a phase of the software process. The exact number of phases through which the
product is developed can be varied by the project manager depending upon the
project risks. A prominent feature of the spiral model is handling unforeseen risks
that can show up much after the project has started. In this context, please
recollect that the prototyping model can be used effectively only when the risks
in a project can be identified upfront before the development work starts. As we
shall discuss, this model achieves this by incorporating much more flexibility
compared to SDLC other models. While the prototyping model does provide
explicit support for risk handling, the risks are assumed to have been identified
completely before the project start. This is required since the prototype is
constructed only at the start of the project. In contrast, in the spiral model
prototypes are built at the start of every phase. Each phase of the model is
represented as a loop in its diagrammatic representation. Over each loop, one or
more features of the product are elaborated
and analysed and the risks at that point of time are identified and are resolved
through prototyping. Based on this, the identified features are implemented.

Phases of the Spiral Model :

Each phase in this model is split into four sectors (or quadrants) as shown in
Figure. In the first quadrant, a few features of the software are identified to be
taken u p for immediate development based on how crucial it is to the overall
software development. With each iteration around the spiral (beginning at the
center and moving outwards), progressively more complete versions of the
software get built. In other words, implementation of the identified features forms
a phase.
Quadrant 1: The objectives are investigated, elaborated, and analysed. Based
on this, the risks involved in meeting the phase objectives are identified. In this
quadrant, alternative solutions possible for the phase under consideration are
proposed.
Quadrant 2: During the second quadrant, the alternative solutions are evaluated
to select the best possible solution. To be able to do this, the solutions are
evaluated by developing an appropriate prototype.
Quadrant 3: Activities during the third quadrant consist of developing and
verifying the next level of the software. At the end of the third quadrant, the
identified features have been implemented and the next version of the software is
available.
Quadrant 4: Activities during the fourth quadrant concern reviewing the results
of the stages traversed so far (i.e. the developed version of the software) with the
customer and planning the next iteration of the spiral. The radius of the spiral at
any point represents the cost incurred in the project so far, and the angular
dimension represents the progress made so far in the current phase.
In the spiral model of development, the project manager dynamically determines
the number of phases as the project progresses. Therefore, in this model, the
project manager plays the crucial role of tuning the model to specific projects. To
make the model more efficient, the different features of the software that can be
developed simultaneously through parallel cycles are identified.
Advantages/pros and disadvantages/cons of the spiral model
There are a few disadvantages of the spiral model that restrict its use to a only a
few types of projects. To the developers of a project, the spiral model usually
appears as a complex model to follow, since it is risk driven and is more
complicated phase structure than the other models we discussed. It would
therefore be counterproductive to use, unless there are knowledgeable and
experienced staff in the project. Also, it is not very suitable for use in the
development of outsourced projects since the software risks need to be
continually assessed as it is developed.
In spite of the disadvantages of the spiral model that we pointed out, for certain
categories of projects, the advantages of the spiral model can outweigh its
disadvantages. For projects having many unknown risks that might show up as
the development proceeds, the spiral model would be the most appropriate
development model to follow.
Iterative Enhancement Model

Software development uses a dynamic and adaptable method called the iterative
enhancement Model. The iterative enhancement model encourages a software
product’s ongoing evolution and improvement. This methodology is noticeable due
to its concentration on adaptability, flexibility and change responsiveness. It makes
it easier for a product to evolve because it gives developers the freedom to
progressively enhance the software, making sure that it complies with evolving
specifications, user demands, and market demands. This helps products evolve more
easily.
The Iterative Enhancement Model creates an environment where development
teams can more effectively adjust to changing requirements by segmenting
the software development process into smaller, more manageable parts. Every
iteration improves on the one before it, adding new features and fixing problems
found in earlier stages. Members of the team, stakeholders and end users are
encouraged to collaborate and communicate continuously to make sure the
software meets changing needs and expectations. Until the software is finished
being built, the iteration process is carried out, which involves giving the user
the increments.
Advantages of Iterative Enhancement Model
• Adaptation to changing requirements is made possible by its
flexibility in accomodating modifications and improvement during
each iteration.
• Early software iterations provide clients with functional portions of
the product, facilitating prompt feedback and validation.
• Problems and risks can be identified and addressed early in the
developement process, reduces chances of issue for future stages.
• Feedback and constant client involvement are encouraged to make
sure the finished product lives up to user expectations.
• Every iteration is put through testing and improvement, leading to
higher quality product.
Disadvantages of Iterative Enhancement Model
• Especially in larger projects, managing several iterations at once can
add complexity.
• Higher cost
• Due to constant changes, there may be delays in documentation,
making it more difficult to maintain comprehensive documentation.
 • Continuous customer engagement may not be possible in all
scenarios, which impacts the effectiveness of the model.

Evolutionary Development Models: This model has many of the features of the
incremental model. As in case of the incremental model, the software is developed over a
number of increments. At each increment, a concept (feature) is implemented and is deployed
at the client site. The software is successively refined and feature-enriched until the full
software is realised. The principal idea behind the evolutionary life cycle model is conveyed
by its name. In the incremental development model, complete requirements are first developed,
and the SRS document prepared. In contrast, in the evolutionary model, the requirements, plan,
estimates, and solution evolve over the iterations, rather than fully defined and frozen in a
major up-front specification effort before the development iterations begin. Such evolution is
consistent with the pattern of unpredictable feature discovery and feature changes that take
place in new product development.
Though the evolutionary model can also be viewed as an extension of the waterfall model, but
it incorporates a major paradigm shift that has been widely adopted in many recent life cycle
models. Due to obvious reasons, the evolutionary software development process is sometimes
referred to as design a little, build a little, test a little, deploy a little model. This means that
after the requirements have been specified, the design, build, test, and deployment activities
are iterated.
Advantages
The evolutionary model of development has several advantages. Two important advantages of
using this model are the following:
Effective elicitation of actual customer requirements: In this model, the user gets a chance
to experiment with a partially developed software much before the complete requirements are
developed. Therefore, the evolutionary model helps to accurately elicit user requirements with
the help of feedback obtained on the delivery of different versions of the software. As a result,
the change requests after delivery of the complete software gets substantially reduced.
Easy handling change requests: In this model, handling change requests is easier as no long
term plans are made. Consequently, reworks required due to change requests are normally
much smaller compared to the sequential models.
Disadvantages
The main disadvantages of the successive versions model are as follows:
Feature division into incremental parts can be non-trivial: For many development
projects, especially for small-sized projects, it is difficult to divide the required features
into several parts that can be incrementally implemented and delivered. Further, even
for larger problems, often the features are so interwined and dependent on each other
that even an expert would need considerable effort to plan the incremental deliveries.
Ad hoc design: Since at a time design for only the current increment is done, the design
can become ad hoc without specific attention being paid to maintainability and
optimality. Obviously, for moderate sized problems and for those for which the
customer requirements are clear, the iterative waterfall model can yield a better solution.
V- Model

Agile Model
Comparison of SDLC Model