Software Engineering and

Testing (SET-315332)
 Highlights
• Teaching Scheme for 5th and 6th Sem.

• Outcome of Polytechnic

• Why software Engineering and Testing

• Teaching and Examination scheme

• Syllabus of ETI
Teaching Scheme for 5 Sem.
th
 Outcome of Polytechnic
3 year Diploma
in Engineering

Higher JOB
Education (Gov./Private) Entrepreneur
Name of 2025- 2024- 2023 ● Hard Skills
Institute 2026 2025 2024 Hard skills are technical knowledge
● Analytical Skills or training that you have gained
● Soft-Skill through any life experience,
XYZ ● including in your career or
Mathematical Reasoning
education
● Know bout selection Process
POQ Analytical skills refer to the ability
to collect and analyze information,
MNO problem-solve, and make
Soft skills are personal habits and decisions.
ABC traits that shape how you work, on
your own and with others
DEF
 Index

Sr. Title Aligned Learning Total Slide

No. COs Hours Marks No.

1. Basic of Software Engineering CO 1 6 12 09

2. Software Requirement, Modeling and Design CO2 10 16 55
3. Software Project Management CO 3 10 16 139
4. Basics of Software Testing CO 4 8 14 157
5. Test and Defect Management CO5 6 12 181
40 70
 Why SET
• INDUSTRY / EMPLOYER EXPECTED OUTCOME
– Apply software engineering principles to develop software product.

• COURSE LEVEL LEARNING OUTCOMES (COS)

– Students will be able to achieve & demonstrate the following COs on completion of course
based learning
● CO1 - Identify relevant software process model for software development.
● CO2 - Use appropriate principles of software modeling to create data design.
● CO3 - Apply project management techniques in software development.
● CO4 - Apply different software testing types to ensure the quality of software product.
● CO5 - Identify defect to improve the overall quality of the software using automated testing
tools.
Teaching-Learning & Assessment
Scheme
Unit 01

Basics of Software Engineering

