Module 3

Chapter 1- Agile Development

Chapter 2- Principles that guide practice: Software

Engineering Knowledge
 Contents
Chapter 1: Agile Development: What is Agility?, Agility and the cost of

change. What is an agile Process?, Extreme Programming (XP), Other Agile

Process Models, A tool set for Agile process.

Chapter 2: Principles that guide practice: Software Engineering Knowledge,

Core principles, Principles that guide each framework activity

 Module 3

Chapter 1- Agile Development

 Manifesto for Agile Software Development
In 2001, Kent Beck and 16 others -- “Agile Alliance” signed the “Manifesto for Agile
Software Development.” It stated: We are uncovering better ways of developing software
by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
 Agility
Traditional Software Development

In Traditional Software Development process(such as waterfall model, V

model, etc..), less communication is there between Customers and client during
Requirements process before Analysis and design process.

• It Takes more than estimated time and estimated budget.

• It has Low Flexibility; Changes are difficult and costly to implement once a
 Agility

Traditional Software Development

While both Traditional Software models and Agile involve iterative and

collaborative processes, Agile's core principles of flexibility, continuous

delivery, and customer involvement set it apart from more rigid and structured

traditional models.
 Agility
• What is it? Agile software engineering combines a philosophy and a set of
development guidelines.

• The philosophy encourages customer satisfaction, early incremental delivery of

software, small & highly motivated project teams, informal methods, minimal
work products, and overall development simplicity.

• The development guidelines stress delivery over analysis & design, active and
 Agility
• Who does it? Software engineers and stakeholders, including managers,
customers, and end users, collaborate on a self-organizing agile team. This team
nurtures communication and collaboration among all members.

• Why is it important? Agile software engineering is suitable for fast-paced,

ever-changing business environments, offering an alternative(agile) to
conventional methods(traditional) for certain software projects. It has proven to
deliver successful systems quickly.
 Agility
• What are the steps? Agile development involves communication, planning,
modeling, construction, and deployment, But they morph into a minimal
task set that pushes the project team toward construction and delivery. This
approach may sometimes prioritize speed over detailed analysis and design.

• What is the work product? The main work product in agile development is
an operational "software increment" delivered to the customer on the agreed
date. Both customers and engineers view this increment as the most important
output.
 Agility
• How do I ensure that I’ve done it right? – If the agile team agrees that the
process works and the delivered software increments satisfy the customer.
Consistent delivery of satisfactory software indicates a successful agile
process.
 Agility And The Cost Of Change
• Conventional wisdom in software development indicates that the cost of change increases
nonlinearly as a project progresses.

• Early changes during requirements gathering are minimal in cost and time. A usage scenario might
have to be modified, a list of functions may be extended, or a written specification can be edited. The
costs of doing this work are minimal, and the time required will not adversely affect the outcome of the
project.

• Late changes during validation testing can be costly and time-consuming, requiring extensive
modifications. The team is in the middle of validation testing, and an important stakeholder is
requesting a major functional change. The change requires a modification to the architectural design of
the software, the design and construction of three new components, modifications to another five
components, the design of new tests, and so on. Costs escalate quickly, and the time and cost required
 Agility And The Cost Of Change

• Agile proponents argue that a well-designed agile process flattens the cost of
change curve, allowing late changes with less impact.

• Agile practices like incremental delivery, continuous unit testing, and pair
programming help reduce these costs.

• Evidence suggests that significant cost reduction can be achieved through agile
methods.
Agility And The Cost Of Change
 What Is An Agile Process?
An agile software process is based on key assumptions:

• It's hard to predict which software requirements will stay the same and which
will change, as well as how customer priorities will shift.

• Design and construction are often interleaved, needing to be performed together

to prove the design as it's created.

• Analysis, design, construction, and testing are less predictable than desired.
 What Is An Agile Process?
• Given these assumptions, the process must be adaptable to handle
unpredictability.

• Adaptability should be incremental, requiring regular customer feedback through

