Unit 1

Clean room software engineering

Clean room software engineering is a methodical approach to

software development aimed at producing high quality code with
minimal defects.

1. Statistical usage testing:- software is rigorously tested

against the required specification to ensure that it
functions accurately in real world scenarios. It helps gauge
the software’s behavior in real world.
2. Stepwise Refinement:- this involves gradual refinements
of specification, design , and code , ensuring that each
phase is thoroughly tested and validated before
proceeding to next.
3. Formal methods:- mathematical models and formal
verification techniques are employed to validate the
correctness of software at various stages. This involves
proving properties about the software’s behavior using
logical reasoning and formal proofs.
4. Independent verification:- Clean room practices involves
independent reviews and verification by individual not
directly involved into software development process. This
unbiased scrutiny helps identify potential issues or
oversights that might be missed by the development
team, enhancing the software’s quality
5. Strict coding standards:- Following strict coding standards
and guidelines is crucial in clean room engineering. This
 involves not only writing functions correctly but also is
easy to understand, maintain, and modify.
6. Clear and comprehensive requirements:- ensuring that
the project requirements are well-defined unambiguous
and comprehensive. This forms the corner stone for the
entire development process.
7. Thorough testing regimen:- allocating adequate time and
resources for comprehensive testing at all stages of
development. This includes unit testing, integration
testing, system testing and acceptance testing to detect
and rectify defects in early stage of development cycle.
8. Continuous quality reviews:- implementing a system of
continuous review and evaluation to maintain quality
standards through the project. Regular inspections and
assessment helps identify and address issues promptly.

Personal and Team process model

Personal software process:- this model emphasizes personal

measurements of both the work product that is produced and the
resultant quality of the work product.The PSP model defines five
framework activites
1)Planning: this activity isolates requirements and develops both
Size and resource estimates. In addition, defects estimates(the
number of defects projected for work) is made. All metrics are
recorded on worksheets or templates. Finally development tasks
are identified and project schedule is created.
2)high level design: external specifications for each component to
be constructed are developed and a component design is created.
Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
3)high level design review: formal verification methods are applied
to uncover errors in design. Metrics are maintained for all
important tasks and work results.
4)Development: the component level design is refined and
reviewed. Code is generated, reviewed, compiled and tested.
Metrics are maintained for all important tasks and work results.
5)Postmortem: using the measures and metrics collected, the
effectiveness of the process is determined. Measures and metrics
should provide guidance for modifying the process to improve its
effectiveness

Team software process

Watts Humphrey extended the lessons learned from the

introduction of PSP and proposed a Team software process (TSP).
The goal of TSP is to build a “self directed” project team that
organizes itself to produce high quality software.

Humphrey defines the following objectives for tsp

 Build self directed teams that plan and track their work,
establish goals, and own their processes and plans. These can
be pure software teams or integrated product teams of 3 to 20
engineers
  Show managers how to coach and motivate their teams and
how to help them sustain peak performance
 Accelerate software improvement by making cmm23 level 5
behavior normal and expected.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial grade team skills.

Activities in tsp: project launch, high level design, implementation,

personal team process mode, integration and test and
postmortem.

CMM and CMMI Models

CMM (capability maturity model) :-

CMM is a framework used in software engineering and
development to assess and improve an organization’s software
development processes. The model was developed by the software
engineering institute (SEI) at Carnegie mellon university.

CMM is structured into five maturity levels, each representing a

different stage of process maturity:

1)initial (level 1): in initial level all processes are unpredictable and
chaotic. There is no defined processes in work place all work
happens in a chaotic manner leading to inconsistent result.
Project might lack clear goals or defined goals, causing confusion
and variability in outcomes.
2) managed (level 2): basic processes start to take shape at this
level. Organizations establish some structure by implementing
project management practices. There’s a focus on planning,
tracking, and following basic processes, leading to more stability in
project outcomes.

3) defined (level 3): processes become well-defined and

documented. Standardized processes and procedures are
established across the organization. Team follows consistent
methods, making the development process more repeatable and
reliable.

4) quantitatively managed (level 4): organizations at this level

focus on quantitative analysis. They use metrics and data-driven
approaches to measure and control their processes. The emphasis
is on understanding and improving the quality and effectiveness of
the processes.

5)optimizing (level 5): at the highest level, organization are

continually improving their processes. They innovate, find better
ways of working, implement best practices. The goal is to achieve
ongoing excellence by constantly refining and optimizing processes.
CMMI (capability maturity model integration)

CMMI is a successor of CMM and is a more evolved model that

