1.

EXTREME PROGRAMMING (XP)

Extreme Programming (XP), the most widely used approach to agile software development,
emphasizes business results first and takes an incremental, get-something-started approach to
building the product, using continual testing and revision. XP proposed by Kent beck during
the late
1980’s.
XP Values
• Beck defines a set of five values that establish a foundation for all work performed as
part of XP— communication, simplicity, feedback, courage, and respect. Each of
these values is used as a driver for specific XP activities, actions, and tasks.
• In order to achieve effective communication between software engineers and other
stakeholders, XP emphasizes close, yet informal collaboration between customers and
developers, the establishment of effective metaphors for communicating important
concepts, continuous feedback, and the avoidance of voluminous documentation as a
communication medium.
• To achieve simplicity, XP restricts developers to design only for immediate needs,
rather than consider future needs. The intent is to create a simple design that can be
easily implemented in code. If the design must be improved, it can be refactored at a
later time.
• Feedback is derived from three sources: the implemented software itself, the
customer, and other software team members. By designing and implementing an
effective testing strategy the software provides the agile team with feedback. 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.
• Beck argues that strict adherence to certain XP practices demands courage. A better
word might be discipline. 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.
• By following each of these values, 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.
The 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. Following figure illustrates the XP process and notes
some of
the key ideas and tasks that are associated with each framework activity.

Key XP activities are

1) Planning. The planning activity begins with listening—a requirements gathering activity.
• Listening leads to the creation of a set of “stories” (also called user stories) that describe
required output, features, and functionality for software to be built.
• Each story is written by the customer and is placed on an index card. The customer
assigns a value (i.e., a priority) to the story 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 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 stories with highest value will be moved up in the schedule and implemented first
2) Design. XP design rigorously follows the KIS (keep it simple) principle.
• If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design. Called a spike solution.
• XP encourages refactoring—a construction technique that is also a method for design
optimization.
• Refactoring is the process of changing a software system in a way that it does not change
the external behavior of the code and improves the internal structure.

3) Coding. After stories are developed and preliminary design work is done, the team does
not
move to code, develops a series of unit tests for 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.
• Once the code is complete, it can be unit-tested immediately, and providing feedback to
the developers.
• A key concept during the coding activity is pair programming. i.e.., two people work
together at one computer workstation to create code for a story.
• As pair programmers complete their work, the code they develop is integrated with the
work of others.
4) Testing. The creation of unit tests before coding commences is a key element of the XP
approach. The unit tests that are created should be implemented using a framework that
enables them to be automated. This encourages a regression testing strategy whenever code is
modified.
• As the individual unit tests are organized into a “universal testing suite” integration and
validation testing of the system can occur on a daily basis. This provides the XP team with a
continual indication of progress and also can raise warning flags early if things go awry.
Wells states: “Fixing small problems every few hours takes less time than fixing huge
problems just before the deadline.”
• XP acceptance tests, also called customer tests, are specified by the customer and focus on
overall system features and functionality that are visible and reviewable by the customer.
Acceptance tests are derived from user stories that have been implemented as part of a
software release.
2. Scrum
Scrum is an agile software development method that was conceived by Jeff Sutherland and
his
development team in the early 1990s. Scrum principles are consistent with the agile
manifesto and are used to guide development activities within a process that incorporates the
following framework
activities: requirements, analysis, design, evolution, and delivery. Within each framework
activity,
work tasks occur within a process pattern called a sprint. The work conducted within a sprint
is
adapted to the problem at hand and is defined and often modified in real time by the Scrum
team.
The overall flow of the Scrum process is illustrated in following figure.

