SE&PM (21CS61) Lecture Notes 1

Chapter 3

Agile Development

3.1 What is agility?

 An agile team is a nimble team which is adaptable and capable of responding

effectively to changes.
 Change is intrinsic to software development, whether its changes in the
software being developed, changes in team members, new technologies, or
any other factors that may influence the product or project.
 Embracing change should be an integral part of our approach to software
development, as it is fundamental to the process.
 An agile team understands that software is created by individuals working
collaboratively, and the success of the project hinges on their skills and ability
to work together.
 Agility goes beyond responding effectively to change.
 Promotes team structures and attitudes that facilitate communication
among team members, technologists and business people, and software
engineers and their managers.
 Prioritizes the rapid delivery of functional software, often reducing the focus
on intermediate work products.
 Includes the customer as part of the development team to eliminate the "us
and them" mentality prevalent in many software projects.
 Acknowledges the limitations of planning in an uncertain world and
emphasizes the need for flexible project plans.

3.2 Agility and Cost of change

An agile process reduces the cost of change because software is released in

increments and change can be better controlled within an increment.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 2

 Conventional knowledge in software development, supported by decades

of experience, suggests that the cost of change increases nonlinearly as a
project progresses (illustrated by Figure above, solid black curve).
 Accommodating changes is relatively easy during the requirements
gathering phase early in a project.
 Early changes might involve modifying a usage scenario, extending a list
of functions, or editing a written specification, all of which have minimal
costs and do not significantly impact the project timeline.
 However, if a major functional change is requested during the middle of
validation testing (which occurs late in the project), the situation is more
complex.
 This late-stage change might require modifications to the architectural
design, the design and construction of three new components, changes to
five existing components, and the design of new tests.
 Costs escalate quickly, and ensuring the change is implemented without
unintended side effects requires substantial time and effort.\
 Proponents of agility argue that a well-designed agile process "flattens" the
cost of change curve (Figure above shaded, solid curve).
 This flattening allows a software team to accommodate changes late in a
project without significant cost and time impacts.
 The agile process includes incremental delivery.
 When incremental delivery is combined with other agile practices, such as
continuous unit testing and pair programming, the cost of making changes
is reduced.
 Although there is ongoing debate about how much the cost curve flattens,
evidence suggests that a significant reduction in the cost of change can be
achieved.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 3

3.3 What is an agile process?

Key assumptions about the majority of software projects:

 It is challenging to foresee which software requirements will remain constant

and which will evolve. Similarly, anticipating how customer priorities will shift
as the project progresses is equally difficult.
 For various types of software, design and construction are intertwined. This
means that both activities should occur concurrently, allowing design models
to be validated as they are developed. Predicting the amount of design
required before construction can validate it is challenging.
 Analysis, design, construction, and testing phases are not as predictable from
a planning perspective as desired.
Given these three assumptions, a crucial question emerges: How can we
develop a process capable of handling unpredictability? As previously
mentioned, the key lies in the adaptability of the process to swiftly adjust to
changing project and technical circumstances.

Therefore, an agile process must be flexible and adaptable. Also holds the below
features:
 An agile software process must adapt incrementally.
 Customer feedback is essential for making appropriate adjustments.
 Operational prototypes or parts of the system are effective catalysts for
gathering customer feedback.
 An incremental development strategy should be implemented.
 Software increments (working prototypes or segments of the operational
system) must be delivered in short time frames.
 Delivering increments quickly helps keep pace with changes and
unpredictability.
 This iterative approach allows customers to regularly evaluate the software
increment.
 Customers can provide crucial feedback to the development team.
 Customer feedback influences process adaptations.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 4

3.3.1 Agility 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, 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.
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.

3.3.2 The Politics of Agile Development

 There is heated debate between proponents of agile and traditional software

development methods.
 Agilists are favoring practical systems over exhaustive documentation, while
critics see agile as lacking scalability for enterprise software.
 These debates often devolve into ideological conflicts, sidelining rational
decision-making in favor of beliefs.
 The central issue is how to achieve agility effectively and build software that
meets current needs while being scalable for future demands.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 5

 Agile encompasses various process models, each offering unique approaches

to agility.
 Agile principles often innovate upon established software engineering
practices rather than outrightly replacing them.
 Combining the strengths of both agile and traditional methods can yield
more comprehensive solutions to modern software challenges.

3.3.3 Human Factors

Key traits that must exist among the people on an effective software team

1. Competence: In the context of agile development, "competence" includes

inherent abilities, specialized software skills, and a comprehensive
understanding of the chosen development process. Skills and process
knowledge can and should be imparted to all individuals serving as members of
agile teams.
2. Common focus: While agile team members may have varying roles and skills,
they should all share a unified objective: delivering a functional software
increment to the customer within the agreed-upon timeframe. To achieve this
objective, the team will prioritize ongoing adjustments—both minor and
significant—that align the process with the team's evolving needs.
3. Collaboration: Software engineering, regardless of the process, revolves
around assessing, analysing, and using communicated information within the
team. It also involves creating information that clarifies the team's work to
stakeholders and developing software and databases that provide business
value to customers. Collaboration among team members and with stakeholders
is crucial for achieving these objectives effectively.
4. Decision-making: Effective decision-making is crucial for any competent
software team, including agile teams. It is essential that the team has the
autonomy to control its own direction, granting them authority over both
technical and project-related decisions.
5. Fuzzy problem-solving ability: Software managers need to understand that
agile teams will consistently face uncertainty and be subject to frequent
changes. At times, the team must acknowledge that the current problem they
are addressing may not be the same problem they need to solve in the future.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 6

6. Mutual trust and respect: A cohesive team demonstrates the essential trust
and respect that make them "so tightly bonded that their collective strength
surpasses the individual contributions."
7. Self-organization: In agile development, self-organization entails three
aspects: (1) the agile team organizes itself to accomplish the tasks at hand, (2) it
structures the process to suit its specific environment, and (3) it schedules work
to optimize software delivery. Beyond technical advantages, self-organization
significantly enhances collaboration and boosts team morale.

