Software Engineering

Unit-1
(Introduction)
Compiled By
Dr. Vandana Agarwal
Introduction
• Software Engineering is a subdomain of Engineering in which you
learn to develop, designing, testing, and maintenance of software
using a systematic and structured approach
• Software is a program or set of programs containing instructions that
provide desired functionality. Engineering is the process of designing
and building something that serves a particular purpose and finds a
cost-effective solution to problems
Program vs Software
• A program is a set of instructions that are given to a computer in
order to achieve a specific task.
• Program is one of the stages involved in the development of the
software.
• Software is when a program is made available for commercial
business and is properly documented along with its licensing.
Software Product = Program + Documentation + Licensing
• Software Development usually follows a life cycle, which involves the
feasibility study of the project, requirement gathering, development
of a prototype, system design, coding, and testing.
Program vs Software
Program Software
• Small in size. • Large in size.
• Authors himself is user-soul.
• Large number.
• Single developer. Software
• Adopt development. Set of Programs • Team developer.
• Lack proper interface. • Systematic development.
Program
• Large proper Set of • Well define interface.
documentation. instructions
• Well documented
Components of Software :
There are three components of the software: These are : Program, Documentation, and Operating
Procedures.
Program –
A computer program is a list of instructions that tell a computer what to do.

Documentation –
Source information about the product contained in design documents, detailed code comments,
etc.
Operating Procedures –
Set of step-by-step instructions compiled by an organization to help workers carry out complex
routine operations.
Code: the instructions that a computer executes in order to perform a specific task or set of tasks.
Data: the information that the software uses or manipulates.
User interface: the means by which the user interacts with the software, such as buttons, menus,
and text fields.
Libraries: pre-written code that can be reused by the software to perform common tasks.
Documentation: information that explains how to use and maintain the software, such as
user manuals and technical guides.
Test cases: a set of inputs, execution conditions, and expected outputs that are used to test
the software for correctness and reliability.
Configuration files: files that contain settings and parameters that are used to configure
the software to run in a specific environment.
Build and deployment scripts: scripts or tools that are used to build, package, and deploy
the software to different environments.
Metadata: information about the software, such as version numbers, authors, and
copyright information.
All these components are important for software development, testing and deployment.
 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.
• 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.
• 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
applications for improving quality, budget, and time efficiency.
• Software Engineering ensures that the software that has to be built
should be consistent, correct, also on budget, on time, and within the
required requirements.
Characteristics of good software
• A software product can be judged by what it offers and how well it
can be used. This software must satisfy on the following grounds:
• Operational Transitional Maintenance
Characteristics of good software
• Operational This tells us how well the software works in operations. It
can be measured on:
• Budget Usability Efficiency Correctness Functionality
Dependability Security Safety
• Transitional This aspect is important when the software is moved
from one platform to another: Portability Interoperability
Reusability Adaptability
• Maintenance This aspect briefs about how well the software has the
capabilities to maintain itself in the ever-changing environment:
Modularity Maintainability Flexibility Scalability
Software Crisis – Software Engineering

• Software Crisis is a term used in computer science for the difficulty of

writing useful and efficient computer programs in the required time.
The software crisis was due to using the same workforce, same
methods, and same tools even though rapidly increasing software
demand, the complexity of software, and software challenges.
• With the increase in software complexity, many software problems
arise because existing methods were insufficient.
1) In the late 1960’s hardware price were falling but software
price rising.
2) Many software projects failed.
3) Many software project late and over budget.
4) Complexity of software project is increased.
Factors Contributing to Software Crisis:

• Poor project management.

• Lack of adequate training in software engineering.
• Less skilled project members.
• Low productivity improvements.
One of the famous software failures in computer science is
Therac-25. It is a machine that is used to deliver radiation
therapy to Cancer Patients.
Need of Software Engineering

• Large software - It is easier to build a wall than a house or building, likewise, as the size of the
software becomes large, engineering has to step to give it a scientific process.
• Scalability- If the software process were not based on scientific and engineering concepts, it
would be easier to re-create new software than to scale an existing one.
• Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price
of computer and electronic hardware. But, cost of the software remains high if proper process is
not adapted.
• Dynamic Nature- Always growing and adapting nature of the software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where the software engineering plays a
good role.
• Quality Management- Better process of software development provides better and quality
software product
Why study software engineering?