operational prototypes or system portions. Incremental development allows for
regular evaluation, feedback, and necessary adaptations to accommodate
changes.
 Agility Principles?
The Agile Alliance defines 12 agility principles for those who want to achieve
agility:

1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes

harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.
 Agility Principles?
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.

 Agility Principles?
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.
 The Politics of Agile Development
•Ongoing Debate: There is continuous debate about the benefits of agile versus
traditional software development methods.

•Extreme Views: Agilists see traditionalists as overly focused on producing flawless

documentation instead of working systems.
•Traditionalists view agilists as unprepared for scaling projects to enterprise levels.

•Risk of Ideological Battles: when debates turn into conceptual battles, rational
decision-making can get overshadowed, becoming counterproductive.
 The Politics of Agile Development
•Key Questions:
•How to best achieve agility in software development?
•How to build software that meets current customer needs and is scalable for
future requirements?

•No Absolute Answers: There are no definitive solutions, and even within the
agile community, multiple process models exist, each with a different approach
to agility.
 The Politics of Agile Development

•Ideas vs. Tasks: Agile methodologies often propose "ideas" rather than specific

"work tasks," marking a departure from traditional methods.

•Adaptation of Good Practices: Many agile concepts are adaptations of good

software engineering practices.

•Balanced Approach: The best results come from combining the strengths of both

agile and traditional methods, rather than dismissing either.

 Human Factors
Proponents of agile software development highlight the importance of "people factors.“

As Cockburn and Highsmith state, "Agile development focuses on the talents and skills
of individuals, molding the process to specific people and teams." The process adapts to
the team, not the other way around.

Key characters(traits) for agile teams include:

•Competence: Encompasses essential talent, specific software skills, and knowledge

of the process, which can be taught to all team members.
 Human Factors
•Common Focus: Team members should be focused on delivering a working software
increment within the promised time, continually adapting the process to fit team needs.

•Collaboration: Team members must collaborate with each other and all stakeholders
to assess, analyze, and use information, and to build software that provides business value.

•Decision-Making Ability: The team must have the autonomy to make technical and
project decisions.
 Human Factors
•Fuzzy Problem-Solving Ability: Agile teams must handle ambiguity and adapt to changing problems,
learning from all problem-solving activities.

Mutual Trust and Respect: Teams must be "jelled," exhibiting trust and respect to become greater than the
sum of their parts. A jelled team exhibits the trust and respect that are necessary to make them “so strongly knit
that the whole is greater than the sum of the parts.”

Self-Organization: In the context of agile development, self-organization implies three things:

(1) the agile team organizes itself for the work to be done,
(2) the team organizes the process to best accommodate its local environment,
(3) the team organizes the work schedule to best achieve delivery of the software increment.
Teams organize their work, process, and schedules to best achieve delivery of the software increment,
boosting collaboration and morale.
 Extreme Programming (XP)
Extreme Programming (XP) is a flexible and collaborative approach to software
development that focuses on delivering quality software quickly. It involves
close teamwork, frequent feedback, and simple design, aiming to meet changing
requirements efficiently.

Extreme Programming (XP), the most widely used agile approach. Originally
developed by Kent Beck, XP emphasizes five core values: communication,
simplicity, feedback, courage, and respect.
 Extreme Programming (XP) Values
XP values: five values that establish a foundation for all work performed as part of XP.
1) Communication - XP emphasizes close, yet informal (verbal) collaboration between customers and
developers. Everyone on a team works jointly at every stage of the project.
2) Simplicity - XP restricts developers to design only for immediate needs, rather than consider future needs.
Developers strive to write simple code bringing more value to a product, as it saves time and effort.
3) Feedback - Feedback is derived from three sources: the implemented software itself, the customer, and
other software team members. XP makes use of the unit test as its primary testing tactic. As each class is
developed, the team develops a unit test to exercise each operation according to its specified functionality. As
an increment is delivered to a customer, the user stories or use cases that are implemented by the increment are
used as a basis for acceptance tests. The degree to which the software implements the output, function, and
behavior of the use case is a form of feedback. Finally, as new requirements are derived as part of iterative
planning, the team provides the customer with rapid feedback regarding cost and schedule impact.
 Extreme Programming (XP) Values