Scrum emphasizes the use of a set of software process patterns that have proven effective for
projects with tight timelines, changing requirements, and business criticality. Each of these
process patterns defines a set of development actions:
Backlog—a prioritized list of project requirements or features that provide business value for
the
customer. Items can be added to the backlog at any time. The product manager assesses the
backlog
and updates priorities as required.
Sprints—consist of work units that are required to achieve a requirement defined in the
backlog that
must be fit into a predefined time-box (typically 30 days). Changes (e.g., backlog work items)
are not
introduced during the sprint. Hence, the sprint allows team members to work in a short-term,
but
stable environment.
Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team.
Three key
questions are asked and answered by all team members
o What did you do since the last team meeting?
o What obstacles are you encountering?
o What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses from each
person. The Scrum meeting helps the team to uncover potential problems as early as possible.
Also,
these daily meetings lead to “knowledge socialization”
Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer. It is important to note that
the
demo may not contain all planned functionality, but rather those functions that can be
delivered
within the time-box that was established.
3. what is agile process, agility and agile principles.
Agile is a software development methodology to build software incrementally using short
iterations of 1 to 4 weeks so that the development process is aligned with the changing
business
needs.

➢ An agile team is a nimble team able to appropriately respond to changes. Change is what
software
development is very much about. Changes in the software being built, changes to the team
members, changes because of new technology, changes of all kinds that may have an impact
on
the product they build or the project that creates the product. Support for changes should be
built-
in everything we do in software, something we embrace because it is the heart and soul of
software.

➢ An agile team recognizes that software is developed by individuals working in teams and
that the
skills of these people, their ability to collaborate is at the core for the success of the project.

➢ The aim of agile process is to deliver the working model of software quickly to the
customer For
example: Extreme programming is the best known of agile process.
Agility Principles
Agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
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.
Not every agile process model applies these 12 principles with equal weight, and some
models
choose to ignore (or at least downplay) the importance of one or more of the principles.
WHAT IS AN AGILE PROCESS?
Any agile software process is characterized in a manner that addresses a number of key
assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will
change. It is equally difficult to predict how customer priorities will change as the project
proceeds.
2. For many types of software, design and construction are interleaved. That is, both activities
should be performed in tandem so that design models are proven as they are created. It is
difficult to predict how much design is necessary before construction is used to prove the
design.
3. Analysis, design, construction, and testing are not as predictable.
Given these three assumptions, an important question arises:
1) How do we create a process that can manage unpredictability?
It lies in process adaptability. An agile process, therefore, must be adaptable. But continual
adaptation without forward progress accomplishes little. Therefore, an agile software process
must adapt incrementally.
To accomplish incremental adaptation, an agile team requires customer feedback. An
effective
catalyst for customer feedback is an operational prototype or a portion of an operational
system.
Hence, an incremental development strategy should be instituted. Software increments must
be
delivered in short time periods so that adaptation keeps pace with change.
This iterative approach enables the customer to evaluate the software increment regularly,
provide
necessary feedback to the software team, and influence the process adaptations that are made
to
accommodate the feedback.
AGILITY AND THE COST OF CHANGE

➢ In conventional software development the cost of change increases non linearly as a

project
progresses (Fig Solid Black curve).

➢ An agile process reduces the cost of change because software is released in increments and
change can be better controlled within an increment.

➢ Agility argue that a well-designed agile process “flattens” the cost of change curve shown
in
following figure (shaded, solid curve), allowing a software team to accommodate changes
late in
a software project without dramatic cost and time impact.

➢ When incremental delivery is coupled with other agile practices such as continuous unit
testing
and pair programming, the cost of making a change is attenuated(reduced). Although debate
about
the degree to which the cost curve flattens is ongoing, there is evidence to suggest that a
significant reduction in the cost of change can be achieved. application, design, architecture
etc.
The verification process involves activities like reviews, walk-throughs and inspection.
4. software Quality

Explain each step

THE IMPORTANCE OF SOFTWARE QUALITY
Now a days, quality is the important aspect of all organization. Good quality software is the
requirement of all users. There are so many reasons that describe why the quality of software
is important; few among of those which are most important are described below:
Increasingly criticality of software:

➢ The final customer or user is naturally anxious about the general quality of software
especially about the reliability.

➢ They are concern about the safety because of their dependency on the software system
such as aircraft control system are more safety critical systems.
Earlier detection of errors during development-