3.4 Extreme Programming (XP)

Extreme Programming (XP) is a software development methodology that

emphasizes iterative development, collaboration, flexibility, and customer
satisfaction. It was created by Kent Beck in the late 1990s and has since become
one of the prominent agile methodologies.

3.4.1 XP Values

Kent Beck outlines a core set of five values that underpin all activities within
Extreme Programming (XP): communication, simplicity, feedback, courage, and
respect. Each of these values serves as a guiding principle for specific XP
practices and tasks.

 Effective communication in XP is facilitated through close, informal

collaboration between software engineers and stakeholders. This verbal
interaction helps establish necessary software features and functions,
using effective metaphors to convey key concepts. XP also prioritizes
continuous feedback over extensive documentation, ensuring that
communication remains dynamic and responsive to evolving needs.

 Simplicity in XP is achieved by focusing on immediate requirements rather

than speculative future needs. This approach aims to create
straightforward designs that are easier to implement. If necessary,
designs can be refined through refactoring at a later stage.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 7

 Feedback in XP is derived from multiple sources: the implemented

software itself, direct input from customers, and insights from team
members. This feedback loop is supported by robust testing strategies,
where unit tests and acceptance tests provide critical insights into
software functionality and user satisfaction.

 Adhering strictly to XP practices requires courage or discipline, as it resists

the temptation to over-design for future scenarios that may never
materialize. Instead, XP teams focus on delivering value in the present,
prepared to adapt as requirements evolve.

 Through these values, XP fosters mutual respect among team members

and between stakeholders, cultivating a culture of collaboration and
appreciation for the software development process. Successful delivery
of software increments reinforces respect for XP principles and practices
within the team.

3.4.2 The XP Process

Extreme Programming (XP) adopts an object-oriented methodology as its

primary development paradigm. It incorporates a structured set of rules and
practices that revolve around four core framework activities: planning, design,
coding, and testing.
Figure 3.2 provides an overview of the XP process, highlighting essential
concepts and tasks associated with each framework activity. The following
paragraphs summarize key XP activities.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 8

Planning
The planning activity, also known as the planning game in Extreme Programming
(XP), initiates with a crucial phase of listening. This involves gathering
requirements, enabling technical members of the XP team to grasp the business
context of the software and understand the necessary outputs, major features,
and functionalities. Through this listening phase, a set of "stories" (also referred
to as user stories), which describe the required outputs, features, and
functionalities of the software, are created by the customer and written on
index cards.
 Each story is assigned a value or priority by the customer based on its
business significance. Subsequently, members of the XP team assess each
story and assign a development cost, typically measured in weeks.
 If a story is estimated to require more than three weeks, the customer is
encouraged to split it into smaller stories, and the value and cost assignment
process is repeated. Importantly, new stories can be introduced at any point
in the planning process.
 Customers and developers collaborate closely to determine how to group
these stories into the next software release or increment to be developed by
the XP team.
 Once a foundational commitment is made for a release, which includes
agreements on the stories to be included, the delivery date, and other
project details, the XP team prioritizes and orders the stories in one of three
ways: (1) all stories are implemented concurrently within a few weeks, (2)
stories with the highest business value are prioritized and scheduled first, or
(3) stories perceived to carry the highest risk are prioritized and addressed
first.
 Following the delivery of the initial project release or software increment,
the XP team calculates the project velocity. Project velocity, simply put,
quantifies the number of customer stories successfully implemented during
the initial release. This metric serves two main purposes: (1) it aids in
estimating delivery dates and schedules for subsequent releases and (2) it
helps identify if there has been an over-commitment across all stories
throughout the entire development project. If an over-commitment is
detected, adjustments are made to the content of future releases or to the
final delivery dates.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 9

 Throughout the development process, the customer retains the ability to

introduce new stories, adjust the value of existing stories, split stories
further, or remove them altogether. The XP team continuously reassesses
remaining releases and adjusts its plans accordingly based on these changes.

Design

 XP adheres strictly to the principle of KIS (keep it simple), prioritizing

simplicity in design over complexity. Designs in XP are tailored precisely to
guide the implementation of each story, avoiding unnecessary additions
based on future assumptions of functionality needs.

 XP promotes the use of CRC (class-responsibility-collaborator) cards as a tool

for organizing object-oriented classes relevant to the current software
increment. These cards are central to XP's design process, serving as the
primary design artefact.

 When facing challenging design issues while working on a story, XP advocates

for creating an operational prototype immediately—a practice known as a
spike solution. This prototype helps reduce risks during actual
implementation and validates the initial estimates for the story containing
the design challenge.

 In the earlier section, we discussed XP's endorsement of refactoring—a

construction approach that also serves as a means to optimize design.
Refactoring involves altering a software system in a manner that does not
change its external behavior but enhances its internal structure. It's a
systematic approach to cleaning up code, which reduces the risk of
introducing bugs. Essentially, refactoring improves the code's design after it
has been written. Refactoring improves the internal structure of a design (or
source code) without changing its external functionality or behavior.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 10

Coding
 After completing the development of stories and initial design work, the
team focuses on creating a set of unit tests for each story planned for the
current software release (increment). These tests ensure that each story's
requirements are properly exercised and validated.
 Following the creation of unit tests, developers concentrate on implementing
only what is necessary to pass these tests, adhering to the KIS (keep it simple)
principle. Once the code is written, it is immediately subjected to unit testing,
providing instant feedback to developers.
 During the coding phase, a prominent practice in XP is pair programming,
where two developers collaborate at a single workstation to write code for a
story. This approach facilitates real-time problem-solving and quality
assurance, as the code is continuously reviewed as it is being written.
 Pair programming also helps maintain focus on the task at hand, with each