incorporates best components of individual diciplines.
There are two representations of CMMI :
1)Staged representation:
 Uses a pre-defined set of process areas to define
improvement path.
 Provides a sequence of improvements, where each part in
the sequence serves as a foundation for the next.
 An improved path Is defined by maturity level
 Maturity level describes the maturity of processes in
organization.
 Staged CMMI representation allows comparison between
different organization for multiple maturity levels.
2)Continuous Representation:
 Allows selection of specific process areas.
 Uses capability levels that measures improvement of an
individual process area.
 Continuous CMMI representation allows comparison between
different organization on a process-area-by-process-area basis.
 Allows organizations to select processes which require more
improvement.
  In this representation , order of improvement of various
processes can be selected which allows the organization to
meet their objectives and eliminate risks.

CMMI maturity levels same as CMM.

CMMI capability levels

A capability level includes relevant specific and generic practices for
a specific process area that can improve the organization’s
processes associated with that process area.

1)incomplete (level 0):

 No generic goals are specified for this level.
 Processes are incomplete or partially complete or not
performed
 One or more specific goals of process area are not met
 This capability level is same as maturity level 1
2)performed (level 1):
 Process performance may not be stable
 Objective of quality, cost and schedule may not be me.
 A capability level 1 process is expected to perform all specific
and generic practices for this level.
 Only a start-step for process improvement.
3)managed (level 2):
 Process is planned, monitored and controlled
 Managing the process by ensuring that objectives are achieved
  Objectives are both model and other including cost, quality,
schedule.
 Actively managing processing with the help of metrics

4)defined (level 3):

 A defined process is managed and meets the organization’s set
of guidelines and standards
 Focus is process standardization
5)quantitatively managed (level 4):
 Process is controlled using statistical and quantitative
techniques
 process performance and quality is understood in statical
terms and metrics.
 Quantitative objectives for process quality and performance
are established
6)optimizing (level 5):
 Focuses on continually improving process performance
 Performance is improved in both ways – incremental and
innovative
 Emphasizes on studying the performance result across the
organization to ensure that common causes or issues are
identified and fixed

Verification and Validation

Verification: Verification focuses on ensuring that the software is

being built correctly and according to the defined specifications. It
involves a series of activities that review and evaluate software
artifacts like requirements, design documents, code, and other
development-related documents.

1)requirement verification: this phase involves checking the

requirements to ensure they are clear, complete, consistent, and
achievable. It ensures that the software Is being developed based
on accureate and comprehensive specifications.

2)design verification: reviewing the architectural and detailed

design documents to confirm that they align with the
requirements. It verifies whether the design adequately fulfills the
specified functionality and performance expectations.

3)code verification: inspecting the source code the identify bugs,

coding errors, adherence to coding standards, and conformity to
design specifications. Code review, static analysis, and automated
testing are common verification methods.

4)document verification: ensuring that all documentation related

to the software development process is accurate, complete, and
up-to-date. This includes test plans, user manuals, and technical
documentation.

Validation: validation on the other hand, focuses on ensuring that

the software meets, the user’s actual needs and expectations. It on
volves activities aimed at assessing whether the developed
software satisfies the intended use and provides values in the
intended environment.

1)user requirement validation: confirming that the software fulfills

the user’s needs and objectives. This involves constant
communication and stakeholders to ensure that the software
meets their expectations.

2)functional validation: verifying that the software functions as

intended and delivers the desired features and functionalities. It
involves testing the software against the specified requirements to
ensure that it performs its intended tasks accurately.

3)acceptance testing: conducting tests to determine if the software

meets the acceptance criteria set by the stakeholders. This often
involves user acceptance testing(UAT) where the end-users or
clients assess the software’s usability and functionality.

4)performance testing: ensuring that the software operates

efficiently and effectively under various condition, such as stress
testing, load testing, and scalability testing.

Unit 2
Prioritize software requirements bases on kano analysis

Kano Analysis is a technique used to prioritize software

requirements based on customer satisfaction and the impact these
requirements have on users. It categorizes requirements into
different groups based on how they are perceived by customers.
Here's how you can prioritize software requirements using Kano
Analysis:

Steps to Prioritize Software Requirements using Kano Analysis:

1)identify and list requirements: Gather all the requirements for

your software product. These can be collected from various
stakeholders, user feedback, market research, and business
objectives.
2) Categorize Requirements using Kano Analysis:
 Performance requirements: These are basic requirements
that, when met, satisfy customers but don't necessarily delight
them. They are expected features and functionalities.
 Excitement or delighters: These are unexpected or innovative
features that can significantly increase customer satisfaction
when delivered. They often go beyond customer expectations.
 Must-Be or Basic Requirements: These are essential