CO1 - Identify relevant software process model for software
development.
Theory Learning Outcomes (TLO's)aligned to CO's.
TLO 1.1 Explain different types and characteristics of software.
TLO 1.2 Describe software engineering layered technology and process framework.
TLO 1.3 State software engineering principles for requirement engineering.
TLO 1.4 Select software process model for the given problem statement.
TLO 1.5 Apply agile development process with justification
Ch-01 Basics of Software Engineering

Content
1.1 Software, software engineering as layered approach, characteristics of software, types of
software
1.2 Software development framework: Software generic process framework activities and umbrella
activities
1.3 Software engineering core principles, communication practices, planning practices, modelling
practices, construction practices, software deployment practices
1.4 Prescriptive process models: Waterfall model, incremental model, RAD model, prototyping
model, spiral model
1.5 Agile software development: Agile process, and its importance, extreme programming, scrum
1.6 Selection criteria for software process model
What is Software
Software consists of computer programs that instruct the execution of a computer.
● a set of instructions to acquire the inputs and to manipulate (process) them to produce
the desired output in terms of functions and performance as determined by the user
of the software
● a software is a set of instructions computer programs that when executed provide
desire output performance and functions
● a software can be defined as a set of instruction which when executive computer
except the inputs and after doing the required computation produced output or result
as users requirement
What is Software
Software Includes:
1. Functionality: The software should perform all the operations it was designed to do, fulfilling user and
business requirements.
2. Usability: It should be easy for users to learn, understand, and use the software to accomplish their tasks
effectively.
3. Efficiency: The software should optimize the use of resources (time, CPU, memory) and deliver prompt
responses.
4. Reliability: The software should perform consistently and predictably without failures or errors under
given conditions and for a specified time period.
5. Dependability: The software should function without failure under specified conditions.
6. Integrity: Data processed and stored by the software should remain accurate, consistent, and unaltered
unless authorized.
7. Portability: The ease with which software can be moved from one platform or environment to another
with minimal effort or modifications.
8. Maintainability: The ease with which a software system or its components can be modified, updated, or
fixed with minimal cost, effort, and time.
9. Acceptability : Software must be accept by the uses for which it was designed.
Characteristics of Software

1. Software is developed or
engineered; it is not
manufactured in the
classical sense.
2. The software doesn’t “wear
out.”
3. The software continues to
be custom-built, rather than
being assembled from
 Characteristics of Software
1. Software is developed or engineered, not manufactured

● “Think about a car. It is manufactured in a factory, and each car is made on an

assembly line. But software is not like that. We don’t ‘manufacture’ software in

factories. We design it, write code, and test it step by step. That’s why we call it

software engineering.”

Example: WhatsApp was developed once by engineers, and now millions of

copies can be installed without re-building it again.

 Characteristics of Software
2. Software doesn’t wear out
● “If you buy a mobile phone, after a few years its battery and hardware parts wear
out. But does your calculator app or game ‘wear out’? No. Software doesn’t get
old or rusty.”

● “However, sometimes it stops working properly when the environment

changes—for example, if you update your Android version, some old apps might
crash. That is not because the software wore out, but because it was not
updated.”

Example: Old PC games may not run on Windows 11 even though the game itself
has not ‘worn out.
 Characteristics of Software
2. Software doesn’t wear out
 Characteristics of Software
3. Most software is custom-built

● “In hardware, we use ready-made parts like screws, nuts, and bolts. But in
software, we usually write programs from scratch to meet user requirements.”

● “Today, we do use libraries, frameworks, and ready-made components (like

a login module or payment gateway), but still, every software has some part that
is custom-made.”

Example: An e-commerce website might use a ready-made payment system

(PayPal, Razorpay) but the overall design, products, and features are custom-built.
Types/ Categories of Software
 What is Software Engineering

● Software Engineering is the systematic approach to the development,

operation, and maintenance of software.

● It applies engineering principles (planning, designing, testing, managing) to

build reliable, efficient, and cost-effective software.

“Software Engineering is the application of engineering methods to develop high-

quality software in a systematic way.
 What is Software Engineering
Definitions of Software Engineering

1. IEEE Definition (1993):

Software Engineering is the application of a systematic, disciplined, and quantifiable approach to the development,
operation, and maintenance of software.

2. Fritz Bauer (1969):

Software Engineering is the establishment and use of sound engineering principles to obtain economically software that
is reliable and works efficiently on real machines.

3. Ian Sommerville:
Software Engineering is an engineering discipline concerned with all aspects of software production – from the early
stages of specification through to maintaining the system after it has gone into use.

4. Pressman:
Software Engineering is a layered technology and a process of analyzing user requirements, designing, building, and
testing software to satisfy those requirements.

5. General Simple Definition (for students):

Software Engineering is the process of designing, developing, testing, and maintaining software by applying engineering
principles in a systematic way.
 What is Software Engineering

“All definitions say the same thing in different words –

Software Engineering = Systematic + Engineering Principles + Reliable & Efficient Software.”

“Programming is like cooking for yourself at home. Software Engineering is like

running a big restaurant – you need recipes, planning, teamwork, quality checks,
and customer service.”
 Software Engineering (Layered Approach)
● Software Engineering follows a layered approach where each layer builds on
the foundation of the previous one.

● The layers are related and each layer demands the fulfillment of the previous
layer

● The layers technology approach ensures well designed software product

 Software Engineering (Layered Approach)
1. Quality Focus (Core Layer) 3. Methods Layer
● At the very core, software engineering emphasizes ● Provides technical methods for software
quality. development.
● Includes:
● Every activity (requirement, design, coding, testing, ○ Requirement analysis
maintenance) must ensure high quality software. ○ Design techniques (UML, DFD, ER diagrams)
○ Coding standards
● Quality acts as the foundation of all layers. ○ Testing methods
2. Process Layer 4. Tools Layer (Top Layer)
● Defines the framework for software development. ● Provides automated or semi-automated support
for methods and process.
● Provides a set of activities(Key Process Areas- ● Examples:
KPA) (planning, managing, monitoring) that guide ○ CASE tools (Rational Rose, Enterprise
how software is built. Architect)
○ IDEs (Eclipse, Visual Studio, IntelliJ)
● Examples: Waterfall, Agile, Spiral, Incremental ○ Testing tools (Selenium, JUnit)
models. ○ Version control (GitHub, GitLab)
Software Engineering (Layered Approach)
 Software Process & Process Framework
A Software Process is a structured set of activities and associated results that are
followed to develop, operate, and maintain software. In simple terms, it’s the method
or approach used to create software systematically.

It ensures that software is delivered on time, within budget, and meets the required
quality.

A Software Process Framework is a generic structure that defines the basic set of
activities, tasks, and workflows that are common to all software development
processes.

It provides a blueprint for managing software projects and ensures that software is
 Software Development Framework

Generic Process Framework:

A generic software process framework is a set of fundamental activities that

are common to all software development projects, regardless of size, domain, or
methodology.
These activities form the backbone of any software development process.
A generic process framework for software engineering defines five framework
activities—
Communication, Planning, Modeling, Construction, and Deployment.
 Software Development Framework
1. Communication (Requirement Gathering)
○ Understanding what the client wants.
○ Activities include meetings, interviews, and requirement analysis.
○ Output: Software Requirements Specification (SRS)
2. Planning
○ Creating a roadmap for the project.
○ Activities include estimating cost, effort, resources, and scheduling.
○ Output: Project Plan / Work Breakdown Structure
3. Modeling / Analysis and Design
○ Understanding and modeling the software solution.
○ Activities include data modeling, architectural design, and UI design.
○ Output: Design Documents (Architectural, Detailed Design)
 Software Development Framework
4. Construction (Implementation / Coding)

○ Writing the actual code.

○ Activities: coding, debugging, unit testing.
○ Output: Working Software / Modules

5. Deployment (Release & Maintenance)

○ Delivering the software to the client and supporting it.

○ Activities: installation, user training, maintenance, bug fixes.
○ Output: Deployed Software and Updates

These activities are complemented by a number of Umbrella activities

Umbrella activities
 Umbrella activities
These are activities that support and span across all the fundamental activities. They are not tied to a
single phase but are ongoing throughout the software development life cycle.

1. Software project tracking and control—allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.

2. Risk management—assesses risks that may affect the outcome of the project or the quality of the
product.

3. Software quality assurance—defines and conducts the activities required to ensure software
quality.

4. Formal Technical reviews—assesses software engineering work products in an effort to uncover

and remove errors before they are propagated to the next activity.
 Umbrella activities
5. Measurement—defines and collects process, project, and product measures that assist the team
in delivering software that meets stakeholders’ needs; can be used in conjunction with all other
framework and umbrella activities.

6. Software configuration management—manages the effects of change throughout the software

process.

7. Reusability management—defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

8. Work product preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.

Umbrella activities run in parallel with all stages of software development. They don’t produce the
final product directly but ensure the product is high-quality, safe, and maintainable.
1.3 Software engineering core Principles, Communication
Practices, Planning Practices, Modelling Practices, Construction
Practices, Software Deployment Practices
● The dictionary defines the word Principle as “an important underlying law or
assumption required in a system of thought.”
● Software engineering principles are fundamental guidelines that helps
developers design, develop, and maintain high-quality software systems. These
principles ensure that software is efficient, scalable, maintainable and meets
user requirements
● Software Engineering Practices are a set of guidelines, methodologies, and
principles that ensure the development of high-quality, maintainable, and efficient
software.
 Software engineering core principles
The 7 principles can be remembered as:

1. Reason it exists → Focus on customer value

2. KISS → Keep it simple

3. Maintain the vision → Clear purpose

4. What you Produce, Others will consume →Write clean & understandable code

5. Be open to future → Flexible design

6. Plan for reuse → Build reusable components

7. Think! → Use common sense always

Communication Practices
● Principle 1. Listen carefully.
● Principle 2. Prepare before you communicate.
● Principle 3. Someone should facilitate the activity.
● Principle 4. Face-to-face communication is best.
● Principle 5. Take notes and document decisions.
● Principle 6. Strive for collaboration.
● Principle 7. Stay focused; modularize your discussion.
● Principle 8. If something is unclear, draw a picture.
● Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to
something, move on. (c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
● Principle 10. Negotiation is not a contest or a game.
 Software Engineering Planning Practices

Principle 1. Understand the scope of the project.

Principle 2. Involve stakeholders in the planning activity.
Principle 3. Recognize that planning is iterative
Principle 4. Estimate based on what you know.
Principle 5. Consider risk as you define the plan.
Principle 6. Be realistic.
Principle 7. Adjust granularity as you define the plan.
Principle 8. Define how you intend to ensure quality
Principle 9. Describe how you intend to accommodate change.
Principle 10. Track the plan frequently and make adjustments as required.
 Design Modeling Principles
Principle 1. Design should be traceable to the requirements model.
Principle 2. Always consider the architecture of the system to be built.
Principle 3. Design of data is as important as design of processing functions.
Principle 4. Interfaces (both internal and external) must be designed with care.
Principle 5. User interface design should be tuned to the needs of the end user.
Principle 6. Component-level design should be functionally independent.
Principle 7. Components should be loosely coupled to one another and to the
external environment
Principle 8. Design representations (models) should be easily understandable.
Principle 9. The design should be developed iteratively.
 Software Engineering Construction Practices
Coding Principles:
The principles that guide the coding task are closely aligned with programming style,
programming languages, and programming methods.
However, there are a number of fundamental principles that can be stated:
Preparation principles: Before you write one line of code, be sure you
• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be built
and the environment in which it will operate.
• Select a programming environment that provides tools that will make your work
easier.
• Create a set of unit tests that will be applied once the component you code is
completed.
 Software Engineering Construction Practices
Programming principles:
As you begin writing code, be sure you
• Constrain your algorithms by following structured programming practice.
• Consider the use of pair programming.
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that aids understanding.
Software Engineering Construction Practices

Validation Principles:

After you’ve completed your first coding pass, be sure you

• Conduct a code walkthrough when appropriate.

• Perform unit tests and correct errors you’ve uncovered.

• Re factor the code. Refactoring

The authorisofthe theprocess of restructuring
code presents it to theexisting
team, code
without changing
explaining its external
its logic and flow,behavior or functionality
while other team membersto
improve readability, maintainability, and structure.
ask questions and provide feedback to identify errors
Common refactoring techniques include renaming
and foster collaboration. Code walkthroughs are
variables and methods, breaking down large methods,
particularly useful for complex code, new team
removing duplicate code, and extracting common
members, and
functionality into to
new ensure common
methods understanding of the
or classes.
codebase.
 Software Engineering Testing Practices

In a classic book on software testing, Glen Myers states a number of rules that can

serve well as testing objectives:

• Testing is a process of executing a program with the intent of finding an error.

• A good test case is one that has a high probability of finding an as-yet-

undiscovered error.

• A successful test is one that uncovers an as-yet-undiscovered error.

Software Engineering Testing Practices

Principle 1. All tests should be traceable to customer requirements.

Principle 2. Tests should be planned long before testing begins.

Principle 3. The Pareto principle applies to software testing.

Principle 4. Testing should begin “in the small” and progress toward testing “in

the large.”

Principle 5. Exhaustive Intesting is not possible.

testing, the Pareto Principle (or 80/20 rule) states that approximately
The number of path permutations for even a
80% of software defects are concentrated in 20% of the application's
moderately sized program is exceptionally large.
code or features. Testers use this principle to prioritize their efforts,
For thison
focusing reason, it few"
the "vital is impossible
modules orto execute
features thatevery combination
are most likely to
of paths
contain theduring
majoritytesting.
of the bugs
Software Engineering Deployment Practices

Principle 1. Customer expectations for the software must be managed.

Principle 2. A complete delivery package should be assembled and tested.

Principle 3. A support regime must be established before the software is

delivered.

Principle 4. Appropriate instructional materials must be provided to end users.

Principle 5. Buggy software should be fixed first, delivered later.

 1.4 Prescriptive process models: Waterfall
Model, Incremental Model, RAD Model,
Prototyping model, Spiral Model
● The process model is an abstraction of the software development process.
● Software Process Models are systematic methods for controlling and
coordinating the development of a software product achieving all the stated
objectives or goals
● A framework containing the process, activities and task involved in the
development operation and maintenance of the software product, spanning the
life of the system from the definition of its requirements to the termination of its
uses.
● A process model is blueprint of how to organise, implement, conduct and
manage software engineering processes in an organisation with an established,
validated, and proven process system and good practices
 Prescriptive Process Models

● Prescriptive process models are traditional software development models that

follow a structured and well-defined sequence of steps.
● Prescriptive process models provide a structured, step-by-step roadmap for
software development, emphasizing defined phases, activities, and deliverables
in a specific order to ensure order and quality
● Prescriptive process models provide structured approaches to software
development.
● While they ensure discipline and organization, they may not always be flexible
enough for modern, rapidly changing projects
Prescriptive Process Models
➢ A linear process flow executes
each of the five framework
activities in sequence, beginning
with communication and
culminating with deployment
➢ An iterative process flow
repeats one or more of the
activities before proceeding to the
next
➢ An evolutionary process flow
executes the activities in a
“circular” manner.
➢ A parallel process flow
executes one or more activities in
parallel with other activities.
 Waterfall Model

● Introduced by Winston W. Royce in 1970.

● The waterfall model is a traditional, linear-sequential software development
process where each phase flows sequentially into the next, with no overlap, and
● Each phase must be completed before the subsequent one begins.
● This model includes phases like Requirements Gathering, System Design,
Implementation, Testing, Deployment, and Maintenance.
● It is suitable for projects with fixed, unchanging requirements, such as small or
simple projects, but is inflexible and does not allow for changes or feedback once
a phase is completed.
Waterfall Model
 Waterfall Model
Advantages:
• Simple and easy to understand and use.
• Works well for smaller projects with clear, fixed requirements.
• Easy to manage due to its rigidity (each phase has specific deliverables).

Disadvantages:
• Inflexible to changes: hard to go back to a previous phase.
• Poor model for long-term or complex projects.
• Late discovery of issues (testing happens after implementation).
• Limited customer involvement once requirements are finalized.
 Incremental Model

● It developed by Harlan Mills et al., in 1980

● The incremental model in software engineering builds a system in small,

manageable parts called increments rather than all at once.

● Each increment represents a working piece of software that is built, tested, and
delivered incrementally, adding new features and functionality with each release
until the complete system is finished.

● This phased approach allows for early delivery of functional software, provides
opportunities for early user feedback, and makes it easier to adapt to changing
requirements.
Incremental Model
 Incremental Model
Each following increment repeats all the same phases
• New features are planned, designed, built, and deployed.
• These increments are integrated with previous ones to enhance the software.
• Each delivery improves overall functionality.
Advantages:
• Delivers working software early and frequently.
• Easier to test and debug smaller increments.
• Flexible: easier to accommodate changes in requirements. •
Customers can provide feedback after each increment.
Disadvantages:
• Needs good planning and design upfront to define increments well.
• Integration of increments can be complex.
• Total cost may be higher than using the waterfall model for simple projects.
RAD Model
● IBM first proposed the Rapid Application Development or RAD Model in the
1980s.
● The RAD model is used when the requirements are fully understood and the
component-based construction approach is adopted.
● Various phases in RAD are Requirements Gathering, Analysis and Planning,
Design, Build or Construction, and finally Deployment.
● The important feature of RAD Model is increased involvement of user customer
at all stage of life cycle through the use of powerful development tool
● The RAD Model is a high speed adaptation of waterfall model in which Rapid
development is achieved by using a component-based construction approach.
● This model distribute the analysis design built and taste phases into a series of
short iterative development cycles
RAD Model
 RAD Model
Advantages of Rapid Application Development Model (RAD)
● The use of reusable components helps to reduce the cycle time of the project.
● Feedback from the customer is available at the initial stages.
● Reduced costs as fewer developers are required.
● The use of powerful development tools results in better quality products in
comparatively shorter periods.
● The progress and development of the project can be measured through the
various stages.
● It is easier to accommodate changing requirements due to the short iteration
time spans.
 RAD Model
Disadvantages of Rapid application development model (RAD)
● The use of powerful and efficient tools requires highly skilled professionals.
● The absence of reusable components can lead to the failure of the project.
● The team leader must work closely with the developers and customers to
close the project on time.
● The systems which cannot be modularized suitably cannot use this model.
● Customer involvement is required throughout the life cycle.
● It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the project.
● Not every application can be used with RAD
 Prototyping Model
● Often, a customer defines a set of general objectives for software, but does not identify
detailed requirements for functions and features.
● In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human-machine interaction should
take.
● In these, and many other situations, a prototyping paradigm may offer the best
approach.
● The quick design leads to the construction of a prototype. The prototype is deployed
and evaluated by stakeholders, who provide feedback that is used to further refine
requirements.
● The prototyping model source to clarity requirements, which are not clear, hence
reducing ambiguity and improving communication between the developer and user
● It focus on those aspects of the software that are visible to the customer or user. user
feedback is used to refine the prototype. There is a great environment of user in
software development which helps in reducing the risk associated with the software
Prototyping Model

Phases of the Prototyping Model:

1. Communication

2. Quick Plan

3. Modeling / Quick Design

4. Construction of Prototype

5. Deployment, Delivery & Feedback

 Phases of the Prototyping Model
Phases of the Prototyping Model:
● 1. Communication:
○ Purpose: Understand business needs and gather initial requirements from
stakeholders.
○ Activities: Meetings, brainstorming, user interviews.
○ Outcome: Clear understanding of what the user wants in the software.

● 2. Quick Plan:
○ Purpose: Outline a short-term development plan.
○ Activities: Prioritize features, schedule tasks, assign roles.
○ Outcome: A lightweight and flexible project plan to get started quickly.
 Phases of the Prototyping Model
● 3. Modeling / Quick Design:
○ Purpose: Create a fast, conceptual design or model of the system.
○ Activities: Create mock-ups, flow diagrams, or quick UI designs.
○ Outcome: A visual or functional design that guides prototype development.
● 4. Construction of Prototype:
○ Purpose: Develop a working prototype based on the design.
○ Activities: Rapid coding and unit testing of features.
○ Outcome: A functional version of the system or a prototype for user testing.
● 5. Deployment, Delivery & Feedback:
○ Purpose: Deliver the prototype to the user and gather feedback.
○ Activities: Demonstrations, feedback collection, refinement.
○ Outcome: Insights for improving the prototype in the next iteration.
 Prototyping Model
● Advantages:
○ Helps clarify vague or changing requirements.
○ Increases user involvement and satisfaction.
○ Early detection of design and usability issues.
○ Reduces risk of building the wrong system.

● Disadvantages:
○ May lead to scope creep (users keep requesting changes).
○ Incomplete prototypes may create false expectations.
○ Not suitable for performance-critical systems.
○ Requires frequent customer interaction and developer flexibility.
 Spiral Model
● Originally proposed by Barry Boehm [Boe88],
● The spiral model is an evolutionary software process model
● That it couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model.
● Using the spiral model, software is developed in a series of evolutionary releases.
● During early iterations, the release might be a model or prototype.
● During later iterations, increasingly more complete versions of the engineered system
are produced.
● The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
● the first circuit around the spiral might represent a “concept development project” that
starts at the core of the spiral and continues for multiple iterations until concept
development is complete.
 Spiral Model

The arrows pointing inward

along the axis separating the
deployment region from the
communication region
indicate a potential for local
iteration along the same spiral
path.
 Spiral Model
Phases of the Prototyping Model:
➔ 1. Planning:
◆ Activities: Estimation, scheduling, risk analysis
◆ Purpose:
● Define objectives, identify constraints, estimate costs, and perform risk
assessment.
● A key strength of the spiral model is early and repeated focus on risk
management.
➔ 2. Modeling:
◆ Activities: Analysis, design
◆ Purpose:
● Requirements are analyzed and system architecture is designed.
● At each iteration, new features or improvements are modeled and
planned.
 Spiral Model
Phases of the Prototyping Model:
➔ 3. Construction:
◆ Activities: Code, test
◆ Purpose: Develop and test the software incrementally. A working product
(prototype or module) is delivered at the end of each loop.
➔ 4. Deployment:
◆ Activities: Delivery, feedback
◆ Purpose: The developed version is delivered to users or stakeholders for
feedback. Based on feedback, improvements are planned in the next
iteration.
➔ 5. Communication:
◆ Activities: Stakeholder interaction
◆ Purpose: Maintain continuous interaction with stakeholders to gather
requirements, clarify expectations, and validate progress.
 Spiral Model
➔ Advantages:

◆ Strong risk management.

◆ Suitable for large and mission-critical projects.

◆ Allows for early detection of problems.

◆ Encourages customer feedback throughout.

➔ Disadvantages:

◆ Can be complex to manage and implement.

◆ Expensive due to repeated planning and risk analysis.

◆ Not suitable for small or low-risk projects.

 Agile Software Development
In 2001, Kent Beck and 16 other noted software developers, writers, and
consultants [Bec01a] (referred to as the “Agile Alliance”) signed the “Manifesto for
Agile Software Development.”
It stated:
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
● Individuals and interactions over processes and tools
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the
left more
Agile Software Development Process
Agile software engineering combines a philosophy and a set of development
guidelines.

● The philosophy encourages customer satisfaction and early incremental

delivery of software;
● small, highly motivated project teams;
● informal methods;
● minimal software engineering work products;
● and overall development simplicity.
The development guidelines stress delivery over analysis and design , and
active and continuous communication between developers and customers.
 Agile Software Development Process
● Agile is a methodology or mindset which consists of several iterative and
incremental software development methodologies.
● Agile software development is an iterative and collaborative approach to building
software that emphasizes flexibility, continuous feedback, and the frequent
delivery of working products in short, fixed-length cycles called "sprints".
● Instead of a single, long development cycle like the traditional "Waterfall" model,
Agile breaks projects into small, manageable cycles called "sprints" or
"iterations".
 Agile Software Development Process
A typical Agile workflow follows these steps:
● Requirements gathering: The team and product owner identify and prioritize customer
requirements and feedback. This is sometimes documented in a "product backlog".
● Sprint planning: At the start of each sprint (typically 1–4 weeks), the team decides which items
from the product backlog to address, creating a "sprint backlog".
● Development and testing: The team works on the tasks from the sprint backlog. Crucially,
testing is done continuously, not just at the end, allowing for rapid feedback and early error
detection.
● Deployment: A working increment of the software is delivered to stakeholders. The goal is to
produce a functional product or feature at the end of every sprint.
● Review and retrospective: The team demonstrates the completed work and gathers feedback
from customers and stakeholders. They also hold a retrospective meeting to reflect on what
went well and what could be improved for the next sprint.
Agile Software Development Process
Agile Software Development Process
 Agility Principles
The Agile Alliance defines 12 agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
 Agility Principles

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self– organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
 Agile Software Development Process
Features of the Agile Software Development Approach:
Customer involvement: Customers should be closely involved throughout the
development process. Their role is to provide and prioritize new system
requirements and to evaluate the iterations of the system.
Incremental delivery: The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process: The skills of the development team should be recognized and
exploited. Team members should be left to develop their own ways of working
without prescriptive processes.
Embrace change: Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity: Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work to eliminate
complexity from the system.
Advantages of Agile Process
● Flexibility and adaptability

● Faster delivery of values

● Higher product quality

● Customer satisfaction

● Risk man mitigation

● Reduce technical debate

● Better Communication and Collaboration

Disadvantages of Agile Process
● Difficult to Predict

● Limited Upfront Documentation

● High Dependency on Customer Availability

● Challenging for Complex Dependencies

● Requires Skilled Teams

● Risk of scope creep Scope creep is the uncontrolled expansion of

a project's scope beyond its original, agreed-
upon boundaries
 Agile Software Development Models
Agile software development models are iterative frameworks for building software that
emphasize flexibility, collaboration, and customer satisfaction through rapid, incremental
delivery of working software;
Examples of Agile Models:
● Scrum: A popular framework that uses fixed-length iterations called "sprints" to
deliver software in increments.
● Extreme Programming (XP): An agile methodology that promotes high-quality
software through practices like pair programming, test-driven development, and
continuous integration.
● Kanban
● Lean
● DSDM or Dynamic Systems Development Method ·
● FDD or Feature Driven Development
● Crystal
● Scaled Agile Framework (SAFe)
 Extreme Programming (XP)
● Extreme Programming (XP), the most widely used approach to agile software
development.
● Extreme Programming (XP) is an Agile software development methodology that
focuses on delivering high-quality software through frequent and continuous
feedback, collaboration, and adaptation.
● XP emphasizes a close working relationship between the development team, the
customer, and stakeholders, with an emphasis on rapid, iterative development
and deployment.
● XP is based on the frequent iteration through which the developers implement
User Stories. User stories are simple and informal statements of the customer
about the functionalities needed.
● A User Story is a conventional description by the user of a feature of the required
system.
 Extreme Programming (XP) Process

Extreme Programming uses an

object-oriented approach as its
preferred development
paradigm and encompasses a
set of rules and practices that
occur within the context of
four framework activities:
planning, design, coding, and
testing.
 Extreme Programming (XP) Process
Planning
● Begins with the creation of a set of stories (also called user stories)
● Each story is written by the customer and is placed on an index card
● The customer assigns a value (i.e. a priority) to the story
● Agile team assesses each story and assigns a cost
● Stories are grouped to for a deliverable increment
● A commitment is made on delivery date
● After the first increment “project velocity” is used to help define subsequent delivery
dates for other increments
Project velocity is an Agile metric that measures the amount of work
a team completes in a fixed time period, like a sprint, and is used for
forecasting and improving project delivery.
 Extreme Programming (XP) Process
Design
● XP design rigorously follows the KIS (keep it simple) principle.
● XP encourages the use of CRC (class-responsibility-collaborator) cards as an effective
mechanism for thinking about the software in an object-oriented context.
● If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design. Called a spike solution, the design prototype is implemented and evaluated.
Coding
● Recommends the construction of a series of unit tests for each of the stories before
coding commences
● Encourages “pair programming”
○ –Mechanism for real-time problem solving and real-time quality assurance
○ –Keeps the developers focused on the problem at hand
 Extreme Programming (XP) Process
Testing
● Unit tests should be implemented using a framework to make testing automated. This
encourages a
● regression testing strategy.
● Integration and validation testing can occur on a daily basis
● Acceptance tests, also called customer tests, are specified by the customer and
executed to assess customer visible functionality
● Acceptance tests are derived from user stories.
 Values of Extreme Programming (XP)
There are five core values of Extreme Programming (XP)
Extreme Programming (XP)
Extreme Programming (XP)
 SCRUM

● Scrum is a popular framework that is used whenever we want to develop complex

products, Ken Schwaber and Jeff Sutherland are known as the people who developed
Scrum.
● Scrum is a framework within which people can address complex adaptive problems,
while productively and creatively delivering products of the highest possible value.
● Scrum is not a process or a technique for building products; rather, it is a framework
within which you can employ various processes and techniques.
● Scrum makes clear the relative efficacy of your product management and development
practices so that you can improve.
● Scrum offers several advantages, including faster development cycles, improved
transparency, and better adaptability to changing requirements. It fosters collaboration
and ensures incremental delivery of value to stakeholders.
 Scrum Process Framework

● The Scrum process is based on iterative cycles called Sprints which typically last 2-4
weeks during which the product is designed, coded and tested.
● The business sets the priorities and the team organizes themselves to determine the best
way to deliver the highest priority features.
● The Product Owner represents the Business side and is responsible for the maintaining
the list of product features and sets priorities for development.
● Anyone in the team can add items in the product backlog but the Product Owner has the
authority to choose the features and set the priorities.
● Every 2-4 weeks customers can see real working software and decide to release it as-is
or continue to enhance it for another sprint.
Scrum Process Framework
 SPRINTS
● The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a
potentially releasable product increment is created.
● A new Sprint starts immediately after the conclusion of the previous Sprint.
● Sprints consist of the Sprint planning, daily scrums, the development work, the Sprint
review, and the Sprint retrospective.
○ In Sprint planning, the work to be performed in the Sprint is planned collaboratively by the Scrum
Team.
○ The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to synchronize the
activities and create a plan for that day.
○ A Sprint Review is held at the end of the Sprint to inspect the Increment and make changes to the
Product Backlog, if needed.
○ The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this
meeting, the Scrum Team is to inspect itself and create a plan for improvements to be enacted during
the subsequent Sprint.
 Scrum - Roles
Scrum Master Team
Product Owner

● Facilitator ● Typically comprises of 8-10

● Representative from the business
● Remove barriers members
side
● Guide the Product Owner ● Usually a mix of software
● Owns the product backlog which ● Improve the productivity of the engineers, architects,
is a list of all the features team programmers, analysts, QA
● Prioritizes and provides ● Improve the engineering experts, testers, UI designers etc.
clarifications practices ● They self-organize to meet the
● Reports the team’s progress to all sprint goals
● Available to the team at any time,
parties ● The team has autonomy to
especially sprint planning & ● Guardian to ensure the team is choose how to best meet the
sprint review meeting
insulated from Product Owner goals, and is held responsible for
them.
 Scrum - Events
Scrum is an Agile framework designed to manage complex projects by breaking them into
smaller, iterative cycles called sprints. It emphasizes collaboration, adaptability, and continuous
improvement. Below is an overview of the key phases and components of the Scrum process.
Key Phases in Scrum
1. Sprint Planning: This phase begins each sprint. The team collaborates to decide which
tasks from the product backlog will be completed during the sprint. The selected tasks
from the sprint backlog.
2. Daily Scrum: A short, time-boxed meeting (usually 15 minutes) held daily. The team
discusses progress, identifies obstacles, and plans the work for the next 24 hours.
3. Sprint Execution: During this phase, the development team works on the tasks defined in
the sprint backlog. The Scrum Master ensures the team adheres to Scrum principles and
removes any blockers.
4. Sprint Review: At the end of the sprint, the team demonstrates the completed work to
stakeholders. Feedback is gathered to refine the product and prioritize future tasks.
5. Sprint Retrospective: This is a reflective meeting where the team discusses what went
well, what didn’t, and how processes can be improved in the next sprint
Scrum Process Framework
Sprint Retrospective:

Two main questions are asked

Sprint
in the Review:
sprint retrospective:
What went well during the
The SprintWhat
Sprint? Review could
Meetingbe
is
conducted inatthethenext
improved endsprint?
of a
sprintiscycle
This to; activity in the
the final
sprint process and is
● Review the
facilitated by work
the that
Scrum
Masterwasto;completed and the
planned work that was
not completed
● Reflect on the past sprint,
● discuss
Present the
andcompleted
record the
work to the
lessons stakeholders
learned during
(through
the sprint acycle
Demo)
● Make continuous process
improvement
 Scrum- Artifacts
Product Backlog
● The Product Backlog is an ordered list of features that are needed as part of the end product
and it is the single source of requirements for any changes to be made to the product.
● The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases.

Sprint Backlog
● The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal.
● The Sprint Backlog is a forecast by the Team about what functionality will be made available
in the next Increment and the work needed to deliver that functionality as a working
product Increment.
● The Sprint Backlog is a plan with enough detail that can be understood but the Team to
track in the Daily Scrum.
Selection Criteria for Software Process Model
1. Project Size and Complexity
• Small projects: Lightweight models like Agile or Prototyping.
• Large, complex projects: Structured models like Spiral or Waterfall with detailed documentation.
2. Clarity of Requirements
• Well-defined requirements: Waterfall, V-Model.
• Unclear or evolving requirements: Agile, Spiral, Prototyping.
3. Risk Involvement
• High-risk projects (e.g., safety-critical systems): Spiral Model (focus on risk analysis).
• Low-risk projects: Waterfall or Incremental may suffice.
4. Customer Involvement
• Continuous customer input available: Agile, XP, Prototyping.
• Limited customer involvement: Waterfall, V-Model.
5. Project Duration / Time Constraints
• Short timeline / rapid delivery needed: Agile, RAD.
• Long-term projects with detailed planning: Spiral, Waterfall.
6. Team Experience and Skill Level
• Experienced, self-organized teams: Agile, XP.
• Less experienced teams: Waterfall or V-Model (more structured guidance).
7. Budget Constraints
• Limited budget: Agile (early working versions), Waterfall (predictable costs).
• Flexible budget: Spiral (due to repeated risk assessments and iterations).
8. Need for Flexibility
• High flexibility required: Agile, Incremental, Spiral.
• Low flexibility (strict compliance projects): Waterfall, V-Model.
Unit 02

Software Requirement, Modeling and Design

CO2 - Use appropriate principles of software modeling to create data design.

Theory Learning Outcomes (TLO's)aligned to CO's.

TLO 2.1 Determine requirement engineering tasks in the given problem.
TLO 2.2 Prepare use case diagram for given scenario.
TLO 2.3 Prepare SRS for the given problem.
TLO 2.4 Convert analysis model into requirement model.
TLO 2.5 Apply the specified design feature for requirements software modeling.
TLO 2.6 Represent the specified problem in the given design notation.
 Ch-02 Software Requirement,
Modeling and Design
Content
2.1 Requirement engineering: Requirement engineering task, types of requirement,
developing use-case
2.2 SRS (Software Requirements Specifications): Need of SRS, format and it's
characteristics
2.3 Translating requirement model into design model
2.4 Design modelling: Fundamental design concepts - abstraction, information
hiding, patterns, modularity, concurrency, verification, aesthetics
2.5 Design notations: Data flow diagram (DFD), structured flowcharts
 Requirement Engineering
● The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering.
● From a software process perspective, requirements engineering is a major software
engineering action that begins during the communication activity and continues into the
modeling activity.
● Requirements Engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software
system.
● Requirements engineering builds a bridge to design and construction.
● Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an operational system
Requirement Engineering Processes
 Requirement Engineering Task
● It encompasses seven distinct tasks:
○ inception, Inception
Elicitation(
Elaboration (from
to
why
(todraw
it
where
workisout
difficult)
outto
thestart)
in truth
detail)from
● Problems
anybody)
The Itofcertainly
information scope..
obtained from theget
customer
● How does seems
a software simple
project started?during
enough—ask the
○ elicitation, inception
● Problems
customer, andof
the elicitation
users, is expanded
and others
understanding. what theand refinedfor the
objectives
● Is there
during
system a single
elaboration.
or product are, event
This
whattaskthat
is becomes
tofocuses
be on the catalyst
developing
accomplished, how thea
○ elaboration, ● Problems
refined of volatility.
requirements model that identifies variousand
systemfor or product
a new fits into
computer-based the needs of theorbusiness,
system product, or
○ negotiation, aspects
Negotiation of the
finally, how software
systemfunction,
or product behavior, and on a day-to-
is to be used
● basis.
does the need evolve over time?
information.
day
○ specification, Specification. ● It’s relatively common for different customers or
In the context of computer-based systems (and software), the
users to propose conflicting requirements, arguing
○ validation, and term specification means different things to different people.
A specification canthat
be atheir version
written is “essential
document, for our special
a set of graphical
○ management. models, a formal mathematical model, a collection of usage
needs.”
● It is important to notethatscenarios,
some of a prototype,
these tasks or anyoccur
combination of these.
in parallel and all are adapted to
the needs of the project.
Functional Requirements:

● These are the requirements that the end user specifically demands as basic facilities
that the system should offer.
● All these functionalities need to be necessarily incorporated into the system as a part of
the contract.
● These are represented or stated in the form of input to be given to the system, the
operation performed and the output expected.
● They are basically the requirements stated by the user which one can see directly in the
final product, unlike the non-functional requirements
Non-functional requirements:

These are basically the quality constraints that the system must satisfy according to the
project contract. The priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioral requirements.

They basically deal with issues like:

1. Portability
2. Security
3. Maintainability
4. Reliability
5. Scalability
6. Performance
7. Reusability
8. Flexibility
Non-functional requirements:
3. Domain Requirements

Definition: Domain requirements are specific to the domain or industry in which the
software operates. They include terminology, rules, and standards relevant to that
particular domain.
Examples:

● Healthcare: The software must comply with HIPAA regulations for handling patient
data.
● Finance: The system should adhere to GAAP standards for financial reporting.
● E-commerce: The software should support various payment gateways like PayPal,
Stripe, and credit cards.
Unit 03

Software Project Management

CO3 - Apply project management techniques in software development.

Theory Learning Outcomes (TLO's)aligned to CO's.

TLO 3.1 Explain 4 P's of management spectrum.
TLO 3.2 Estimate the size of the software product using the given method.
TLO 3.3 Evaluate the cost of the given software using COCOMO model.
TLO 3.4 Describe the RMMM strategy for the given problem.
TLO 3.5 Use various scheduling techniques for the given project.
TLO 3.6 Prepare the Timeline chart / Gantt chart to track progress of the given project
Ch-03 Software Project Management

Content
3.1 The management spectrum- 4P's
3.2 Metrics for size estimation: Line of code (LoC), function points(FP)
3.3 Project cost estimation using COCOMO (Constructive Cost Model), COCOMO II
3.4 Define risk, types of risk, RMMM strategy
3.5 Project scheduling: Basic principle, scheduling techniques - CPM, PERT
3.6 Project tracking: Timeline charts, Gantt charts
Unit 04

Basics of Software Testing

CO4 - Apply different software testing types to ensure the quality of software
product.
Theory Learning Outcomes (TLO's)aligned to CO's.
TLO 4.1 State the importance of software testing.
TLO 4.2 Identify errors and bugs in the program.
TLO 4.3 Prepare test case for the application.
TLO 4.4 Identify the entry and exit criteria for the given test application.
TLO 4.5 Describe features of the given software quality evaluation standard.
TLO 4.6 Explain V model for the given application.
TLO 4.7 Describe features of the given testing method.
TLO 4.8 Apply specified testing levels for the given application.
Ch-04 Basics of Software Testing
Content
4.1 Software testing, objective of testing, software testing life cycle (STLC)
4.2 Failure, fault, error, defect, bug terminology
4.3 Test case, when to start and stop testing
4.4 Quality assurance, quality control and verification - validation, Quality
evaluation standards: Six sigma, CMMI levels
4.5 Static and dynamic testing
4.6 The box approaches: Compare white box testing, black box testing
4.7 Levels of testing: Unit testing, integration testing, system testing, acceptance
testing
Unit 05

Test and Defect Management

CO5 - Identify defect to improve the overall quality of the software using
automated testing tools.

Theory Learning Outcomes (TLO's)aligned to CO's.

TLO 5.1 Prepare test plan for the given application.
TLO 5.2 Identify the resource requirement for test infrastructure management.
TLO 5.3 Prepare test report of executed test cases for given application.
TLO 5.4 Apply defect life cycle.
TLO 5.5 Prepare defect report for identified defect for AUT.
TLO 5.6 Compare automation and manual testing based on various parameters.
TLO 5.7 Describe metrics and measurement for the given application.
Ch-05 Test and Defect Management
Content
5.1 Test planning: Preparing a test plan
5.2 Test management: Test infrastructure management
5.3 Test reporting: Executing test cases, preparing test summary report
5.4 Definition and types of defect, defect life cycle, defect template
5.5 Comparison of manual testing and automation testing
5.6 Metrics and measurement: Types of metrics - product metrics and process metrics
Thank You…!
Get in Touch
AISSMS Polytechnic
Kennedy Road, Near R.T.O.,
Pune - 411 001, Maharashtra (INDIA)
www.aissmspoly.org.in

/ AISSMS_POLY