person taking on complementary roles—for instance, one may handle coding
specifics while the other ensures adherence to XP's coding standards or
verifies that the code satisfies the established unit tests.
 As pair programmers complete their work, the code they produce is
integrated with that of others. Integration can occur daily by a dedicated
integration team or be managed directly by the pair programmers
themselves. This practice of continuous integration minimizes compatibility
issues and interfaces problems.

Testing
In XP, a fundamental practice is to create unit tests before starting coding. These
tests should be developed using an automated framework, allowing them to be
executed easily and repeatedly. This approach supports a regression and
integration testing strategy whenever code is modified, aligning with XP's
philosophy of frequent refactoring. Organizing individual unit tests into a
"universal testing suite" [Wel99] enables daily integration and validation testing
of the system. This continuous testing strategy provides ongoing feedback on
progress and helps detect issues early.

According to Wells [Wel99], addressing small issues every few hours is more
efficient than dealing with major problems right before a deadline.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 11

XP acceptance tests, also known as customer tests, are defined by the customer
and focus on validating overall system features and functionalities that are
visible and reviewable by the customer. These tests are derived from user
stories implemented in each software release.

3.4.3 Industrial XP
Joshua Kerievsky characterizes Industrial Extreme Programming (IXP) as a
natural progression of XP, enriched with XP's core values of simplicity, customer
focus, and test-driven development. However, IXP diverges from traditional XP
by placing greater emphasis on management involvement, enhancing customer
participation, and refining technical methodologies. It introduces six additional
practices tailored to ensure the effective implementation of XP in substantial
projects within larger organizations.

Readiness assessment: Before commencing an IXP project, the organization

must perform a readiness assessment. This evaluation determines whether
(1) The development environment can adequately support IXP
(2) The team comprises the right stakeholders.
(3) There is a defined quality program and commitment to continuous
improvement within the organization.
(4) The organizational culture aligns with the agile team values.
(5) The broader project community is appropriately engaged.

Project community: Classic XP emphasizes assembling a skilled, adaptable team

for project success. In larger organizations, this evolves into a community model
where key figures like technologists and customers, alongside peripheral
stakeholders such as legal, quality, and sales representatives, all contribute to
the project's success. IXP mandates clear definition of community roles and
effective communication channels among members.

Retrospectives: After delivering a software increment, an IXP team conducts a

focused technical review known as a retrospective. This review evaluates
"issues, events, and lessons learned" from either the software increment or the
entire software release with the goal of enhancing the IXP process.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 12

Continuous learning: As continuous process improvement relies heavily on

learning, XP team members are encouraged to explore and adopt new methods
and techniques that can enhance the quality of the product.

Project chartering: The IXP team evaluates the project to ascertain if there is a
valid business justification and whether the project aligns with the
organization's overarching goals and objectives. Chartering also analyses the
project's context to understand its relationship with existing systems or
processes, whether it complements, extends, or replaces them.

Test-driven management: In an IXP project, there is a need for clear,

measurable criteria to evaluate the project's current state and its progress. Test-
driven management sets specific measurable "milestones" and establishes
mechanisms to determine if these milestones have been achieved.

3.4.4 The XP Debate

 Requirements volatility: Customers actively participate in the XP team,
leading to informal requests for changes that can alter project scope.
 Conflicting customer needs: Projects often involve multiple customers,
each with their own distinct requirements.
 Informal requirement expression: XP relies on user stories and
acceptance tests as the primary means of documenting requirements,
necessitating thorough specification to resolve inconsistencies and errors
before development.
 Lack of formal design: XP prioritizes iterative development over upfront
design, focusing on evolving software structure to ensure quality in
complex systems.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 13

3.5 OTHER AGILE PROCESS MODELS

Several other agile process models have been proposed and are widely utilized
in the industry:
 Adaptive Software Development (ASD)
 Scrum
 Dynamic Systems Development Method (DSDM)
 Crystal
 Feature Drive Development (FDD)
 Lean Software Development (LSD)
 Agile Modeling (AM)
 Agile Unified Process (AUP)

Adaptive Software Development (ASD)

Jim Highsmith introduced Adaptive Software Development (ASD) as a method
for constructing complex software and systems. ASD's foundation emphasizes
human collaboration and team self-organization. Highsmith contends that an
agile and adaptive development approach, rooted in collaboration, provides
structure amid complex interactions akin to discipline and engineering. He
outlines an ASD "life cycle" comprising three phases: speculation, collaboration,
and learning.
Speculation: In the speculation phase, the project begins with adaptive cycle
planning. This planning process utilizes project initiation details such as the
customer's mission statement, project constraints (like delivery dates or user
descriptions), and fundamental requirements to outline the series of release
cycles (software increments) needed for the project.
Collaboration: Motivated individuals leverage collaboration to amplify their
talent and creative output beyond mere numbers. This principle is a recurring
theme in all agile methodologies. However, collaboration is complex—it
involves communication and teamwork while also valuing individual creativity.
Trust is paramount in collaboration, where team members must trust each other
to
(1) Provide constructive criticism,
(2) Offer assistance without resentment,
(3) Commit to the work with diligence,
(4) Possess the necessary skills to contribute effectively, and

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 14

(5) Communicate issues or concerns in a manner that facilitates productive

action.
Learning: As ASD team members commence developing components within an
adaptive cycle, the focus is equally on "learning" as it is on advancing towards
completing the cycle.

Scrum
Scrum, an agile software development method originated by Jeff Sutherland and
his team in the early 1990s, aligns with the principles of the agile manifesto. It
guides development activities through a framework that encompasses
requirements, analysis, design, evolution, and delivery. Work tasks within each
of these activities are structured into time-bound iterations called sprints. The
Scrum team adapts and refines tasks in real-time to address current project
challenges. The overall flow of the Scrum process is depicted in the
accompanying diagram.
Scrum prioritizes a collection of software process patterns that have
demonstrated effectiveness in projects characterized by tight deadlines,
evolving requirements, and critical business demands.
Each of these patterns outlines a series of development actions:
Backlog - refers to a prioritized list of project requirements or features that
deliver business value to the customer. Items can be added to the backlog

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 15