4) Courage - Programmers objectively evaluate their own results without making excuses
and are always ready to respond to changes. An agile XP team must have the discipline
(courage) to design for today, recognizing that future requirements may change dramatically,
thereby demanding substantial rework of the design and implemented code.

5) Respect - Every person assigned to a project contributes to a common goal. The agile team
inculcates respect among its members, between other stakeholders and team members, and
indirectly, for the software itself. As they achieve successful delivery of software increments, the
team develops growing respect for the XP process.
 Extreme Programming (XP) Process
XP process:
• Extreme Programming uses an object-oriented approach as its preferred development
paradigm and encompasses a set of rules and practices that occur within the context of
four framework activities: planning, design, coding, and testing.

• Extreme Programming (XP) is an agile software development methodology that

emphasizes frequent releases, continuous testing, and close collaboration between
developers and customers.

• It involves practices such as pair programming, test-driven development, and

continuous integration to deliver high-quality software efficiently.
Extreme Programming (XP)
(pilot
study)
 The XP process and roles of extreme programming
Framework activities for XP:
Planning - The planning activity (also called the planning game) begins with listening—a requirements
gathering activity that enables the technical members of the XP team to understand the business context for the
software and to get a broad feel for required output and major features and functionality.

Listening leads to the creation of a set of “user stories” that describe required output, features, and
functionality for software to be built.

Each story (similar to use cases) is written by the customer and is placed on an index card. The customer
assigns a value (i.e., a priority) to the story based on the overall business value of the feature or function.

Members of the XP team then assess each story and assign a cost—measured in development weeks—to it. If
the story is estimated to require more than three development weeks, the customer is asked to split the story
into smaller stories and the assignment of value and cost occurs again. It is important to note that new stories
can be written at any time.
 The XP process
Framework activities for XP:
and roles of extreme programming
Planning
Customers and developers work together to decide how to group stories into the next release (the next
software increment) to be developed by the XP team.