1) Higher productivity.
2) To acquire skills to develop large programs.
3) Ability to solve complex programming problems.
4) Learn techniques of specification design.
5) Better quality programmers
Key Principles of Software Engineering

• Modularity: Breaking the software into smaller, reusable components

that can be developed and tested independently.
• Abstraction: Hiding the implementation details of a component and
exposing only the necessary functionality to other parts of the
software.
• 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.
• Reusability: Creating components that can be used in multiple
projects, which can save time and resources.
Key Principles of Software Engineering
• Maintenance: Regularly updating and improving the software to fix bugs,
add new features, and address security vulnerabilities.
• Testing: Verifying that the software meets its requirements and is free of
bugs.
• Design Patterns: Solving recurring problems in software design by
providing templates for solving them.
• Agile methodologies: Using iterative and incremental development
processes that focus on customer satisfaction, rapid delivery, and flexibility.
• Continuous Integration & Deployment: Continuously integrating the code
changes and deploying them into the production environment
Main Attributes of Software Engineering

• Efficiency: It provides a measure of the resource requirement of a

software product in an efficient way.
• Reliability: It provides the assurance that the product will deliver the
same results when used in similar working environment.
• Reusability: This attribute makes sure that the module can be used in
multiple applications.
• Maintainability: It is the ability of the software to be modified,
repaired, or enhanced easily with changing requirements.
Advantages of Software Engineering

• Improved Quality: By following established software engineering principles

and techniques, the software can be developed with fewer bugs and higher
reliability.
• Increased Productivity: Using modern tools and methodologies can
streamline the development process, allowing developers to be more
productive and complete projects faster.
• Better Maintainability: Software that is designed and developed using
sound software engineering practices is easier to maintain and update over
time.
• Reduced Costs: By identifying and addressing potential problems early in
the development process, software engineering can help to reduce the cost
of fixing bugs and adding new features later on.
• Increased Customer Satisfaction: By involving customers in the
development process and developing software that meets their needs,
software engineering can help to increase customer satisfaction.
• Better Team Collaboration: By using Agile methodologies and continuous
integration, software engineering allows for better collaboration among
development teams.
• Better Scalability: By designing software with scalability in mind, software
engineering can help to ensure that software can handle an increasing
number of users and transactions.
• Better Security: By following the Software Development Life Cycle and
performing security testing, software engineering can help to prevent
security breaches and protect sensitive data.
Disadvantages of Software Engineering

• High upfront costs: Implementing a systematic and disciplined

