Introduction

❖ The term software engineering is composed of two words, software and

engineering.
❖ Software Engineering is a framework for building software and is an
engineering approach to software development.
❖ Software Engineering as an engineering branch associated with the
development of software product using well-defined scientific principles,
methods and procedures.
❖ Software is defined as:
Instructions + Data Structures + Documents
❖ IEEE defines software engineering as:
The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software.
Need of Software Engineering
➔ Large software - It is easier to build a wall than to a house or building, likewise, as
the size of software become 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 the cost of software
remains high if proper process is not adapted.
➔ Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which the user works.
➔ Quality Management- Better process of software development provides better and
quality software product.
Characteristics of good Software
This software must satisfy on the following grounds:
➔ Operational: Budget, Usability,Efficiency, Correctness, Functionality,
Dependability, Security, Safety
➔ Transitional: Portability, Interoperability, Reusability, Adaptability
➔ Maintenance: Modularity, Maintainability, Flexibility, Scalability
NATURE OF SOFTWARE
The various categories of software are:
❖ System software
❖ Application software
❖ Engineering and scientific software
❖ Embedded software
❖ Product-line software
❖ Web-applications
❖ Artificial intelligence software
Characteristics of a good software engineer

❖ Exposure to systematic methods

❖ Good technical knowledge of the project range (Domain knowledge)
❖ Good programming abilities
❖ Good communication skills
❖ High motivation.
Programs Software Products
Programs are developed by individuals A software product is usually developed by a group of
for their personal use engineers working as a team.

Usually small in size Usually large in size

Single user Large number of users

Single developer Team of developers

Lack proper documentation Good documentation support

Adhoc development Systematic development

Lack of user interface Good user interface

Have limited functionality Exhibit more functionality

Failure Curve for Hardware
Failure Curve for Software
Software Myths
❖ Computers are more reliable than the devices they have replaced
❖ Software is easy to change
❖ If software development gets behind scheduled, adding more programmers will
❖ put the development back on track
❖ Testing software removes all the errors
❖ Software with more features is better software
❖ Aim has now shifted to develop working programs
Software Crisis
Size: Software is becoming larger and more complex with the growing complexity
Quality: Many software products have poor quality,
Cost: Software development is costly
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
Attributes of Good Software
❖ Maintainability: Software must evolve to meet changing needs.
❖ Dependability: Software must be trustworthy.
❖ Efficiency: Software should not make wasteful use of system resources.
❖ Usability: Software must be usable by the users for which it was designed.
Key Challenges facing Software Engineering
❖ Legacy systems: Old, valuable systems must be maintained and updated
❖ Heterogeneity: Systems are distributed and include a mix of hardware and software
❖ Delivery: There is increasing pressure for faster delivery of software.
Professional and Ethical Responsibility
❖ Software engineering must have
❖ Technical skills.
❖ Honest and ethically responsible way
❖ Respected as professionals
Software Development Issues
❖ Client/Customer View: What do the clients and the customers expect from
the software.
❖ The user viewpoint: The users and the client/customers can be different,
what do the users expect out of the software.
❖ Project Teams
❖ Team building
❖ Technical competencies
❖ Communication
Software Development Roles and Processes
SDLC
❖ Software development life cycle (SDLC) is a structured process that is used to design,
develop, and test good-quality software.
❖ SDLC is a process followed for software building within a software organization.
❖ The Software Development Life Cycle (SDLC) is a well-structured process that guides
software development projects from start to finish.
❖ It provides a clear framework for planning, building, and maintaining software, ensuring
that development is systematic and meets quality standards.
Why SDLC is important?

❖ It provides a standardized framework that defines activities and deliverables