➢ As software is developed through a number of phases; output of one phase is given as

input to the other one. So, if error in the initial phase is not found, then at the later stage, it is
difficult to fix that error and also the cost indulged is more.
The intangibility of software :

➢ Difficulty in verifying the satisfactory completion of project tasks.

➢ Tangibility is achieved by requiring developers to produce "deliverables" that can be
examined
for quality.
Accumulating errors during software development :

➢ Errors in earlier steps can propagate and accumulate in later steps.

➢ Errors found later in the project are more expensive to fix.

➢ The unknown number of errors makes the debugging phase difficult to control.
DEFINING SOFTWARE QUALITY
Quality is a rather vague term and we need to define carefully what we mean by it. For any
software
system there should be three specifications.
• A functional specification describing what the system is to do
• A quality specification concerned with how well the function are to operate
• A resource specification concerned with how much is to be spent on the system.
Attempt to identify specific product qualities that are appropriate to software , for instance,
grouped
software qualities into three sets. Product operation qualities, Product revision qualities and
product
transition qualities.
Product operation qualities:
• Correctness: The extent to which a program satisfies its specification and fulfil user
objective.
• Reliability: the extent to which a program can be expected to perform its intended
function with required precision.
• Efficiency: The amounts of computer resource required by software.
• Integrity: The extent to which access to software or data by unauthorized persons can
be controlled.
• Usability: The effort required to learn, operate, prepare input and interprets output.
Product Revision Qualities:
• Maintainability: The effort required to locate and fix an error in an operational
program
• Testability: The effort required to test a program to ensure it performs its intended
function.
• Flexibility: The effort required to modify an operational program.
Product Transition Qualities:
 • Portability: The efforts require to transfer a program from one hardware configuration
and or software system environment to another.
• Reusability: The extent to which a program can be used in other applications.
• Interoperability: The efforts required to couple one system to another.
When there is concerned about the need for a specific quality characteristic in a software
product then a quality specification with the following minimum details should be drafted .
1. Definition/Description
Definition: Clear definition of the quality characteristic.
Description: Detailed description of what the quality characteristic entails.
2. Scale o Unit of Measurement:
The unit used to measure the quality characteristic (e.g., faults per thousand lines of code).
3. Test
Practical Test: The method or process used to test the extent to which the quality attribute
exists.
4. Minimally Acceptable
Worst Acceptable Value: The lowest acceptable value, below which the product would be
rejected.
5. Target Range
Planned Range: The range of values within which it is planned that the quality measurement
value should lie.
6. Current Value
Now: The value that applies currently to the quality characteristic.
5. Product metrics and process metrics
The internal attributes may measure either some aspects of product or of the development
process(called process metrics).
1. Product Metrics:
Purpose: Measure the characteristics of the software product being developed.
Examples:
Size Metrics: Such as Lines of Code (LOC) and Function Points, which quantify the size or
complexity of the software.
Effort Metrics: Like Person-Months (PM), which measure the effort required to develop the
software.
Time Metrics: Such as the duration in months or other time units needed to complete the
development.
2. Process Metrics:
Purpose: Measure the effectiveness and efficiency of the development process itself.
Examples:
Review Effectiveness: Measures how thorough and effective code reviews are in finding
defects.
Defect Metrics: Average number of defects found per hour of inspection, average time taken
to
correct defects, and average number of failures detected during testing per line of code.
Productivity Metrics: Measures the efficiency of the development team in terms of output per
unit of effort or time.
Quality Metrics: Such as the number of latent defects per line of code, which indicates the
robustness of the software after development.
Differences:

➢ Focus: Product metrics focus on the characteristics of the software being built (size, effort,
time), while process metrics focus on how well the development process is performing
(effectiveness, efficiency, quality).

➢ Use: Product metrics are used to gauge the attributes of the final software product, aiding
in
planning, estimation, and evaluation. Process metrics help in assessing and improving the
development process itself, aiming to enhance quality, efficiency, and productivity.