approach to software development can be resource-intensive and
require a significant investment in tools and training.
• Bureaucratic: Software Engineering can create an environment that is
bureaucratic, with a lot of processes and paperwork, which may slow
down the development process.
• Complexity: With the increase in the number of tools and
methodologies, software engineering can be complex and difficult to
navigate.
• Limited creativity: The focus on structure and process can stifle
creativity and innovation among developers.
• High learning curve: The development process can be complex, and it
requires a lot of learning and training, which can be challenging for
new developers.
• High dependence on tools: Software engineering heavily depends on
the tools, and if the tools are not properly configured or are not
compatible with the software, it can cause issues.
• High maintenance: The software engineering process requires regular
maintenance to ensure that the software is running efficiently, which
can be costly and time-consuming.
A GENERIC VIEW OF PROCESS
SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY
• Software engineering is a layered technology. Any engineering approach must rest on an organizational commitment to
quality. The bedrock that supports software engineering is a quality focus.
• The foundation for software engineering is the process layer. Software engineering process is the glue that holds the
technology layers. Process defines a framework that must be established for effective delivery of software engineering
technology.
• The software forms the basis for management control of software projects and establishes the context in which
1.technical methods are applied, 2.work products are produced, 3. milestones are established, 4
quality is ensured, And change is properly managed.
• A PROCESS FRAMEWORK:
➢ Software process must be established for effective delivery of software engineering technology.
➢ A process framework establishes the foundation for a complete software process by identifying a small number of
framework activities that are applicable to all software projects, regardless of their size or complexity.
➢ The process framework encompasses a set of umbrella activities that are applicable across the entire software process.
➢ Each framework activity is populated by a set of software engineering actions
➢ Each software engineering action is represented by a number of different task sets- each a collection of software
engineering work tasks, related work products, quality assurance points, and project milestones.
• "A process defines who is doing what, when, and how to reach a certain goal
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.
• 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:
• Software specifications: The functionality of the software and constraints on its
operation must be defined.
• Software development: The software to meet the requirement must be
produced.
• Software validation: The software must be validated to ensure that it does what
the customer wants.
• 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. 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. A role/action model: This means the roles of the people involved in the software
process and the activities for which they are responsible.
Similarities Between Software Engineering Process and
Conventional Engineering Process
• Both Software Engineering and Conventional Engineering Processes
become automated after some time.
• Both these processes are making our day-to-day place better.
• Both these processes have a fixed working time.
• Both processes must consist of deeper knowledge.
Differences Between Software Engineering Process and
Conventional Engineering Process
• Software Engineering Process is a process • The conventional Engineering Process is a
that majorly involves computer science, process that majorly involves science and
information technology, and discrete mathematics
mathematics • It is about building cars, machines, hardware,
• It is mainly related to computers, buildings, etc.
programming, and writing codes for building
applications. • It usually applies only known and tested
principles to meet product requirements
• It can involve the application of new and • Product development develops tangible
untested elements in software projects. products (e.g. bridges, buildings).
• Product development develops intangible • Design Requirements are typically well-
products (software). defined upfront.
• Design requirements may change throughout
the development process. • Conventional engineering may be more
expensive to start due to materials and
• Software development is typically less construction but may have lower
expensive to start, but costs may increase maintenance costs.
with maintenance and updates.
SDLC Activities
• Communication
This is the first step where the user initiates the request for a desired
software product. The user contacts the service provider and tries to
negotiate the terms, submits the request to the service providing
organization in writing.
• Requirement Gathering
This step onwards the software development team works to carry on the
project. The team holds discussions with various stakeholders from problem
domain and tries to bring out as much information as possible on their
requirements. The requirements are contemplated and segregated into user
requirements, system requirements and functional requirements. The
requirements are collected using a number of practices as given -
• studying the existing or obsolete system and software,
• conducting interviews of users and developers,
• referring to the database or
• collecting answers from the questionnaires.
• Feasibility Study
After requirement gathering, the team comes up with a rough plan of
software process. At this step the team analyzes if a software can be
designed to fulfill all requirements of the user, and if there is any possibility
of software being no more useful. It is also analyzed if the project is
financially, practically, and technologically feasible for the organization to
take up. There are many algorithms available, which help the developers to
conclude the feasibility of a software project.
• System Analysis
At this step the developers decide a roadmap of their plan and try to bring
up the best software model suitable for the project. System analysis includes
understanding of software product limitations, learning system related
problems or changes to be done in existing systems beforehand, identifying
and addressing the impact of project on organization and personnel etc. The
project team analyzes the scope of the project and plans the schedule and
resources accordingly.
• Software Design
Next step is to bring down whole knowledge of requirements and
analysis on the desk and design the software product. The inputs from
users and information gathered in requirement gathering phase are the
inputs of this step. The output of this step comes in the form of two
designs; logical design, and physical design.
• Coding
This step is also known as programming phase. The implementation of
software design starts in terms of writing program code in the suitable
programming language and developing error-free executable programs
efficiently
• Testing
Software testing is done while coding by the developers and thorough
testing is conducted by testing experts at various levels of code such as
module testing, program testing, product testing, in-house testing, and
testing the product at user’s end. Early discovery of errors and their
remedy is the key to reliable software.
• Integration
Software may need to be integrated with the libraries, databases, and
other program(s). This stage of SDLC is involved in the integration of
software with outer world entities.
• Implementation
This means installing the software on user machines. At times, software
needs post-installation configurations at user end. Software is tested for
portability and adaptability and integration related issues are solved during
implementation.
• Operation and Maintenance
This phase confirms the software operation in terms of more efficiency and
less errors. If required, the users are trained on, or aided with the
documentation on how to operate the software and how to keep the
software operational. The software is maintained timely by updating the
code according to the changes taking place in user end environment or
technology. This phase may face challenges from hidden bugs and real-world
unidentified problems.
The Software Development Paradigm

• Software development paradigm helps a developer to select a

strategy to develop the software. A software development paradigm
has its own set of tools, methods, and procedures, which are
expressed clearly and defines software development life cycle.
CLASSICAL WATERFALL MODEL
The classical waterfall model is the most
obvious way to develop software. Though the
classical waterfall model is elegant and obvious,
it is not a practical model in the sense that it
cannot be used in actual software development
projects. Thus,

this model can be considered to be a

theoretical way of developing software. But all
other life cycle models are essentially derived
from the classical waterfall model. So, in order
to be able to appreciate other life cycle models
it is necessary to learn the classical waterfall
model.
Shortcomings of the classical waterfall model
• The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle
phases. However, in practical development environments, the engineers do
commit a large number of errors in almost every phase of the life cycle.
• The source of the defects can be many: oversight, wrong assumptions, use of
inappropriate technology, communication gap among the project engineers, etc.
These defects usually get detected much later in the life cycle.
• For example, a design defect might go unnoticed till we reach the coding or
testing phase. Once a defect is detected, the engineers need to go back to the
phase where the defect had occurred and redo some of the work done during
that phase and the subsequent phases to correct the defect and its effect on the
later phases.
• Therefore, in any practical software development work, it is not possible to
strictly follow the classical waterfall model.
ITERATIVE WATERFALL MODEL
• Here, we provide feedback paths for error
correction as & when detected later in a phase.
Though errors are inevitable, but it is desirable to
detect them in the same phase in which they
occur. If so, this can reduce the effort to correct the
bug.
• The advantage of this model is that there is a
working model of the system at a very early stage
of development which makes it easier to find
functional or design flaws. Finding issues at an
early stage of development enables to take
corrective measures in a limited budget
• The disadvantage with this SDLC model is that it is
applicable only to large and bulky software
development projects. This is because it is hard to
break a small software system into further small
serviceable increments/modules.
 PRTOTYPING MODEL
• A prototype is a toy implementation of the system.
A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient
performance compared to the actual software.
• A prototype is usually built using several shortcuts.
The shortcuts might involve using inefficient,
inaccurate, or dummy functions. The shortcut
implementation of a function, for example, may
produce the desired results by using a table look-
up instead of performing the actual computations
• A prototype of the actual product is
preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear
EVOLUTIONARY MODEL
• It is also called successive versions model or incremental
model. At first, a simple working model is built. Subsequently
it undergoes functional improvements & we keep on adding
new functions till the desired system is built.
• Applications:
• Large projects where you can easily find modules for
incremental implementation. Often used when the customer
wants to start using the core features rather than waiting for
the full software.
• Also used in object oriented software development
because the system can be easily portioned into units in
terms of objects.
• Advantages:
• User gets a chance to experiment partially developed
system Reduce the error because the core modules get
tested thoroughly.
• Disadvantages:
• It is difficult to divide the problem into several versions that
would be acceptable to the customer which can be
incrementally implemented & delivered.
 SPIRAL MODEL
• The diagrammatic representation of this
model appears like a spiral with many
loops. The exact number of loops in the
spiral is not fixed. Each loop of the spiral
represents a phase of the software
process.
• For example, the innermost loop might
be concerned with feasibility study, the
next loop with requirements
specification, the next one with design,
and so on.
• Each phase in this model is split into four
sectors (or quadrants) as shown in fig.
The following activities are carried out
during each phase of a spiral model.
First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
•Steps are taken to reduce the risks.
For example, if there is a risk that the requirements are inappropriate, a prototype system
may be developed.

Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

Fourth Quadrant (Review and Planning)

•Review the results achieved so far with the customer and plan the next iteration around the spiral.
• Progressively more complete version of the software gets built with each iteration around the
spiral.
• The spiral model is called a meta model since it encompasses all other
life cycle models. Risk handling is inherently built into this model. The
spiral model is suitable for development of technically challenging
software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.
The Agile Model
• The Agile Model was primarily designed to help a project adapt quickly to
change requests. So, the main aim of the Agile model is to facilitate quick
project completion. To accomplish this task, agility is required. Agility is
achieved by fitting the process to the project and removing activities that
may not be essential for a specific project. Also, anything that is a waste of
time and effort is avoided.
• The Agile Model refers to a group of development processes. These
processes share some basic characteristics but do have certain subtle
differences among themselves.
• Agile development requires a high degree of collaboration and
communication among team members, as well as a willingness to adapt to
changing requirements and feedback from customers.
When To Use the Agile Model?

• When frequent modifications need to be made, this method is