functionalities that, if absent, significantly decrease customer
satisfaction. They are the minimum requirements needed for
the product to be considered acceptable.
3)create a kano analysis grid: create a matrix or grid with the
identified requirements categorized into the kano categories: must-
be, performance, and excitements/delighters

4)gather customer input: Conduct surveys, interviews, or focus

groups with customers or potential users to collect their feedback
on each requirement. Use techniques like questionnaires or direct
feedback sessions to understand how customers perceive each
requirement.

5)evaluate and classify requirements: Based on the collected

feedback, classify each requirement into its respective Kano
category. Some requirements may shift categories based on
customer responses.

6)prioritize requirements:
 Must-Be Requirements: These are non-negotiable and should
be prioritized as they directly impact user satisfaction.
 Performance Requirements: Prioritize these based on the
level of satisfaction they provide. High satisfaction features
might be prioritized over others.
 Excitement/Delighters: Consider implementing these
innovative features selectively, based on their potential impact
on customer satisfaction and the resources available.

7)iterate and refine: Kano Analysis isn't a one-time process. It's

iterative. As you gather more data or as market preferences
change, reassess and update the prioritization of requirements.
8)develop roadmap or backlog: Create a roadmap or backlog that
reflects the prioritization of requirements based on the Kano
Analysis. This roadmap will guide the development team in
implementing features based on customer satisfaction and
business impact.

Unit 3
Agile methodology for project development
1. Scrum:
Framework: Scrum divides work into time-boxed iterations called
sprints, each lasting 1-4 weeks. It involves defined roles (Product
Owner, Scrum Master, and Development Team) and ceremonies
like daily stand-ups, sprint planning, reviews, and retrospectives.
Focus: Collaboration, transparency, and adaptability to changing
requirements. It emphasizes delivering incremental value in short
cycles.
2. Kanban:
Method: Kanban visualizes work on a board with columns
representing different stages. It emphasizes limiting work in
progress (WIP) to improve flow and focuses on continuous delivery
by pulling work as capacity allows.
Focus: Optimizing flow, reducing bottlenecks, and responding
quickly to changes.
3. Extreme Programming (XP):
Practices: XP emphasizes engineering practices for high-quality
software. It includes pair programming (two developers coding
together), test-driven development (writing tests before code),
continuous integration (frequent integration of code changes), and
simple design.
Focus: Rapid feedback, customer involvement, and delivering
valuable software with high quality.
4. Lean Software Development:
Principles: Derived from Lean manufacturing, Lean Software
Development focuses on eliminating waste, optimizing flow, and
delivering value. It includes principles like value stream mapping,
just-in-time delivery, and continuous improvement (Kaizen).
Focus: Identifying and eliminating non-value adding activities,
ensuring the shortest path to value delivery.
5. Crystal:
Variants: Crystal methodologies come in different flavors (Crystal
Clear, Crystal Yellow, etc.) tailored to different project sizes and
team characteristics. They prioritize communication, team
interaction, and adapting processes based on team size.
Focus: Reflects a people-centric approach, emphasizing teamwork
and flexibility in adapting practices.
6. Dynamic Systems Development Method (DSDM):
Framework: DSDM provides a framework for developing software
iteratively and incrementally. It involves specific roles (like Business
Sponsor, Business Visionary) and phases (Feasibility, Foundations,
Exploration, Engineering, Deployment).
Focus: Emphasizes on-time delivery of products that meet the
business needs while managing risks effectively.
7. Feature-Driven Development (FDD):
Approach: FDD emphasizes designing and building features one at a
time. It involves domain object modeling, developing by feature,
and frequent builds.
Focus: Breaking down complex systems into manageable
components (features) and delivering them iteratively.
8. Adaptive Software Development (ASD):
Principles: ASD focuses on collaboration, constant learning, and
adapting to changing circumstances. It includes speculation,
collaboration, and learning cycles to drive development.
Focus: Adapting to changes, maintaining flexibility, and
continuously improving processes and products.
9. Disciplined Agile Delivery (DAD):
Framework: DAD provides a decision framework for Agile
practitioners, allowing teams to select and tailor their way of
working based on their context. It includes lifecycles, practices, and
roles from Agile to traditional methods.
Focus: Supporting a full range of project types and providing
guidance on how to choose practices that best suit the project at
hand.
10. Pair programming:
Pair programming, a practice within Extreme Programming (XP),
involves two developers working together at one workstation. One
person writes the code (the "driver"), while the other reviews each
line, suggests improvements, and navigates the code's direction
(the "navigator").