continuously. The product manager evaluates the backlog and adjusts priorities
as necessary.
Sprints - are comprised of work units necessary to fulfil a requirement outlined
in the backlog, all within a fixed time-box (usually around 30 days). No changes,
such as introducing new backlog items, are permitted during the sprint. This
approach enables team members to operate within a short-term, yet stable,
environment.
Scrum meetings, also known as daily stand-ups, are brief gatherings held daily
by the Scrum team, typically lasting around 15 minutes. During these meetings,
each team member answers three key questions:
 What have you accomplished since the last team meeting?
 What obstacles or challenges are you currently facing?
 What do you aim to achieve by the next team meeting?
These questions ensure team members stay informed, address any issues
promptly, and maintain alignment on project progress.
A Scrum master, serving as the team leader, facilitates the meeting and
evaluates responses from each team member. The Scrum meeting aids in early
detection of potential issues and promotes knowledge sharing among team
members.
Demos - involve presenting the software increment to the customer, allowing
them to evaluate the implemented functionality. It's important to highlight that
the demo may not include all planned features but focuses on delivering
functionalities within the established time-box.

Dynamic Systems Development Method (DSDM)

 Dynamic Systems Development Method (DSDM) is an agile software
development approach.
 It aims to build and maintain systems meeting tight time constraints using
incremental prototyping.
 DSDM philosophy is based on a modified version of the Pareto principle: 80%
of application functionality can be delivered in 20% of the time required for
the complete application.
 DSDM follows an iterative software process where each iteration adheres to
the 80% rule.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 16

 Each increment includes enough work to progress to the next stage;

remaining details are completed later as more business requirements
emerge or changes are accommodated.
The DSDM life cycle that defines three different iterative cycles, preceded by
two additional life cycle activities:
Feasibility study: A feasibility study in the context of DSDM defines the
fundamental business requirements and constraints of the application to be
developed. It evaluates whether the application is suitable for the DSDM process
based on these criteria.
Business study: It defines the functional and informational requirements
necessary for the application to deliver business value. Additionally, it outlines
the fundamental application architecture and specifies the requirements for
maintaining the application over time.
Functional model iteration: During the functional model iteration, a series of
incremental prototypes are developed to showcase functionality to the
customer. The goal of this iterative process is to gather additional requirements
by obtaining feedback from users as they interact with the prototype.
Implementation: Implementation in DSDM involves deploying the latest
software increment into the operational environment. It's important to note
that either the increment may not be fully complete or changes may be
requested during implementation. In either scenario, DSDM development
progresses by returning to the functional model iteration activity.

Crystal
 Alistair Cockburn and Jim Highsmith created the Crystal family of agile
methods.
 The emphasis is on "manoeuvrability" in software development.
("maneuverability" refers to the ability to swiftly adapt and respond to changes, challenges, and
opportunities throughout the development process. It involves being flexible, agile, and responsive
to evolving requirements, market conditions, and technological advancements.)
 Cockburn describes it as a resource-limited, cooperative game centered
on invention and communication.
 The primary goal is to deliver useful, working software, with a secondary
goal of preparing for subsequent iterations.
 The Crystal family offers a range of agile processes tailored for different
project types.
MRS. DEEKSHA DEPARTMENT OF CS&E
 SE&PM (21CS61) Lecture Notes 17

 Agile teams can select the Crystal method that best fits their project and
environment.

Feature Driven Development (FDD)

Feature Driven Development (FDD) originated from Peter Coad and his
colleagues as a pragmatic process model for object-oriented software
engineering. Stephen Palmer and John Felsing further developed Coad's ideas,
presenting FDD as an adaptive and agile approach suitable for medium to large-
scale software projects.
Similar to other agile methodologies, FDD embraces a philosophy that prioritizes
three key principles:
(1) Fostering collaboration among team members
(2) Addressing project complexity through feature-based decomposition and the
integration of software increments, and
(3) Communicating technical details using verbal, graphical, and text-based
methods.
FDD places significant emphasis on ensuring software quality through several
practices: adopting an incremental development strategy, conducting design
and code inspections, performing software quality assurance audits, collecting
metrics, and utilizing patterns for analysis, design, and construction.

In the context of FDD, a feature is defined as a client-valued function that can

be implemented within a two-week timeframe or less. This focus on defining
features offers several advantages:
 Features are small, making them easier for users to describe and understand
their relationships.
 Features can be organized into hierarchical business-related groups.
 Operational features are developed every two weeks, as each feature serves
as a deliverable software increment.
 Due to their size, the design and code of features are more manageable and
conducive to effective inspection.
 Project planning, scheduling, and tracking are driven by the feature hierarchy
rather than arbitrary software engineering tasks.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 18

Template for defining a feature:

 FDD emphasizes project management guidelines and techniques more than

many other agile methods.
 As projects grow in size and complexity, ad hoc project management
becomes inadequate.
 It's crucial for developers, managers, and stakeholders to understand project
status and encountered challenges.
 During tight deadline situations, it's essential to ensure proper scheduling of
software increments (features).
 FDD defines six milestones for each feature during design and
implementation:
a. Design walkthrough
b. Design
c. Design inspection
d. Code
e. Code inspection
f. Promote to build

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 19

Lean Software Development (LSD)

Lean Software Development (LSD) applies lean manufacturing principles to
software engineering. These principles can be summarized as:
 Eliminate waste
 Build quality in
 Create knowledge
 Defer commitment
 Deliver fast
 Respect people
 Optimize the whole

In the context of agile software projects, eliminating waste involves:

 Avoiding unnecessary features or functions
 Assessing the cost and schedule impact of new requirements
 Removing redundant process steps
 Improving information retrieval for team members
 Enhancing testing processes to detect errors effectively

Agile Modeling (AM)

Agile Modeling (AM) is a methodology focused on the efficient modeling and
documentation of software-based systems. It consists of values, principles, and
practices tailored for modeling software in a lightweight and effective manner
within software development projects. Agile models are prioritized for
effectiveness rather than perfection, distinguishing them from traditional
models.

AM aligns with the values outlined in the Agile Manifesto. It emphasizes the
importance of making decisions courageously, even if it means rejecting a design
and refactoring it. Additionally, the philosophy acknowledges that technologists
may not have all the answers, encouraging respect and collaboration with
business experts and other stakeholders.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 20

Agile Modeling proposes a variety of "core" and "supplementary" modeling

principles. The unique principles that distinguish AM include:
Model with a purpose: Model with a purpose in Agile Modeling entails having a
clear objective before creating the model. By identifying the goal of the model
upfront, the developer can determine the appropriate notation and level of
detail needed more effectively.
Employ multiple models: There exists a variety of models and notations
available for describing software, though only a select few are typically essential
for most projects. Agile Modeling (AM) recommends that each model should
offer a distinct perspective of the system, and only those models that deliver
value to their intended audience should be utilized.
Travel light: Travel light in Agile Modeling means maintaining only those models
that offer long-term value as software engineering progresses, discarding the
rest. Each retained work product must be actively maintained through changes,
which can potentially slow down the team. Ambler emphasizes that every
decision to retain a model involves a trade-off between agility and the
convenience of having information available in an abstract form for the team.
Focus on content over representation: The primary goal of modeling is to
convey useful information to its intended audience. A model that is syntactically
perfect but lacks valuable content is less valuable than a model with imperfect
notation that effectively communicates important information.
Understand models and tools: It is essential to be familiar with the strengths and
weaknesses of each model and the tools used to create them. This knowledge
allows for informed decisions on which models and tools best suit the project's
needs.
Adapt locally: Customize the modeling approach to fit the specific needs and
dynamics of the agile team.

Agile Unified Process (AUP)

 Agile Unified Process (AUP) adopts a "serial in the large" and "iterative in the
small" philosophy.
 It integrates classic Unified Process (UP) phases: inception, elaboration,
construction, and transition.
 AUP provides a sequential overlay to visualize the overall process flow of a
software project.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 21

 Within each phase, AUP emphasizes iteration to enhance agility.

 Each iteration in AUP focuses on completing meaningful software increments
rapidly for end users.
Modeling: UML diagrams are developed to represent the business and problem
domains.
Implementation: Models are transformed into source code.
Testing: Similar to XP, a series of tests are designed and executed to detect
errors and validate that the source code fulfils its requirements.
Deployment: This process focuses on delivering a software increment and
gathering feedback from end users.
Configuration and project management: In AUP, configuration management
includes change management, risk management, and control of persistent work
products.
Environment management: Environment management in Agile Unified Process
(AUP) oversees the coordination of a process infrastructure encompassing
standards, tools, and other supportive technologies accessible to the team.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 22

Chapter 4
PRINCIPLES THAT GUIDE THE PRACTICE

Practice refers to a set of ideas, principles, techniques, and instruments that a

software engineer utilizes regularly. It enables managers to oversee software
projects and empowers engineers to develop computer programs effectively.
Practice fills a software process model with essential guidelines, both technical
and managerial, needed to accomplish tasks successfully.

4.1 SOFTWARE ENGINEERING KNOWLEDGE

 In an editorial published in IEEE Software a decade ago, Steve McConnell
emphasized the importance of software engineering knowledge beyond
specific technologies.
 McConnell noted that while knowledge of technologies like Java, Perl, HTML,
etc., is crucial for programming, it tends to become outdated every three
years.
 He introduced the concept of "software engineering principles" which, unlike
technology-specific knowledge, remain relevant throughout a programmer's
career.
 McConnell argued that by the year 2000, software engineering had
developed a "stable core" comprising about 75% of the knowledge necessary
for developing complex systems.
 This stable core primarily consists of fundamental principles that guide
software engineers and form the basis for applying and evaluating software
engineering models, methods, and tools.

4.2 CORE PRINCIPLES

Software engineering is driven by a set of fundamental principles that facilitate
the implementation of a structured software process and the adoption of
efficient software engineering methodologies. These core principles provide a
philosophical basis at the process level, guiding software teams through
framework activities, overarching process flows, and the creation of essential
software engineering deliverables.
At the practical level, core principles establish a set of fundamental values and
guidelines that direct activities such as problem analysis, solution design,
MRS. DEEKSHA DEPARTMENT OF CS&E
 SE&PM (21CS61) Lecture Notes 23

implementation, testing, and software deployment within the user community.

Identified are a set of overarching principles that apply across software
engineering processes and practices:
1. Deliver value to end users.
2. Prioritize simplicity.
3. Maintain alignment with the project and product vision.
4. Ensure clarity and understanding for stakeholders.
5. Remain adaptable to future needs.
6. Strategically plan for reusability.
7. Foster critical thinking.
While these general principles are crucial, their high level of abstraction
sometimes poses challenges in translating them into day-to-day software
engineering operations.

4.2.1 Principles That Guide Process

The following set of core principles can be applied to the framework, and by
extension, to every software process.
Principle 1: Be agile.
Whether the process model you choose is prescriptive or agile.
1. Keep your technical approach as simple as possible
2. Keep the work products you produce as concise(short) as possible
3. Make decisions locally whenever possible.
Principle 2. Focus on quality at every step.
For every process activity, action, and task should focus on the quality of the
work product that has been produced.
Principle 3. Be ready to adapt.
Adapt your approach to conditions imposed by the problem, the people, and the
project itself.
Principle 4. Build an effective team.
Build a self-organizing team that has mutual trust and respect.
Principle 5. Establish mechanisms for communication and coordination.
Projects fail because stakeholders fail to coordinate their efforts to create a
successful end product.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 24