Once a basic commitment (agreement on stories to be included, delivery date, and other project matters) is
made for a release, the XP team orders the stories that will be developed in one of three ways:
(1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule and implemented first, or
(3) the riskiest stories will be moved up in the schedule and implemented first.

After the first project release (also called a software increment) has been delivered, the XP team computes
project velocity – the number of customer stories implemented during the first release.

Project velocity can then be used to (1) help estimate delivery dates and schedule for subsequent releases and
(2) determine whether an overcommitment has been made for all stories across the entire development project.
If an overcommitment occurs, the content of releases is modified or end delivery dates are changed.

As development work proceeds, the customer can add stories, change the value of an existing story, split
stories, or eliminate them. The XP team then reconsiders all remaining releases and modifies its plans
accordingly.
 The XP process and roles of extreme programming
Framework activities for XP:

Design
XP design rigorously follows the KIS (keep it simple) principle. A simple design is always preferred over a
more complex representation.

In addition, the design provides implementation guidance for a story as it is written—nothing less, nothing
more.

The design of extra functionality is discouraged.

XP encourages the use of CRC (class-responsibility-collaborator) cards -- object-oriented s/w development.

The CRC cards are the only design work product produced as part of the XP process.
 The XP process and roles of extreme programming
Framework activities for XP:
Design
If a difficult design problem is encountered as part of the design of a story, XP recommends the immediate
creation of spike solution - an operational prototype of that portion to be implemented and evaluated. The
intent is to lower risk when true implementation starts and to validate the original estimates for the story
containing the design problem.

XP encourages refactoring—a construction technique that is also a method for design optimization.

Refactoring is the process of changing a software system in such a way that it does not alter the external
behavior of the code yet improves the internal structure.

A central notion in XP is that design occurs both before and after coding commences.

Refactoring means that design occurs continuously as the system is constructed.

 The XP process and roles of extreme programming
Framework activities for XP:
Coding
After stories are developed and preliminary design work is done, the team does not move to code, but rather
develops a series of unit tests that will exercise each of the stories that is to be included in the current release
(software increment).

Once the unit test has been created, the developer is better able to focus on what must be implemented to pass
the test.

Nothing extraneous is added (KIS). Once the code is complete, it can be unit-tested immediately, thereby
providing instantaneous feedback to the developers.

A key concept during the coding activity is pair programming – two people work together at one computer
workstation to create code for a story. This provides a mechanism for real time problem solving and real-time
quality assurance (the code is reviewed as it is created). It also keeps the developers focused on the problem at
hand. In practice, each person takes on a slightly different role. For example, one person might think about the
coding details of a particular portion of the design while the other ensures that coding standards (a required part
of XP) are being followed or that the code for the story will satisfy the unit test that has been developed to
validate the code against the story.
 The XP process and roles of extreme programming
Framework activities for XP:
Coding
As pair programmers complete their work, the code they develop is integrated with the work of others. In some
cases, this is performed on a daily basis by an integration team. In other cases, the pair programmers have
integration responsibility. This “continuous integration” strategy helps to avoid compatibility and interfacing
problems and provides a “smoke testing” environment that helps to uncover errors early.

Testing is the core of extreme programming. It is the regular activity that involves both unit tests (
automated testing to determine if the developed feature works properly) and acceptance tests (customer testing
to verify that the overall system is created according to the initial requirements).
 Extreme Programming (XP)
Industrial XP (IXP): Joshua Kerievsky describes Industrial Extreme Programming (IXP) as an organic
evolution of XP, maintaining its minimalist, customer-centric, test-driven nature. IXP differs by
involving management more, expanding customer roles, and upgrading technical practices.

IXP introduces six new practices to ensure success in large organizational projects:
1) Readiness Assessment: Before starting an IXP project, the organization must conduct a readiness
assessment to ascertain whether:
a) an appropriate development environment exists to support IXP,
b) the team will be populated by the proper set of stakeholders,
c) the organization has a distinct quality program and supports continuous improvement,
d) the organizational culture will support the new values of an agile team, and
e) the broader project community will be populated appropriately.
 Extreme Programming (XP)
2) Project Community: Unlike classic XP, IXP involves a broader community, including
technologists, customers, and other stakeholders like legal staff and quality auditors. Their roles and
communication mechanisms should be clearly defined. People on the team must be well-trained,
adaptable and skilled, and have the proper temperament to contribute to a self-organizing team. For
important projects, “team”  morphs into a community.

3) Project Chartering: The IXP team assesses the project’s business justification and its alignment
with the organization's goals, ensuring it complements or replaces existing systems or processes
appropriately.

4) Test-Driven Management: This involves setting measurable criteria for project progress and
establishing mechanisms to determine if these criteria are met. Test-driven management establishes a
series of measurable “destinations” and then defines mechanisms for determining whether or not these
destinations have been reached.

5) Retrospectives: After delivering a software increment, the IXP team conducts specialized reviews
called Retrospectives to examine “issues, events, and lessons learned”, aiming to improve the IXP
process.
 Extreme Programming (Xp)
Industrial XP (IXP):
6) Continuous Learning: Team members are encouraged and possibly incentivized to learn new
methods and techniques to enhance product quality.

In addition, IXP modifies a number of existing XP practices.

Story-driven development (SDD) insists that stories for acceptance tests be written before a single line
of code is generated.
Domain-driven design (DDD) is an improvement on the “system metaphor” concept used in XP. DDD
suggests the evolutionary creation of a domain model that “accurately represents how domain experts
think about their subject”
Pairing extends the XP pair programming concept to include managers and other stakeholders. The
intent is to improve knowledge sharing among XP team members who may not be directly involved in
technical development.
Iterative usability discourages front-loaded interface design in favor of usability design that evolves as
software increments are delivered.
 Extreme Programming (Xp)
The XP debate focuses on whether Extreme Programming (XP) practices are effective or
problematic. Critics cite issues such as requirements volatility, conflicting customer needs,
informal requirement expression, and lack of formal design in XP. Proponents argue that XP
evolves to address these concerns, emphasizing its adaptability and iterative approach.
Success with XP depends on recognizing weaknesses and adapting it to an organization's
specific needs.
 Other Agile Process Models
The history of software engineering is full of outdated methodologies and tools, with each new
approach eventually being overshadowed by the next big thing. The rise of agile methods,
including Extreme Programming (XP), is no exception. While XP is widely used, many other
agile process models have been proposed and are in use across 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)
 Other Agile Process Models
Adaptive Software Development (ASD):
• Jim Highsmith proposed Adaptive Software Development (ASD) for building complex
software and systems, stressing human collaboration and team self-organization.

• The ASD life cycle has three phases: speculation, collaboration, and learning.

Speculation - the project is initiated and adaptive cycle planning is conducted. Adaptive cycle
planning uses project initiation information—the customer’s mission statement, project
constraints (e.g., delivery dates or user descriptions), and basic requirements—to define the set
of release cycles (software increments) that will be required for the project.
 Other Agile Process Models
Adaptive Software Development (ASD)

- Joint Application Development

 Other Agile Process Models
Adaptive Software Development (ASD):
Collaboration - Motivated people use collaboration in a way that multiplies their talent and creative output
beyond their absolute numbers.
It encompasses communication and teamwork, but it also emphasizes individualism, because individual
creativity plays an important role in collaborative thinking.
It is, above all, a matter of trust. People working together must trust one another to:
(1) criticize without animosity, (2) assist without resentment, (3) work as hard as or harder than they do, (4)
have the skill set to contribute to the work at hand, and (5) communicate problems or concerns in a way that
leads to effective action.

Learning As ASD teams develop components, they focus equally on learning and progress. Developers often
misjudge their understanding, and learning improves it. ASD teams learn through focus groups, technical
reviews, and project.
 Other Agile Process Models
Scrum: Scrum is an agile software development method created by Jeff Sutherland and his
team in the early 1990s.
It follows agile principles and includes these key activities: requirements, analysis, design,
evolution, and delivery. Each activity is divided into "sprints," which are short, adaptable
work periods. Work tasks occur within a process pattern called a sprint.

Each of the process patterns defines a set of development actions:

1. Backlog: A prioritized list of project requirements or features that provide business value.
2. Sprints: Work units required to achieve backlog requirements, typically within a 30-day
period, during which no changes are introduced.
 Other Agile Process Models
Scrum:
3. Scrum meetings: Daily 15-minute meetings where team members answer three
questions: What did you do since the last meeting?
What obstacles are you encountering?
What will you do by the next meeting?
A team leader - Scrum master - leads the meeting & assesses the responses from each person

4. Demos: Deliver the software increment to the customer for review and feedback.

Scrum helps teams manage projects with tight deadlines, changing requirements, and high
business importance by embracing disorder and uncertainty..
Other Agile Process Models
 Other Agile Process Models
Dynamic Systems Development Method (DSDM):
An agile software approach that uses incremental prototyping to meet tight deadlines. It follows the
modified Pareto principle, aiming to deliver 80% of an application in 20% of the time needed for
the full application.

DSDM's life cycle includes three different iterative cycles, preceded by two additional life cycle
activities:
1) Feasibility study: establishes the basic business requirements and constraints associated with
the application to be built and then assesses whether the application is a viable candidate for the
DSDM process
2) Business study: establishes the functional and information requirements that will allow the
application to provide business value; also, defines the basic application architecture and
 Other Agile Process Models
Dynamic Systems Development Method (DSDM):
3. Functional model iteration: Create incremental prototypes. The intent during this iterative cycle
is to gather additional requirements by eliciting feedback from users as they exercise the prototype.
4. Design and build iteration: Refine prototypes to ensure operational value.
5. Implementation: Deploy the software increment, continue refining as needed. It should be noted
that (1) the increment may not be 100 percent complete or
(2) changes may be requested as the increment is put into place.
In either case, DSDM development work continues by returning to the functional model iteration

DSDM can be combined with XP for a comprehensive approach and adapted with ASD concepts for
enhanced collaboration and self-organizing teams.
 Other Agile Process Models
Crystal methods:

Crystal family of agile methods, created by Alistair Cockburn and Jim Highsmith, - achieve
a software development approach that puts a premium on “maneuverability”.
They aim to make software development more flexible and efficient. They focus on
delivering working software along with preparing for future projects.
• The Crystal family offers various agile methodologies tailored to different project
needs. Teams can choose the method that suits their project best.
 Other Agile Process Models
Feature Driven Development (FDD):

It was originally coined by Peter Coad and his colleagues as a process model for object-
oriented software engineering. A feature is defined as "a client-valued function that can be
implemented in two weeks or less.“

- Features are small blocks of deliverable functionality, making them easier for users to
describe.
- Since a feature is the FDD deliverable software increment, the team develops operational
features every two weeks.
- Because features are small, their design and code representations are easier to manage.
 Other Agile Process Models
Feature Driven Development (FDD):
FDD adopts a philosophy that
(1) emphasizes collaboration among people on an FDD team;
(2) manages problem and project complexity using feature-based decomposition
followed by the integration of software increments, and
(3) communication of technical detail using verbal, graphical, and text-based means.
FDD emphasizes software quality assurance activities by encouraging an incremental
development strategy, the use of design and code inspections, the application of software
quality assurance audits, the collection of metrics, and the use of patterns (for analysis,
design, and construction).
 Other Agile Process Models
Feature Driven Development (FDD): The FDD approach defines five “collaborating”
framework activities (in FDD) - these are called “processes”
 Other Agile Process Models
Feature Driven Development (FDD):

The emphasis on the definition of features provides the following benefits:

• Because features are small blocks of deliverable functionality, users can describe them
more easily; understand how they relate to one another more readily; and better review
them for ambiguity, error, or omissions.
• Features can be organized into a hierarchical business-related grouping.
• Since a feature is the FDD deliverable software increment, the team develops operational
features every two weeks.
• Because features are small, their design and code representations are easier to inspect
effectively.
• Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an
arbitrarily adopted software engineering task set.
 Other Agile Process Models
Feature Driven Development (FDD):
Template for defining a feature:
<action> the <result> <by for of to> a(n) <object>
where an <object> is “a person, place, or thing (including roles, moments in time or intervals of time,
or catalog-entry-like descriptions).”

Examples of features for an e-commerce application might be:

Add the product to shopping cart
Display the technical-specifications of the product
Store the shipping-information for the customer

A feature set groups related features into business-related categories and is defined as:
<action><-ing> a(n) <object>
For example: Making a product sale is a feature set that would encompass the features noted earlier
and others.

FDD defines six milestones during the design and implementation of a feature: “design walkthrough,
design, design inspection, code, code inspection, promote to build”
 Other Agile Process Models
Lean Software Development (LSD): Lean Software Development (LSD) has adapted the principles of
lean manufacturing to the world of software engineering.
• LSD process can be summarized as eliminate waste, build quality in, create knowledge, defer
commitment, deliver fast, respect people, and optimize the whole.
• For example, eliminate waste within the context of an agile software project as
(1) adding no extraneous features or functions
(2) assessing the cost and schedule impact of any newly requested requirement,
(3) removing any extra process steps,
(4) establishing mechanisms to improve the way team members find information,
(5) ensuring the testing finds as many errors as possible
(6) reducing the time required to request and get a decision that affects the software or the process
that is applied to create it, and
(7) streamlining the manner in which information is transmitted to all stakeholders involved in
the process.
 Other Agile Process Models
Agile Modeling (AM): For large, business critical systems, the scope and complexity is high.
“weight” of these modeling methods - volume of notation required, the degree of formalism
suggested, the sheer size of the models for large projects, and the difficulty in maintaining the
model(s) as changes occur.

Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that
can be applied on a software development project in an effective and light-weight manner.

Agile Modeling (AM) promotes several key principles:

1. Model with a purpose: Before creating a model, developers should have a specific goal in mind,
such as communicating with customers or understanding software aspects.
 Other Agile Process Models
Agile Modeling (AM): Agile Modeling (AM) promotes several key principles:
2. Use multiple models: Different models and notations can describe software, each presenting
a unique system aspect. Only use models that provide value to their intended audience.
3. Travel light: Keep only models that offer long-term value as software engineering
progresses.
4. Content is more important than representation. Modeling should impart information to
its intended audience. A syntactically perfect model that imparts little useful content is not as
valuable as a model with flawed notation that nevertheless provides valuable content for its
audience.
 Other Agile Process Models

5. Know your models and tools: Understand the strengths and weaknesses of each

model and the tools used to create them.

6. Adapt locally: Tailor the modeling approach to suit the needs of the agile team.

A major segment of the software engineering community has adopted the Unified
Modeling Language (UML) as the preferred method for representing analysis and design
models.
 Other Agile Process Models
Agile Unified Process (AUP) : An agile approach which adopts a “serial in the large” and
“iterative in the small” philosophy for building computer-based systems. It focuses on both
the larger life-cycle and the iterations within each step to deliver incremental releases
over time.

Each iteration of AUP involves:

- Modeling: Creating UML representations of business and problem domains.

- Implementation: Translating models into source code.

- Testing: Designing and executing tests to find errors and ensure code meets requirements.
- Deployment: focuses on the delivery of a software increment and the acquisition of
feedback from end users.
 Other Agile Process Models

Agile Unified Process (AUP)

- Configuration and project management: Addressing change and risk management,

controlling work products, and tracking team progress.

- Environment management: Coordinating process infrastructure, standards, tools, and

support technology.
 A Tool Set For The Agile Process
1. Agile proponents debate the role of software tools, with some seeing them as minor
supplements(less role of tools than communication), while others, like Alistair Cockburn, believe
they can benefit agile teams.

2. Cockburn emphasizes the importance of tools that facilitate rapid understanding, ranging from
social (like pair programming during hiring) to technological (supporting distributed teams) to
physical (whiteboards, posters, index cards).

3. Effective communication is crucial, achieved through active means like pair programming and
passive methods like information displays.
 A Tool Set For The Agile Process

4. Project management tools in agile contexts replace traditional Gantt charts with earned value
charts and focus on improving the team's environment and culture.

5. Cockburn suggests that if these tools enhance a team member's work and improve the end
product's quality, they should be considered tools.
Chapter 2: Software Engineering knowledge
 Software Engineering knowledge
Many software practitioners(developers) think of software engineering knowledge as

knowledge of specific technologies: Java, Perl, html, C , and so on. Knowledge of specific

technology details is necessary to perform computer programming.

 Body of Software engineering knowledge had evolved into a “stable core” that represented

about “75 percent of the knowledge needed to develop a complex system.”

 As McConnell indicates, core principles are the elemental ideas that guide the software

engineers in the work that they do. It provide a foundation from which software engineering

models, methods, and tools can be applied and evaluated.

 Core principles
Software engineering is guided by a collection of core principles that help in the application of a

meaningful software process and the execution of effective software engineering methods.

• At the process level, core principles establish a foundation that guides a software team as it

performs framework and umbrella activities, navigates the process flow, and produces a set of

software engineering work products.

• At the level of practice, core principles establish a collection of values and rules that serve as a

guide to gather the requirements, analyze a problem, design a solution, implement and test the

solution, and deploy the software in the user community.

 General Principles that span SE
Set of general principles that span software engineering process and practice:
(1) provide value to end users,
(2) keep it simple,
(3) Maintain the vision (of the product and the project),
(4) recognize that others consume (and must understand) what you produce,
(5) be open to the future,
(6) plan ahead for reuse, and
(7) think!