Pair programming
Pair programming, an integral practice in Agile development
methodologies, involves two programmers jointly working on code
at a single workstation. One assumes the role of the "driver,"
responsible for actively writing the code, while the other takes the
position of the "navigator," offering feedback, reviewing the code
in real time, and considering broader strategic approaches.
This collaborative approach fosters numerous benefits. Firstly, it
enables continuous peer review, ensuring that the code is
thoroughly inspected as it's being written, leading to early bug
detection and higher code quality. The navigator's role also extends
to suggesting improvements, discussing design decisions, and
sharing knowledge, creating an environment conducive to learning
and skill-sharing among team members.
Beyond the technical advantages, pair programming also greatly
influences team dynamics. It encourages effective communication,
trust, and shared responsibility within the development team. The
shared ownership of the codebase strengthens collective
accountability and often results in a more cohesive and engaged
team.
While initially perceived as a resource-intensive practice, pair
programming has shown to improve overall productivity by
reducing the time spent on debugging and rework. Moreover, it
brings a diversity of perspectives and ideas to problem-solving,
often leading to more innovative solutions and robust code
architectures.
Despite its advantages, pair programming might not suit every
individual or situation. However, for teams that adopt it, this
collaborative approach significantly contributes to delivering high-
quality software, fostering a culture of continuous learning, and
enhancing team collaboration and efficiency.

Test driven development

Test-Driven Development (TDD) is a software development

approach that operates within the Agile methodology framework,
emphasizing writing tests before writing the actual code. This
practice involves creating automated tests that define the expected
behavior of the code before the implementation phase begins. The
process follows a repetitive cycle known as the "Red-Green-
Refactor" cycle.
The cycle starts with the "Red" phase, where a failing test is written
to articulate the desired functionality. This initial test, having no
corresponding code, naturally fails. Subsequently, the "Green"
phase involves writing the minimum code required to pass the
failing test. This code might be minimalistic and might not cover all
scenarios but fulfills the immediate test requirement. Finally, the
"Refactor" phase focuses on improving the code's design,
efficiency, and maintainability while ensuring the test still passes.
This cycle iterates continuously, with each cycle leading to
improved code quality and functionality.
The advantages of TDD are numerous. It promotes higher code
quality by encouraging a focus on writing code that specifically
meets the intended functionality outlined by the tests. Additionally,
it reduces debugging time as issues are caught and addressed early
in the development cycle, leading to more efficient and reliable
code. Furthermore, TDD's emphasis on frequent refactoring
improves the codebase's design, making it more adaptable to
changes and enhancements.
However, TDD might pose challenges, especially for developers
accustomed to traditional coding practices. It requires a mindset
shift to write tests before writing code and might initially appear
slower due to the time invested in creating tests upfront. Yet, over
time, TDD generally leads to faster development cycles by reducing
debugging and rework time while ensuring a more stable and
maintainable codebase.
In essence, TDD isn't just about testing; it's a design approach that
shapes the development process. Its focus on creating a
comprehensive suite of tests before code implementation aligns
with Agile principles, fostering better code quality, faster feedback
loops, and a more adaptable development environment.

Burndown Chart

A burn-down chart is a valuable project management tool utilized

in Agile methodologies to visually represent the progress of work
completed against time during a project's lifecycle. It serves as a
graphical representation that tracks the remaining work to be done
(often measured in tasks, story points, or hours) on the vertical
axis, while the horizontal axis typically represents time, broken
down into iterations or sprints.
The primary purpose of a burn-down chart is to provide a clear and
visual representation of how effectively a team is progressing
towards completing the planned work within a specific timeframe.
As the team completes tasks or user stories, the chart depicts a
decreasing trendline ("burning down") that illustrates the reduction
in the amount of work remaining over time.
Key Components and Benefits of Burn-Down Charts:
Tracking Progress: The chart allows teams and stakeholders to
track the completion of work against the planned schedule. It
provides a snapshot of the actual progress made compared to the
anticipated progress.
Forecasting and Predictability: By observing the trendline, teams
can predict whether they are on track to complete the work within
the scheduled time. It helps in forecasting and adjusting plans if
needed to ensure timely delivery.
Identifying Issues and Trends: Sudden deviations from the
expected trendline can signal potential issues or impediments. It
enables teams to identify problems early and take corrective
actions promptly.
Facilitating Decision-Making: The visual representation of the
burn-down chart aids in making informed decisions regarding
resource allocation, scope adjustments, or other modifications
necessary to meet project goals.
Transparency and Communication: Burn-down charts promote
transparency within the team and with stakeholders. They offer a
shared understanding of progress, fostering effective
communication and collaboration.
Extreme Programming (XP)