implemented.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with the team all the time.
• when the project needs to be delivered quickly.
• Projects with few regulatory requirements or not certain requirements.
• projects utilizing a less-than-strict current methodology
• Those undertakings where the product proprietor is easily reachable
• Flexible project schedules and budgets.
Advantages of the Agile Model
Working through Pair programming produces well-written compact
programs which have fewer errors as compared to programmers
working alone.
It reduces the total development time of the whole project.
Agile development emphasizes face-to-face communication among
team members, leading to better collaboration and understanding of
project goals.
Customer representatives get the idea of updated software products
after each iteration. So, it is easy for him to change any requirement if
needed.
Agile development puts the customer at the center of the development
process, ensuring that the end product meets their needs.
Disadvantages of the Agile Model
The lack of formal documents creates confusion and important decisions
taken during different phases can be misinterpreted at any time by different
team members.
The agile model depends highly on customer interactions so if the customer
is not clear, then the development team can be driven in the wrong
direction.
Agile development models often involve working in short sprints, which can
make it difficult to plan and forecast project timelines and deliverables. This
can lead to delays in the project and can make it difficult to accurately
estimate the costs and resources needed for the project.
Agile development models require a high degree of expertise from team
members, as they need to be able to adapt to changing requirements and
work in an iterative environment. This can be challenging for teams that are
not experienced in agile development practices and can lead to delays and
difficulties in the project.
V-Shaped Model
Importance of V-Model
1. Early Defect Identification
The V-Model contains a testing phase that corresponds to each stage of the development process By
incorporating verification and validation tasks into every stage of the development process, the V-Model
encourages early testing. This lowers the cost and effort needed to remedy problems later in the
development lifecycle by assisting in the early detection and resolution of faults.
2. Prevents “Big Bang” Testing
Testing is frequently done at the very end of the development lifecycle in traditional development models,
which results in a “Big Bang” approach where all testing operations are focused at once. By integrating
testing activities into the development process and encouraging a more progressive and regulated testing
approach, the V-Model prevents this.
3. Improves Cooperation
At every level, the V-Model promotes cooperation between the testing and development teams. Through
this collaboration, project requirements, design choices, and testing methodologies are better understood,
which improves the effectiveness and efficiency of the development process.
4 Improved Quality Assurance
Overall quality assurance is enhanced by the V-Model, which incorporates testing operations at every level.
Before the program reaches the final deployment stage, it makes sure that it satisfies the requirements and
goes through a strict validation and verification process
When to Use of V-Model?
• Where requirements are clearly defined and fixed.
• The V-Model is used when ample technical resources are available
with technical expertise.
• Small to medium-sized projects with set and specified needs are
recommended to use the V-shaped model.
• Since it is challenging to keep stable needs in large projects, the
project should be small.
Advantages of V-Model

• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle
thereby enhancing the probability of building an error-free and good quality
product.
• It enables project management to track progress accurately.
• Emphasis on Testing: The V-Model places a strong emphasis on testing, which
helps to ensure the quality and reliability of the software.
• Improved Traceability: The V-Model provides a clear link between the
requirements and the final product, making it easier to trace and manage
changes to the software.
• Better Communication: The clear structure of the V-Model helps to improve
communication between the customer and the development team.
Disadvantages of V-Model

• It is not good for complex and object-oriented projects.

• It is not suitable for projects where requirements are not clear and contain
a high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.
• Inflexibility: The V-Model is a linear and sequential model, which can make
it difficult to adapt to changing requirements or unexpected events.
• Time-Consuming: The V-Model can be time-consuming, as it requires a lot
of documentation and testing.
• Overreliance on Documentation: The V-Model places a strong emphasis on
documentation, which can lead to an overreliance on documentation at
the expense of actual development work
Comparison of different life-cycle models
• The classical waterfall model can be considered as the basic model and all
other life cycle models as embellishments of this model. However, the
classical waterfall model cannot be used in practical development projects,
since this model supports no mechanism to handle the errors committed
during any of the phases.
• This problem is overcome in the iterative waterfall model. The iterative
waterfall model is probably the most widely used software development
model evolved so far. This model is simple to understand and use. However
this model is suitable only for well-understood problems; it is not suitable
for very large projects and for projects that are subject to many risks.
• The prototyping model is suitable for projects for which either the user
requirements or the underlying technical aspects are not well understood.
This model is especially popular for development of the user-interface part
of the projects.
• The evolutionary approach is suitable for large problems which can be
decomposed into a set of modules for incremental development and
delivery. This model is also widely used for object oriented
development projects. Of course, this model can only be used if the
incremental delivery of the system is acceptable to the customer.
• The spiral model is called a meta model since it encompasses all other
life cycle models. Risk handling is inherently built into this model. The
spiral model is suitable for development of technically challenging
software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.