Principle 6. Manage change.

The methods must be established to manage the way changes are requested,
approved, and implemented.
Principle 7. Assess risk.
Lots of things can go wrong as software is being developed.
Principle 8. Create work products that provide value for others.
Create only those work products that provide value for other process activities,
actions and tasks.

4.2.2 Principles That Guide Practice

Software engineering practice has a single goal i.e.., to deliver on-time, high
quality, operational software that contains functions and features that meet the
needs of all stakeholders. To achieve this goal, should adopt a set of core
principles that guide the technical work.
The following set of core principles are fundamental to the practice of software
engineering:
Principle 1. Divide and conquer.
A large problem is easier to solve if it is subdivided into a collection of elements
(or modules or components). Ideally, each element delivers distinct functionality
that can be developed.
Principle 2. Understand the use of abstraction.
At its core, an abstraction (overview) is a simplification of some complex
element of a system used to communicate meaning in a single phrase.
Principle 3. Strive for consistency.
Whether it’s creating a requirements model, developing a software design,
generating source code, or creating test cases. All these are consistent so that
the software is easier to develop.
Principle 4. Focus on the transfer of information.
Software is about information transfer—from a database to an end user, from
an operating system to an application.
Principle 5. Build software that exhibits effective modularity.
Modularity provides a mechanism for any complex system can be divided into
modules (components).

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 25

Principle 6. Look for patterns.

Brad Appleton suggests that: The goal of patterns within the software
community is to create a body of literature to help software developers resolve
recurring problems encountered throughout all of software development
process.
Principle 7. When possible, represent the problem and its solution from a
number of different perspectives.
When a problem and its solution are examined from a number of different
perspectives (ways).
Principle 8. Remember that someone will maintain the software.
Software will be corrected as defects are remove, adapted as its environment
changes, and enhanced as stakeholders request more capabilities.

4.3 PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY

4.3.1 Communication Principles

Before customer requirements can be analysed, modelled, or specified, they
must first be gathered through communication activities. When a customer
presents a problem that could potentially be solved with a computer-based
solution, you respond to their request for assistance, initiating the
communication process. However, progressing from initial communication to
mutual understanding often encounters difficulties.

Effective communication—whether among technical peers, with customers and

other stakeholders, or with project managers—is one of the most challenging
aspects you will encounter. In this context, I explore communication principles
specifically relevant to interactions with customers. Nonetheless, many of these
principles are equally applicable to all forms of communication within a software
project.
Principle 1. Listen.
Try to focus on the speaker’s words, rather than formulating your response to
those words. Ask for clarification if something is unclear, but avoid constant
interruptions. Never become contentious in your words or actions (e.g., rolling
your eyes or shaking your head) as a person is talking.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 26

Principle 2. Prepare before you communicate.

Spend the time to understand the problem before you meet with others. If
necessary, do some research to understand business domain jargon. If you have
responsibility for conducting a meeting, prepare an agenda in advance of the
meeting.
Principle 3. Someone should facilitate the activity.
Every communication meeting should have a leader (a facilitator) to keep the
conversation moving in a productive direction, to mediate any conflict that does
occur, and to ensure than other principles are followed.
Principle 4. Face-to-face communication is best.
But it usually works better when some other representation of the relevant
information is present. For example, a participant may create a drawing or a
“strawman” document that serves as a focus for discussion.
Principle 5. Take notes and document decisions.
Things have a way of falling into the cracks. Someone participating in the
communication should serve as a “recorder” and write down all important
points and decisions.
Principle 6. Strive for collaboration.
Collaboration and consensus occur when the collective knowledge of members
of the team is used to describe product or system functions or features. Each
small collaboration serves to build trust among team members and creates a
common goal for the team.
Principle 7. Stay focused; modularize your discussion.
The more people involved in any communication, the more likely that discussion
will bounce from one topic to the next. The facilitator should keep the
conversation modular, leaving one topic only after it has been resolved
Principle 8. If something is unclear, draw a picture.
Verbal communication goes only so far. A sketch or drawing can often provide
clarity when words fail to do the job.
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.
Communication, like any software engineering activity, takes time. Rather than
iterating endlessly, the people who participate should recognize that many

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 27

topics require discussion (see Principle 2) and that “moving on” is sometimes
the best way to achieve communication agility.
Principle 10. Negotiation is not a contest or a game.
It works best when both parties win. There are many instances in which you and
other stakeholders must negotiate functions and features, priorities, and
delivery dates. If the team has collaborated well, all parties have a common goal.
Still, negotiation will demand compromise from all parties.

4.3.2 Planning Principles

The communication activity helps define goals and objectives, though these may
evolve over time. Understanding these is different from planning, which involves
management and technical practices to create a roadmap.

Difference between Customers and End Users:

Customers: Initiate the software request, define business objectives and basic
requirements, and coordinate funding.
End Users: Use the software to achieve business goals and provide operational
details.

Effective communication with customers and end users is crucial in software

engineering, influencing subsequent technical work.

Planning approaches in software development vary—some advocate

minimalism due to unpredictability, others favour detailed plans for clarity, and
agile methods adapt plans based on evolving project insights ("real work").
Balancing planning is crucial to provide useful team guidance without
unnecessary detail.

Principle 1. Understand the scope of the project.

It’s impossible to use a road map if you don’t know where you’re going. Scope
provides the software team with a destination.
Principle 2. Involve stakeholders in the planning activity.
Stakeholders define priorities and establish project constraints. To
accommodate these realities, software engineers must often negotiate order of
delivery, time lines, and other project-related issues.
Principle 3. Recognize that planning is iterative.
A project plan is never engraved in stone. As work begins, it is very likely that
things will change. As a consequence, the plan must be adjusted to

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 28

accommodate these changes. In addition, iterative, incremental process models

dictate re-planning after the delivery of each software increment based on
feedback received from users.
Principle 4. Estimate based on what you know.
The intent of estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work to be done. If
information is vague or unreliable, estimates will be equally unreliable.
Principle 5. Consider risk as you define the plan.
If you have identified risks that have high impact and high probability,
contingency planning is necessary. In addition, the project plan (including the
schedule) should be adjusted to accommodate the likelihood that one or more
of these risks will occur.
Principle 6. Be realistic.
People don’t work 100 percent of every day. Noise always enters into any human
communication. Omissions and ambiguity are facts of life. Change will occur.
Even the best software engineers make mistakes. These and other realities
should be considered as a project plan is established.
Principle 7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a project plan is
developed. A “high-granularity” plan provides significant work task detail that is
planned over relatively short time increments (so that tracking and control occur
frequently). A “low-granularity” plan provides broader work tasks that are
planned over longer time periods. In general, granularity moves from high to low
as the project time line moves away from the current date. Over the next few
weeks or months, the project can be planned in significant detail.
Activities that won’t occur for many months do not require high granularity (too
much can change).
Principle 8. Define how you intend to ensure quality.
The plan should identify how the software team intends to ensure quality. If
technical reviews3 are to be conducted, they should be scheduled. If pair
programming is to be used during construction, it should be explicitly defined
within the plan.
Principle 9. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change. You should
identify how changes are to be accommodated as software engineering work
proceeds. For example, can the customer request a change at any time? If a
change is requested, is the team obliged to implement it immediately? How is
the impact and cost of the change assessed?

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 29

Principle 10. Track the plan frequently and make adjustments as required.
Software projects fall behind schedule one day at a time. Therefore, it makes
sense to track progress on a daily basis, looking for problem areas and situations
in which scheduled work does not conform to actual work conducted. When
slippage is encountered, the plan is adjusted accordingly.

4.3.3 Modelling Principles

Principle 1. The primary goal of the software team is to build software, not
create models.
Agility means getting software to the customer in the fastest possible time.
Models that make this happen are worth creating, but models that slow the
process down or provide little new insight should be avoided.
Principle 2. Travel light—don’t create more models than you need. Every model
that is created must be kept up-to-date as changes occur. More importantly,
every new model takes time that might otherwise be spent on construction
(coding and testing). Therefore, create only those models that make it easier
and faster to construct the software.
Principle 3. Strive to produce the simplest model that will describe the
problem or the software.
Don’t overbuild the software. By keeping models simple, the resultant software
will also be simple. The result is software that is easier to integrate, easier to
test, and easier to maintain (to change). In addition, simple models are easier
for members of the software team to understand and critique, resulting in an
ongoing form of feedback that optimizes the end result.
Principle 4. Build models in a way that makes them amenable to change.
Assume that your models will change, but in making this assumption don’t get
sloppy. For example, since requirements will change, there is a tendency to give
requirements models short shrift. Why? Because you know that they’ll change
anyway. The problem with this attitude is that without a reasonably complete
requirements model, you’ll create a design (design model) that will invariably
miss important functions and features.
Principle 5. Be able to state an explicit purpose for each model that is created.
Every time you create a model, ask yourself why you’re doing so. If you can’t
provide solid justification for the existence of the model, don’t spend time on it.
Principle 6. Adapt the models you develop to the system at hand.
It may be necessary to adapt model notation or rules to the application; for
example, a video game application might require a different modelling
technique than real-time, embedded software that controls an automobile
engine.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 30

Principle 7. Try to build useful models, but forget about building perfect
models. When building requirements and design models, a software engineer
reaches a point of diminishing returns. That is, the effort required to make the
model absolutely complete and internally consistent is not worth the benefits of
these properties. Am I suggesting that modelling should be sloppy or low
quality? The answer is “no.” But modelling should be conducted with an eye to
the next software engineering steps. Iterating endlessly to make a model
“perfect” does not serve the need for agility.
Principle 8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation is secondary although
everyone on a software team should try to use consistent notation during
modelling, the most important characteristic of the model is to communicate
information that enables the next software engineering task. If a model does
this successfully, incorrect syntax can be forgiven.
Principle 9. If your instincts tell you a model isn’t right even though it seems
okay on paper, you probably have reason to be concerned. If you are an
experienced software engineer, trust your instincts.
Software work teaches many lessons—some of them on a subconscious level. If
something tells you that a design model is doomed to fail (even though you can’t
prove it explicitly), you have reason to spend additional time examining the
model or developing a different one.
Principle 10. Get feedback as soon as you can.
Every model should be reviewed by members of the software team. The intent
of these reviews is to provide feedback that can be used to correct modelling
mistakes, change misinterpretations, and add features or functions that were
inadvertently omitted.

Requirements modelling principles

Principle 1. The information domain of a problem must be represented and

understood.
The information domain encompasses the data that flow into the system (from
end users, other systems, or external devices), the data that flow out of the
system (via the user interface, network interfaces, reports, graphics, and other
means), and the data stores that collect and organize persistent data objects
(i.e., data that are maintained permanently).
Principle 2. The functions that the software performs must be defined.
Software functions provide direct benefit to end users and also provide internal
support for those features that are user visible. Some functions transform data
that flow into the system. In other cases, functions effect some level of control

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 31

over internal software processing or external system elements. Functions can

be described at many different levels of abstraction, ranging from a general
statement of purpose to a detailed description of the processing elements that
must be invoked.
Principle 3. The behavior of the software (as a consequence of external events)
must be represented. The behavior of computer software is driven by its
interaction with the external environment. Input provided by end users, control
data provided by an external system, or monitoring data collected over a
network all cause the software to behave in a specific way.
Principle 4. The models that depict information, function, and behavior must
be partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion. Requirements modelling is the first step in software engineering
problem solving. It allows you to better understand the problem and establishes
a basis for the solution (design). Complex problems are difficult to solve in their
entirety. For this reason, you should use a divide-and-conquer strategy. A large,
complex problem is divided into sub problems until each sub problem is
relatively easy to understand. This concept is called partitioning or separation of
concerns, and it is a key strategy in requirements modelling.
Principle 5. The analysis task should move from essential information toward
implementation detail. Requirements modelling begins by describing the
problem from the end-user’s perspective. The “essence” of the problem is
described without any consideration of how a solution will be implemented. For
example, a video game requires that the player “instruct” its protagonist on
what direction to proceed as she moves into a dangerous maze. That is the
essence of the problem. Implementation detail (normally described as part of
the design model) indicates how the essence will be implemented. For the video
game, voice input might be used. Alternatively,

Design Modelling Principles

Principle 1. Design should be traceable to the requirements model.

The requirements model describes the information domain of the problem,
user-visible functions, system behavior, and a set of requirements classes that
package business objects with the methods that service them. The design model
translates this information into an architecture, a set of subsystems that
implement major functions, and a set of components that are the realization of
requirements classes. The elements of the design model should be traceable to
the requirements model.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 32

Principle 2. Always consider the architecture of the system to be built.

Software architecture is the skeleton of the system to be built. It affects
interfaces, data structures, program control flow and behavior, the manner in
which testing can be conducted, the maintainability of the resultant system, and
much more. For all of these reasons, design should start with architectural
considerations. Only after the architecture has been established should
component-level issues be considered.
Principle 3. Design of data is as important as design of processing functions.
Data design is an essential element of architectural design. The manner in which
data objects are realized within the design cannot be left to chance. A well-
structured data design helps to simplify program flow, makes the design and
implementation of software components easier, and makes overall processing
more efficient.
Principle 4. Interfaces (both internal and external) must be designed with care.
The manner in which data flows between the components of a system has much
to do with processing efficiency, error propagation, and design simplicity. A well-
designed interface makes integration easier and assists the tester in validating
component functions.
Principle 5. User interface design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use. The user interface is the
visible manifestation of the software. No matter how sophisticated its internal
functions, no matter how comprehensive its data structures, no matter how well
designed its architecture, a poor interface design often leads to the perception
that the software is “bad.”
Principle 6. Component-level design should be functionally independent.
Functional independence is a measure of the “single-mindedness” of a software
component. The functionality that is delivered by a component should be
cohesive—that is, it should focus on one and only one function or sub function.

Construction Principles
The construction activity encompasses a set of coding and testing tasks that lead
to operational software that is ready for delivery to the customer or end user.
Coding may be
(1) The direct creation of programming language source code (e.g., Java),
(2) The automatic generation of source code using an Intermediate design like
representation of the component to be built.
The initial focus of testing is at the component level, often called unit testing.
Other levels of testing include
i) Integration testing (conducted as the system is constructed).

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 33

ii) Validation testing that assesses whether requirements have been met for the
complete system (or software increment)
(iii) Acceptance testing that is conducted by the customer in an effort to exercise
all required features and functions.
The following set of fundamental principles and concepts are applicable to
coding and testing:

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.

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.

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.
• Refactor the code

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 34

Testing Principles: 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.

Davis suggests a set of testing principles that have been adapted for use.

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

objective of software testing is to uncover errors. It follows that the most severe
defects (from the customer’s point of view) are those that cause the program to
fail to meet its requirements.

Principle 2. Tests should be planned long before testing begins. Test planning
can begin as soon as the requirements model is complete. Detailed definition of
test cases can begin as soon as the design model has been solidified. Therefore,
all tests can be planned and designed before any code has been generated.

Principle 3. The Pareto principle applies to software testing. In this context the
Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components. The problem,
of course, is to isolate these suspect components and to thoroughly test them.

Principle 4. Testing should begin “in the small” and progress toward testing “in
the large.” The first tests planned and executed generally focus on individual
components. As testing progresses, focus shifts in an attempt to find errors in
integrated clusters of components and ultimately in the entire system.

Principle 5. Exhaustive testing is not possible. The number of path permutations

for even a moderately sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing. It is possible,
however, to adequately cover program logic and to ensure that all conditions in
the component-level design have been exercised.

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 35

Deployment Principles

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

often, the customer expects more than the team has promised to deliver, and
disappointment occurs immediately. This results in feedback that is not
productive and ruins team morale. In her book on managing expectations,
Naomi Karten states: “The starting point for managing expectations is to
become more conscientious about what you communicate and how.” She
suggests that a software engineer must be careful about sending the customer
conflicting messages (e.g., promising more than you can reasonably deliver in
the time frame provided or delivering more than you promise for one software
increment and then less than promised for the next).

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

ROM or other media (including Web-based downloads) containing all
executable software, support data files, support documents, and other relevant
information should be assembled and thoroughly beta-tested with actual users.
All installation scripts and other operational features should be thoroughly
exercised in as many different computing configurations (i.e., hardware,
operating systems, and peripheral devices, networking arrangements) as
possible.

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

delivered. An end user expects responsiveness and accurate information when
a question or problem arises. If support is ad hoc, or worse, non-existent, the
customer will become dissatisfied immediately. Support should be planned,
support materials should be prepared, and appropriate recordkeeping
mechanisms should be established so that the software team can conduct a
categorical assessment of the kinds of support requested.

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

The software team delivers more than the software itself. Appropriate training
aids (if required) should be developed; troubleshooting guidelines should be
provided, and when necessary, a “what’s different about this software
increment” description should be published.

Principle 5. Buggy software should be fixed first, delivered later. Under time
pressure, some software organizations deliver low-quality increments with a
warning to the customer those bugs “will be fixed in the next release.” This is a
mistake. There’s a saying in the software business: “Customers will forget you

MRS. DEEKSHA DEPARTMENT OF CS&E

 SE&PM (21CS61) Lecture Notes 36

delivered a high-quality product a few days late, but they will never forget the
problems that a low-quality product caused them. The software reminds them
every day.”

MRS. DEEKSHA DEPARTMENT OF CS&E