Extreme Programming (XP) is a software development

methodology and a set of practices that emphasize rapid and
flexible development while focusing on high software quality and
customer satisfaction.
Extreme programming principles / values
• Communication
• Courage
• Feedback
• Simplicity
Key practices in extreme programming
1. Planning :planning the current activity that involves customers
and developers
2. Small releases : delivering the project in small and frequent
chunks to the customer
3. Continues integration: continuously integrating the codes
written by the developers onto a single repository for a stable
software product
4. Test driven development: writing test cases before writing the
actual code for the software improves the quality of the software
product
5. Refactoring: regularly modifying the code written for software
product without modifying its behavior improves
Agile Manifesto
The Agile Manifesto is a foundational document that outlines the
guiding values and principles of Agile software development. It was
created in 2001 by a group of software developers who sought
better ways of developing software that would prioritize customer
collaboration, adaptability to change, and delivering valuable
software.
 Individual and interactions: in agile development, self-
organization and motivation are important, as re interactions
like co-location and pair programming.
 Working software: demo working software is considered the
best means of communication with the customer to
understand their requirements, instead of just depending on
documentation.
 Customer collaboration: as the requirements cannot be
gathered completely in the beginning of the project due to
various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to changes: agile development is focused on quick
responses to change and continuous development.
Agile principles
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
4. Business People and Developers Must Work Together Daily
throughout the Project.
5. Build Projects around Motivated Individuals.
6. The Most Efficient and Effective Method of Conveying
Information to and within a Development Team is face-to-face
communications.
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.
Scrum
Scrum is an Agile framework used in software development and
other fields to manage complex projects.
Scrum roles
1. Scrum master: scrum master is typically a project manager or
a team leader responsible for managing the overall
development process of a software product
2. Product owner: product owner is the actual entity that owns
the product it may a individual customer or a organization or
may be a project manager
3. Development team: development team is the actual team that
is currently engaged into the development of the software
product
Events in scrum / process flow
1. Sprint: sprint is a time bound development phase typically
lasting 2 to 4 weeks in which development team completes the
tasks created into the sprint
2. Sprint planning: it is just the planning phase for the sprint.
Before starting a sprint a meeting is conducted in which the
task needed to be done in the sprint are decided.
3. Daily scrum: daily scrum is the daily stand-up meeting typically
lasting 10 – 15 minutes where team discusses the progress of
the current spirnt.
4. Sprint review: at the end of each sprint the team conducts a
review to showcase tasks completed during the sprint to the
stakeholders and to gather feedback from them.
5. Sprint restrospection: after every sprint team organizes a
retrospection event to analyze the performance of sprint and
identify areas for improvement
 Scrum Artifacts / process flow
1. Product backlog: this is the list of all the features, user
stories and tasks needed to be developed of the software
product.
2. Sprint backlog: this is the list of items from product backlog
that development team commit to deliver in a single sprint.
3. Increment: it is the potentially shippable product developed
by the team.
Advantages
• Large projects are divided into manageable amounts.
• Software developments are coded and tested during the sprint
view.
• Works well for fast-moving development projects.
• Scrum, being Agile, adopts feedback from customers and
stakeholders.
• Individual efforts of each team member is visible during daily
scrum meetings.
• Short sprints enable changes based on feedback a lot more easily.

Disadvantages
• Scrum often leads to scope creep, due to lack of a definite end
date.
• The chances of project failure are high if individuals aren't very
committed or
cooperative
• Adopting the Scrum framework in large teams is challenging
• The framework can be successful only with experienced team
members
• Daily meetings sometimes frustrate team members
• If any team member leaves in the middle of a project, it can have
a huge negative
impact on the project
• Quality is hard to implement until the team goes through an
aggressive testing
process
Unit 4
Project initiation
 Project initiation is the first phase of a project’s life cycle. It is
at this point where the opportunity or reason for the project is
identified and a project is developed to take advantage of that
opportunity.
 It is during this phase of the project that a team is assembled,
assigning responsibilities and a business case is created to
define the project in detail.
 A business case is used to explain the reason for starting a
project. The business case shows how to use of financial and
other resources are in support of a business need.

Project scope management

 Project scope management is a part of the project planning
process that helps in determining and documenting the list of
all the project goals, tasks, deliverables, deadlines, and
budgets as a part of the planning process
 The scope is defined by understanding the project
requirements and the client’s expectations. The scope
statement usually contains.
o Project deliverables
o Exclusions
o Project constraints
o Assumptions
 Six process involved in accurately identifying the project scope
management: