Introduction to Software

Engineering
Module 1
Topics
● Nature of Software
● Software Engineering
● Software Process
● Capability Maturity Model (CMM) Generic Process Model
● Prescriptive Process Models: The Waterfall Model, V-model, Incremental
Process Models, Evolutionary Process Models, Concurrent Models
● Agile process, Agility Principles
● Extreme Programming (XP)
● Scrum
● Kanban model
Note : Self-learning Topics: Personal and Team Process Models
Software

Software is:
(1) instructions (computer programs) that when executed provide desired
features, function, and performance;
(2) data structures that enable the programs to adequately manipulate
information;
(3) descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.
The Nature of Software
Software is fundamentally different from hardware and has unique
characteristics and challenges.
• Software is a Product and a Vehicle
• It serves as a product (e.g., applications, systems) and as a vehicle for delivering a product
(e.g., control software in embedded systems).
• Software is Intangible
• Software is not a physical product; it cannot be seen or touched like hardware.
• It exists as code, documentation, and logical structures.
• Software is Engineered, Not Manufactured
• Unlike hardware, which is assembled and produced, software is developed through design,
coding, and testing.
• The cost is largely in development, not replication—copying software is virtually free.
• Software Doesn’t Wear Out
• Software does not degrade over time like physical components.
• However, it can deteriorate due to changes, such as updates, patches, or integration—this is
called software entropy.
• Most Software is Custom-Built
• While reusable components exist, a large portion of software is still custom-developed to meet
specific needs.
• This increases complexity and reduces standardization.
• Software is Complex
• Software systems can have millions of logical paths.
• Managing this complexity is one of the core goals of software engineering.
• Software is Easy to Change, Yet Risky
• Modifying software is comparatively easy, but every change can introduce bugs and affect
other parts of the system unexpectedly.
Types of Software :

1. System software (Windows OS, Linux Kernel)

2. Application software (Microsoft Word, Google Chrome)
3. Engineering/scientific software (MATLAB, AutoCAD)
4. Embedded software (Software in Washing Machines, Firmware in Smart
TVs)
5. Product-line software (Microsoft Office Suite, Adobe Creative Cloud)
6. Web applications(Gmail, Amazon)
7. AI software (ChatGPT, Google Translate)
Challenges in Software Development (SDLC)

Challenge Description

Changing Requirements Frequent changes increase cost and delay development.

Software Complexity Large systems are difficult to design, develop, and

maintain.

Time Constraints Short deadlines may reduce software quality.

Budget Constraints Limited resources affect project execution.

Software Quality Ensuring reliability, efficiency, and correctness is

challenging.

Security Protecting software from cyber threats is essential.

Technology Changes Continuous learning is required to keep up with new
technologies.

System Integration New software must work with existing systems.

Maintenance Continuous updates and bug fixes are required after

deployment.

Communication Poor coordination leads to misunderstandings and delays.

Testing & Debugging Detecting and fixing defects is time-consuming.

Performance & Scalability Software must perform well under heavy user loads.

Risk Management Projects must handle technical, financial, and schedule-

related risks.

Documentation Proper documentation simplifies maintenance and future

development.

User Satisfaction Software should meet customer needs and provide a good
user experience.
phases in SDLC

requirement gathering
requirement analysis
planning
designing
implementation
testing - debugging
deployment
maintenance
The Software Process

● A software process is a structured set of activities required to

develop a software system from requirement gathering to maintenance.
● The overall framework or lifecycle.
● Describes what needs to be done.
● Approach : Generic / perspective / Agile
● Examples:
○ Waterfall Model
○ Agile Process
○ Spiral Model
○ V-Model
Generic Process Framework
● A generic process framework for software engineering
encompasses five activities:
○ Communication ( req. gathering + analysis )
○ Planning
○ Modeling (designing )
○ Construction ( implementation + testing )
○ Deployment. ( deploy + maintenance )
Communication.
• This is where requirements are gathered.
• Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other
stakeholders).
• Involves interaction with customers, stakeholders, and users.
• Focuses on understanding what the software must do.
• Techniques used:
• Interviews, surveys, requirement workshops, use cases.
• Goal:
• The intent is to understand stakeholders’ objectives for the project and to
gather requirements that help define software features and functions.
*A stakeholder is anyone who has a stake in the successful outcome of the project—business
managers, end users, software engineers, support people, and so forth.
Planning
• Any complicated journey can be simplified if a map exists.
• A software project is a complicated journey, and the
planning activity creates a ―map‖ that helps guide the
team as it makes the journey.
• The map-called a software project plan :
• Defines the software engineering work by describing the technical
tasks to be conducted, the risks that are likely, the resources that
will be required, the work products to be produced, and a work
schedule.
• Goal:
• Lay a foundation for controlled, timely, and cost-effective development.
Modeling
• This is the design phase.
• A software engineer creates models to better understand
software requirements and the design that will achieve those
requirements.
• Develops models of the software’s data, architecture, user
interfaces, and behavior.
• Can involve UML diagrams, ER models, or wireframes.
• Focus is on how the system will fulfill the requirements.
• Goal:
• Translate "what needs to be done" into "how it will be done".
Construction
• Design is built : Developers write source code based on
design models.
• This activity combines code generation (either manual or
automated) and the testing that is required to uncover
errors in the code.
• Unit testing, integration testing, and debugging occur here.
• Emphasis on writing clean, functional, and testable code.
• Goal:
• Build the actual working software.
Deployment
• The software (as a complete entity or as a partially
completed increment) is delivered to the customer who
evaluates the delivered product and provides feedback
based on the evaluation.
• Includes installation, training, user feedback, and
maintenance.
• Goal:
• Get the product into the hands of users and support it post-release.
Generic Process Model
● A generic process framework for
software engineering defines five
framework activities-communication,
planning, modeling, construction, and
deployment.
● In addition, a set of umbrella activities-
project tracking and control, risk
management, quality assurance,
configuration management, technical
reviews, and others—are applied
throughout the process.

Fig : A software process framework

● The Generic Process Model is a high-level framework that defines the basic
activities involved in any software development project.
○ Abstract and universal
○ Applicable to all types of projects
○ Not tied to any specific methodology
● Core Activities:
○ Communication – Gathering requirements
○ Planning – Estimating resources, schedules
○ Modeling – Design of system and data
○ Construction – Coding and testing
○ Deployment – Delivery and support
Different Generic models Process Flow
● process flow : it describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time. A linear process
flow executes
each of the five
framework
activities in
sequence,
Fig : Linear process flow beginning with
communication
and culminating
with deployment

An iterative
process flow
repeats one or
more of the
activities before
proceeding to the
Fig : iterative process flow next.
 Fig : Evolutionary process flow Fig : Parallel process flow

An evolutionary process flow executes A parallel process flow executes one or more
the activities in a ―circular‖ manner. Each activities in parallel with other activities (e.g.,
circuit through the five activities leads to a modeling for one aspect of the software might be
more complete version of the software executed in parallel with construction of another
aspect of the software).
Prescriptive Process Models
• Prescriptive process models define a predefined set of process elements and
a predictable process work flow.
• Prescriptive models provide detailed steps, rules, and practices for how software development
should be carried out — based on the generic model but with specific guidance.
• Examples of Prescriptive Models:
• Waterfall Model
• V-Model
• Incremental Model
• Evolutionary Process Model
• Concurrent Development Model
The Waterfall Model
● The waterfall model, sometimes called the linear sequential model, suggests a
systematic, sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modeling, construction,
and deployment, culminating in ongoing support of the completed software.
● Each phase must be completed before the next starts.
● Suitable for projects with clear, unchanging requirements.

Fig : The waterfall model

• Requirement Gathering and analysis :
• All possible requirements of the system to be developed are captured in this phase and

documented in a requirement specification document.

• System Design :
• The requirement specifications from first phase are studied in this phase and the system

design is prepared. This system design helps in specifying hardware and system requirements

and helps in defining the overall system architecture.

• Implementation :
• With inputs from the system design, the system is first developed in small programs called

units, which are integrated in the next phase. Each unit is developed and tested for its

functionality, which is referred to as Unit Testing.

• Integration and Testing :
• All the units developed in the implementation phase are integrated into a system after testing

of each unit. Post integration the entire system is tested for any faults and failures.

• Deployment of system :
• Once the functional and non-functional testing is done; the product is deployed in the
customer environment or released into the market.

• Maintenance :
• There are some issues which come up in the client environment. To fix those issues, patches
are released. Also to enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.
When to use Waterfall model?

● Requirements are very well documented, clear and fixed.

● Product definition is stable.
● Technology is understood and is not dynamic.
● There are no ambiguous requirements.
● Ample resources with required expertise are available to support the product.
● The project is short.
Waterfall Model - Advantages

● Simple and easy to understand and use

● Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
● Phases are processed and completed one at a time.
● Works well for smaller projects where requirements are very well understood.
● Clearly defined stages.
● Well understood milestones.
● Easy to arrange tasks.
● Process and results are well documented.
Waterfall Model - Disadvantages
• The problems that are sometimes encountered when the waterfall
model is applied are:

1. Real projects rarely follow the sequential work flow that the model proposes.
2. It is often difficult for the customer to state all requirements explicitly at the
beginning of most projects.
3. The customer must have patience because a working version of the program(s)
will not be available until late in the project time span.
4. Major blunders may not be detected until the working program is reviewed.
Waterfall Model – Real-World Example

Example: Banking System for Fixed Deposits (FD) Management

● Why? Requirements are well-defined and unlikely to change.
● How it works:
○ Gather all requirements → Design the complete system → Code it → Test it → Deploy it →
Maintain it.
● Once a phase is complete, you don't go back.
Used in:
● Government projects
● Military applications
● Financial software with strict regulations
V-Model

• V-Model :
• Verification and Validation model is a
software development process that
extends the waterfall model by
emphasizing verification and validation
steps.

• It's called the V-Model because the

process steps form a ―V‖shape, where
each development stage is associated Fig : The V-model

with a corresponding testing phase

• Definition : The V-Model is a Software Development Life Cycle (SDLC)
model in which every development phase is paired with a corresponding
testing phase, ensuring that verification and validation are performed
systematically to produce high-quality software.
• The left side of the V represents Verification (Planning and Designing).
• The right side represents Validation (Testing).
• Coding is done at the bottom of the V.
• Verification phase
• Requirement analysis, system design, Architecture design, Module design

• Validation Phase
• unit testing,Integration,system,acceptance testing
V-Model Process

● Requirements Analysis
○ Verification:
■ User requirements are collected and analyzed.
■ The system's functionalities are understood and documented.
○ Validation:
■ User acceptance tests (UAT) are planned.
● System Design
○ Verification:
■ High-level design is created, outlining the system architecture and
components.
○ Validation:
■ System tests are planned based on the high-level design
● Architectural Design
○ Verification:
■ Detailed design of modules and their interactions is created.
○ Validation:
■ Integration tests are planned for interactions between modules.
● Module Design
○ Verification:
■ Detailed design of individual modules is created, specifying internal workings
and logic.
○ Validation:
■ Unit tests are planned for individual modules.
● Coding
○ The actual code is written according to the module designs.
● Testing
○ Unit Testing
■ Each module is tested individually to ensure it functions correctly.
○ Integration Testing
■ Modules are integrated and tested together to ensure they work as a system.
○ System Testing
■ The complete system is tested to ensure it meets the specified requirements.
○ User Acceptance Testing (UAT)
■ The final product is tested in the user environment to ensure it meets user needs and
expectations
When to use V-Model?

● Requirements are well defined, clearly documented and fixed.

● Product definition is stable.
● Technology is not dynamic and is well understood by the project team.
● There are no ambiguous or undefined requirements.
● The project is short.
● Examples:
○ Banking software
○ Hospital management systems
○ Railway reservation systems
○ Defence systems
○ Aerospace software
Advantages of V-model
● In the V-model, much of the testing activities (test case design, test planning, etc.) are carried out in

parallel with the development activities.

○ Therefore, before testing phase starts significant part of the testing activities, including test

case design and test planning, is already complete.

○ Therefore, this model usually leads to a shorter testing phase and an overall faster product

development as compared to the iterative model.

● Since test cases are designed when the schedule pressure has not built up, the quality of the test

cases are usually better.

● The test team is reasonably kept occupied throughout the development cycle in contrast to the

waterfall model where the testers are active only during the testing phase.

○ This leads to more efficient manpower utilization.

● In the V-model, the test team is associated with the project from the
beginning.
○ Therefore they build up a good understanding of the development artifacts, and this in turn,
helps them to carry out effective testing of the software
Disadvantages of V-model

● Not a good model for complex and object-oriented projects.

● Poor model for long and ongoing projects.
● Not suitable for the projects where requirements are at a moderate to high
risk of changing.
● Once an application is in the testing stage, it is difficult to go back and change
a functionality.
● No working software is produced until late during the life cycle.
V-Model – Real-World Example

Example: Airline Reservation System

● Why? Every phase of development must be verified and validated.
● How it works:
○ For every stage of development (e.g., system requirement, design), there's a corresponding
test (e.g., system test, unit test).
● Strict testing at every level.
Incremental Process Models
● In the incremental life cycle model, the
software is developed in increment.
● In this life cycle model, first the
requirements are split into a set of
increments.
● The first increment is a simple working
system implementing only a few basic
features.
● Over successive iterations, successive
increments are implemented and
delivered to the customer until the
desired system is realized. Fig : The Incremental Process model
● Definition : The Incremental Process Model is an SDLC model in which the
software is developed, tested, and delivered in small parts called increments.
Each increment adds new functionality until the complete software is ready.

Fig : Incremental software development

When to use incremental process model?
Advantages of Incremental Model

● Error reduction:
○ The core modules are used by the customer from the beginning and therefore these get tested
thoroughly. This reduces chances of errors in the core modules of the final product, leading to
greater reliability of the software

● Incremental resource deployment:

○ This model obviates the need for the customer to commit large resources at one go for
development of the system. It also saves the developing organization from deploying large
resources and manpower for a project in one go
Disadvantages of Incremental Model
Incremental Model – Real-World Example

Example: Microsoft Word

● Why? Not all features are needed at once; updates can be released in parts.
● How it works:
○ Version 1.0 → Just text editing
○ Version 1.1 → Add spell check
○ Version 1.2 → Add formatting and styles
○ And so on...
Used in:
● Web and mobile apps
● Products with a long roadmap
● Systems requiring frequent updates
Incremental Model vs Waterfall Model

Waterfall Model Incremental Model

Entire software delivered at once Software delivered in parts

Customer waits until the end Customer receives early versions

Changes are difficult Changes are easier

Higher risk Lower risk

Testing after complete development Testing in every increment

Evolutionary Process Model

● 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 realized.
● Definition : The software is developed through multiple versions that are
continuously refined and improved based on customer feedback and
changing requirements.
Fig : The Evolutionary Model
Advantages of the Evolutionary Model

● 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
● 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 intertwined 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
Evolutionary Model – Real-World Example
Example: Google Search Engine (in early stages)
● Why? Requirements kept changing based on user behavior and market
feedback.
● How it works:
○ Initial version → Basic keyword search
○ Next iteration → Added image search, voice search, smart snippets, etc., based on user
interaction and feedback
Used in:
● Startups
● AI/ML-based applications
● Research and experimental products
 Incremental Vs Evolutionary Process Model
Incremental Process Model Evolutionary Process Model

Software is developed in small increments Software is developed through continuous

(modules). refinement based on user feedback.

Requirements are well-defined and stable Requirements are unclear or expected to change.
from the beginning.

Each increment adds new features to the Each version improves or modifies the existing
existing software. software based on feedback.

Customer feedback is useful but not the main Customer feedback is the main driving force.
focus.

Goal is to deliver the complete system in Goal is to gradually evolve the software into the final
planned stages. product.

Examples: Banking System, Library Examples: Mobile Apps, AI Applications, Social

Management System, College ERP. Media Platforms.
Concurrent Models

● The Concurrent Development Model is a software development approach

where multiple phases (e.g., design, coding, testing) occur simultaneously.
● This model emphasizes the overlapping of various project stages, which
allows teams to work on different parts of the project at the same time.
● This model supports the concept of concurrency in that design, code, test and
another related phase occur simultaneously.
Concurrent Models Process

● Each activity (like Design, Coding, Testing) can be in one of the following
states:
○ Inactive: No activity is being performed.
○ Under Development: The activity is currently in progress.
○ Awaiting Changes: Waiting for customer feedback or change requests.
○ Under Review: The completed activity is being reviewed.
○ Under Revision: Modifications are being made based on review or customer feedback.
○ Baselined: The activity has been finalized and approved according to the SRS.
○ Done: The project has been completed, tested, and deployed successfully.
Concurrent Process Model
● The Concurrent Development Model is also known as
the Concurrent Process Model.
● After the communication activity is completed in the first
iteration, it enters the Awaiting Changes state.
● Once the modeling activity completes the initial
communication, it moves to the Under Development
state.
● If the customer requests changes in the requirements, the
modeling activity moves from the Under Development
state to the Awaiting Changes state.
● In the Concurrent Process Model, each activity
continuously transitions from one state to another based
on project progress and customer feedback.
Concurrent Model vs Incremental Model

Incremental Model Concurrent Model

Software is delivered in Modules are developed in parallel.

increments.

Focus is on adding new Focus is on simultaneous

features in stages. development.

One increment is completed Different modules can be in

before the next is released. different stages at the same time.