❖ It aids in project planning, estimating, and scheduling
❖ It makes project tracking and control easier
❖ It increases visibility on all aspects of the life cycle to all stakeholders involved
in the development process
❖ It increases the speed of development
❖ It improves client relations
❖ It decreases project risks
❖ It decreases project management expenses and the overall cost of production
7 phases of SDLC
❖ Phase 1: Planning
❖ Phase 2: Requirements Analysis
❖ Phase 3: Design
❖ Phase 4: Coding
❖ Phase 5: Testing
❖ Phase 6: Deployment
❖ Phase 7: Maintenance
SDLC
Stage1: Planning and requirement analysis
❖ Business analyst and Project organizer set up a meeting with the client to gather all the data like
➢ what the customer wants to build,
➢ who will be the end user,
➢ what is the objective of the product.
❖ Planning for the quality assurance requirements and identifications of the risks associated with
the projects is also done at this stage.
Stage2: Defining Requirements
❖ "SRS"- Software Requirement Specification document which contains all the product
requirements to be constructed and developed during the project life cycle.
Stage3: Designing the Software
❖ SRS is a reference for software designers to come up with the best architecture for the software.
SDLC
Stage 4: Developing the project
❖ The actual development begins, and the programming is built.
❖ The implementation of design begins concerning writing code.
❖ Developers have to follow the coding guidelines described by their management and
programming tools like compilers, interpreters, debuggers
Stage 5: Testing
❖ Software is tested against the requirements to make sure that the products are solving
the needs addressed and gathered during the requirements stage.
❖ During this stage:
➢ unit testing,
➢ integration testing,
➢ system testing,
➢ acceptance testing
SDLC
Stage 6: Deployment
❖ Once the software is certified, and no bugs or errors are stated, then it is deployed.
Stage 7: Maintenance
❖ The client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.
❖ This procedure where the care is taken for the developed product is known as
maintenance.
Benefits of SDLC

❖ Increased visibility of the development process for all stakeholders involved

❖ More efficient estimation, planning, and scheduling
❖ Improved risk management and cost estimation
❖ A systematic approach to delivering software that meets customer expectations
and improves satisfaction
Life cycle model

❖ A software life cycle model is a descriptive and diagrammatic representation of the software
life cycle.
❖ A life cycle model represents all the activities required to make a software product transit
through its life cycle phases.
❖ During any life cycle phase, more than one activity may also be carried out.
Need for a software life cycle Model
❖ The development team must identify a suitable life cycle model to develop a
project..
❖ Without using of a particular life cycle model the development of a software
product may lead to project failure.
Software Development Life Cycle Models
❖ Different types of SDLC Models are:
➢ Waterfall Model
➢ Spiral Model
➢ V-Model
➢ Incremental Model
➢ RAD Model
➢ Iterative Model
➢ Prototype model
➢ Agile Model
Waterfall Model
Waterfall Model
❖ The waterfall model is a very common and traditional SDLC model or software
process model.
❖ This model is known as the waterfall model, because of the cascade from one
phase to another phase.
❖ The phases are cascade in nature, where the output of one phase is the input to
the next one. Each phase performs a set of activities.
❖ Waterfall model has the following phases:
➢ Feasibility Study /Requirements Analysis and Specification
➢ Design
➢ Coding and Unit Testing
➢ Integration and System Testing, and
➢ Maintenance
Waterfall Model: Feasibility Study /Requirements Analysis and Specification

❖ The main aim of feasibility study is to determine whether the project is financially
and technically feasible or not, to develop the product.
❖ The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely
➢ Requirements gathering and analysis, and
➢ Requirements specification
Waterfall Model: 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 by using some
programming language.
❖ Two distinctly different approaches are available:
➢ Architectural Design approach: It involves:
■ Identifying the software components.
■ Decomposing the software components into modules.
■ Specifying the interconnection between the various components.
➢ Detailed Design approach: It is deals with all details for the implementation i.e.
procedures to process the algorithms, data structures to be used, etc.
Waterfall Model: Coding and Unit Testing

❖ The purpose of the coding and unit testing phase (sometimes called the
implementation phase) of software development is to translate the software
design into source code.
❖ The end of this phase, each unit module is tested against each unit test plan.
❖ Output of this phase is:
➢ Program code or source code
➢ Unit test report
Waterfall Model:Integration and System Testing

❖ Integration of different modules is undertaken once they have been coded and unit
tested.
❖ During the integration and system testing phase, the modules are integrated.
❖ System testing usually consists of three different kinds of testing activities:-
➢ α – testing: It is the system testing performed by the development team.
➢ β – Testing: It is the system testing performed by a friendly set of customers.
➢ Acceptance testing: System testing performed by the customer after the
product delivery to accepted or rejected the delivered product.
Waterfall Model: Maintenance

❖ The product is ready and it is delivered to the client.

❖ Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself.
❖ The relative effort of development of a typical software product to its
maintenance effort is roughly in the 40:60 ratio.
❖ Maintenance involves performing any one or more of the following three kinds
of activities:
➢ corrective maintenance
➢ perfective maintenance
➢ adaptive maintenance
Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.

Improving the implementation of the system, and enhancing the functionalities of the system
according to the customer’s requirements is called perfective maintenance.

Porting the software to work in a new environment. For e.g: porting may be required to get
the software to work on a new computer platform or with a new operating system is called
adaptive maintenance.
Advantages of Waterfall Model Disadvantages of waterfall model