➢ Application: Product metrics are typically applied during and after development phases to
assess the product's progress and quality. Process metrics are applied throughout the
development lifecycle to monitor and improve the development process continuously.
By employing both types of metrics effectively, software development teams can better
manage projects,
optimize processes, and deliver high-quality software products that meet user expectations.
6. Software project management
Software Project Management is an art & Science of planning & leading software Projects
from ideas to reality.
A Software Project is the complete procedure of software development from requirement
gathering to testing and maintenance, carried out according to the execution
methodologies, in a specified period of time to achieve intended software product.
WHY IS SOFTWARE PROJECT MANAGEMENT IMPORTANT?
• Large amounts of money are spent on ICT (information and communication technology)
e.g. UK government in 2003-04 spent € 2.3 billion on contracts for ICT and only € 1.4
billion on road building. (1 billion =100 crore).
• Project often fail – Standish Group claim only a third of ICT projects are successful. 82 %
were late and 43 % exceeded their budget. Poor project management a major factor in these
failures.
• The methodology used by the Standish Group to arrive at their findings has been criticized,
but the general perception of the prevalence of ICT project failure is still clear.
the end result.

1. Complexity Management
o Software projects often involve intricate systems and interdependencies. Effective
management of this complexity ensures that the project remains coherent and
manageable.
2. Requirement Management
o Clear and precise requirement management is essential to ensure that the final
product meets user needs and expectations. Mismanagement here can lead to scope
creep and project failure.
3. Time and Budget Control
o Monitoring and controlling the project timeline and budget is vital. This includes
planning, estimating, and adhering to schedules and financial constraints to prevent
overruns.
4. Risk Management
o Identifying, assessing, and mitigating risks can prevent unforeseen issues from
derailing a project. This proactive approach helps in managing uncertainties
effectively.
5. Quality Assurance
o Ensuring that the project meets quality standards is crucial for user satisfaction and
reducing post-release defects. Continuous testing and validation are key practices.
6. Team Coordination
o Effective communication and coordination among team members are essential for
collaboration and timely problem-solving, ensuring that everyone is aligned with
project goals.
7. Stakeholder Management
o Engaging and managing stakeholders helps in gaining their support and addressing
their concerns, which is critical for project acceptance and success.
8. Scope Management
o Defining and controlling what is included in the project prevents scope creep,
ensures that all necessary features are delivered, and avoids unnecessary work.
9. Process Improvement
o Continuously improving processes ensures that the project is using the most
efficient methods and practices, leading to better performance and outcomes.
10. Resource Allocation
o Efficient allocation and management of resources (human, financial, and material)
ensure that the project has what it needs to succeed without wastage.
ACTIVITIES COVERED BY SOFTWARE PROJECT MANAGEMENT:
The activities covered by Software Project management are diagrammatically illustrated as
follows:

The Feasibility Study:

This is an investigation into whether a prospective project is worth starting that it has a
valid business case. Information is gathered about the requirements of the proposed
application.
The probable developmental and operational costs, along with the value of the benefits of the
new
system, are estimated. The study could be part of a strategic planning exercise examining and
prioritizing a range of potential software developments.
Planning:
If the feasibility study produces results which indicate that the prospective project appears
viable, planning of the project can take place. However, for a large project, we would not do
all
our detailed planning right at the beginning. We would formulate an outline plan for the
whole
project and a detailed one for the first stage. More detailed planning of the later stages would
be
done as they approached. This is because we would have more detailed and accurate
information
upon which to base our plans nearer to the start of the later stages.
Project Execution:
The project can now be executed. The execution of a project often contains design and
implementation subphases. The same is illustrated in Figure 1.2 which shows the typical
sequence of software development activities recommended in the international standard ISO
12207.
Requirements Analysis:
This starts with requirement elicitation or requirement gathering which establishes what
the users require of the system that the project is to implement. Some work along these lines
will almost certainly have been carried out when the project was evaluated, but now the
original information obtained needs to be updated and supplemented.
7.

7. LOC Function points

8. Agile programming
Answers not found