Linear mode Difficult to define all requirements at the

beginning of a project

Relatively easy to understand and Not suitable for accommodating any

manage. change

Systematic and sequential Not suitable to large projects

Simple one Involves heavy documentation

Proper documentation Cannot go backward in the SDLC

No risk analysis
Iterative Waterfall Model
Iterative Waterfall Model
❖ The weaknesses of the waterfall model, Iterative development is the heart of
acyclic software development process.
❖ It starts with feasibility study and ends with deployment (maintenance) with the
cyclic interactions in between phases.
❖ The feedback paths allow for correction of the errors done during a phase.
❖ The principle of detecting errors as close to its point of introduction as possible.
This is known as “Phase Containment of Errors”.
❖ To achieve this review is done after completion of each phase.
Spiral Model
Spiral Model
❖ The spiral model, originally proposed by Barry Boehm.
❖ Main objective is to analyze the risks involved in the software project.
❖ Combines the features of prototyping model, evolutionary and iterative
waterfall model. Hence this model is also called meta 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.
❖ Each phase in this model is split into four sectors (or quadrants) The following
activities are carried out during each phase of a spiral model.
➢ First quadrant (Objective Setting)
➢ Second Quadrant (Risk Assessment and Reduction)
➢ Third Quadrant (Development and Validation)
➢ Fourth Quadrant (Review and Planning)
Spiral Model
❖ Advantages:
➢ For large, complex and expensive projects.
➢ If the software associated with risk.
➢ Re-evaluation after each step
❖ Disadvantages:
➢ Assessment and resolution of project risks is not an easy task.
➢ Difficult to estimate budget and schedule in the beginning.
Incremental Model or Evolutionary Model
❖ Also called successive versions model.
❖ The software is first broken down into several modules which can be incrementally
constructed and delivered.
❖ The development team first develops the core modules of the system.
❖ Each successive version of the product is fully functioning capable of performing
more useful work than the previous version.
❖ The user gets a chance to experiment with particularly developed software much
before the complete version of the software is ready.
❖ This model is useful only for very large products.
When Use the Incremental Model

❖ Changing Requirements
❖ Mitigating Risks
❖ Early Feedback
❖ Complex Systems
❖ Short Time-to-Market
❖ Parallel Development
❖ Budget Constraints
❖ Evolving Solutions
❖ Customer Collaboration
❖ Flexibility
Advantages
❖ Problem understanding increases through successive refinements
❖ Performs cost benefit analysis before enhancing software with capabilities
❖ Does not involve high complexity rate
❖ Early feedback is generated

Disadvantages
❖ Requires planning at the management and technical level.
❖ Becomes invalid when there is time constraint in the project schedu
Prototyping Model
The prototype model in software engineering involves developing a basic version
of the system, called a prototype, to gather feedback and refine requirements.

It allows developers, stakeholders, and users to explore ideas, test functionalities,

and visualize the final product.
Requirement Gathering:
❖ Prototyping starts with an initial requirement and gathering phase.
❖ The functionalities required for the product are gathered.

Quick Design:
❖ A quick design is carried out and a prototype is build.
❖ A new plan is created from gathered
❖ Requirements for the prototype to be built.

Prototype creation:
❖ Based on the design issues the trial product is created.
Customer Evaluation:
❖ The developed prototype is submitted to the customer for evaluation.
❖ Based on the customer feedback we may go for development or again go for
the redesign as per customer demand.

Prototype refinement:
❖ Based on the information.

The rest of the phases for development are similar to the waterfall model/
iterative waterfall model.
When Use Prototype Model

❖ User requirements are not complete.

❖ Technical issues are not clear/Feature Validation
❖ Risky or Complex Projects
❖ Quick Iterations Needed
Advantages
❖ Suitable for large systems.
❖ Customer communication is available.
❖ Quality of software is good.
❖ It helps to identifying the requirements.

Disadvantages
❖ It is very difficult to predict how the system will work after development.
❖ This model is time consuming.
Agile Model
❖ In Waterfall model the main difficulties included handling change requests
from customers during project development and the high cost and time
required to incorporate these changes.
❖ Agile methods break tasks into smaller iterations, or parts do not directly
involve long term planning.
❖ The project scope and requirements are laid down at the beginning of the
development process.
❖ Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.
Phases of Agile Model
Following are the phases in the Agile model are as follows:
❖ Requirements gathering
❖ Design the requirements
❖ Construction/ iteration
❖ Testing/ Quality assurance
❖ Deployment
❖ Feedback
Requirements gathering: You must define the requirements. You should explain business
opportunities and plan the time and effort needed to build the project. Based on this
information, you can evaluate technical and economic feasibility.

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

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

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

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

Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.
Agility principles
❖ Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
❖ Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
❖ Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
❖ Business people and developers must work together daily throughout the
project.
❖ Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
❖ The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
❖ Working software is the primary measure of progress.
❖ Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
❖ Continuous attention to technical excellence and good design enhances
agility.
❖ Simplicity—the art of maximizing the amount of work not done—is essential.
❖ The best architectures, requirements, and designs emerge from self–
organizing teams.
❖ At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
RAPID APPLICATION DEVELOPMENT (RAD)

❖ The RAD model was formally developed by James Martin in 1991

❖ Overcome the rigidity of the waterfall model.
❖ Features of both prototyping and evolutionary models deploys an evolutionary
delivery model to obtain and customer feedbacks on incrementally delivered
versions.
❖ The major goals of the RAD model are as follows:
➢ To decrease the time taken and the cost incurred to develop software systems.
➢ To limit the costs of accommodating change requests.
➢ T o reduce the communication gap between the customer and the developers.
RAD Requirements

❖ Experienced team members

❖ Engaged stakeholders
❖ Short timelines
❖ Effective tools
Steps in Rapid Application Development

Define project requirements: The developers, end users, clients, and other stakeholders work together to define
the scope and requirements for the product. This includes timeline, budget, goals, expectations.

Create prototype: Developers build an initial prototype that fulfills the requirements established in step one. The
ultimate goal of this step is to produce a working prototype, though only certain aspects of it may be functional.

Gather feedback: The client and/or end users provide feedback and request changes to prototype elements
individually or the project overall. Developers then take this iterate on the previous prototype to incorporate the
necessary changes. This cycle continues until everyone is satisfied with the prototype.

Finalize and implement the product: The final prototype is pushed into development. The team tests the
software for bugs and fixes problems as they arise. Once a stable version is ready for launch, the system
changeover and user training commences.
Principles of Rapid Application Development (RAD)

RAD principles focus on providing the main benefits of rapid web application development
method:

❖ Increased development speed

❖ Low cost
❖ High quality
❖ Time minimization
❖ Prototyping
❖ Cyclic development
❖ Iterative approach to development
❖ Combining testing and system development
Tools and Technologies in RAD
Real-World Examples
 Advantages Disadvantages

Flexible and adaptable to changes It can’t be used for smaller projects

It is useful when you have to reduce the overall project risk Not all application is compatible with RAD

It is adaptable and flexible to changes When technical risk is high, it is not suitable

It is easier to transfer deliverables as scripts, high-level If developers are not committed to delivering software on
abstractions and intermediate codes are used time, RAD projects can fail
Due to code generators and code reuse, there is a Reduced features due to time boxing, where features are
reduction of manual coding pushed to a later version to finish a release in short period
Reduced scalability occurs because a RAD developed
Due to prototyping in nature, there is a possibility of lesser
application begins as a prototype and evolves into a
defects
finished application
Progress and problems accustomed are hard to track as
Each phase in RAD delivers highest priority functionality to
such there is no documentation to demonstrate what has
client
been done
With less people, productivity can be increased in short
Requires highly skilled designers or developers
time
 RAD Agile

Small projects with narrow Complex projects with large

Best for
scopes scopes

Timeline Short Long

Defined early, adjusted during Refined as the project

Project requirements
prototyping progresses
Prototypes presented before Working product presented
Stakeholder review
development during development

Feedback Collected for each prototype Collected continuously

Extreme programming (XP)

❖ Extreme programming (XP) is an important process model under the agile

umbrella and was proposed by Kent Beck in 1999.
❖ Extreme programming optimizes software engineering practices that speed up the
software development lifecycle.
❖ Extreme programming (XP) is defined as a software engineering paradigm
that uses an Agile-based software development framework to optimize the
software development process by creating good quality programs while
considering constantly shifting end-user demands.
❖ XP is built upon values, principles, and practices, and its goal is to allow small
to mid-sized teams to produce high-quality software and adapt to evolving
and changing requirements.
❖ XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun
way to develop a software.
XP Methodology
When XP Applicable

❖ Dynamically changing software requirements

❖ Risks caused by fixed-time projects using new technology
❖ Small, co-located extended development team
❖ The technology you are using allows for automated unit and functional tests
Principles of Extreme programming

❖ Constant and early feedback

❖ Assumed simplicity
❖ Incremental changes
❖ Embracing change
❖ Quality work