UNIVERSITI KEBANGSAAN MALAYSIA

FAKULTI TEKNOLOGI DAN SAINS MAKLUMAT

TK2013 METODOLOGI KEJURUTERAAN PERISIAN

ASSIGNMENT :

AGILE SOFTWARE DEVELOPMENT

PENSYARAH : PROF. MADYA DR. SALWANI BINTI ABDULLAH

BIL NAMA NO. MATRIK

1. FAUZIYAH BINTI MOHD SHOBIRIN GA00698

2. FOUZILA BINTI ABU GA00699

3. WAN MOHD NAZRI BIN WAN ABDULLAH GA00728

4. SITI ROSELA BINTI MOHAMED GA00725

5. NURUL AINI BINTI MOHAMAD GA00719

 Software Engineering (TK2013) - Agile Software Development

INTRODUCTION

Agile Modeling (AM) is a practice-based methodology for effective modeling and

documentation of software-based systems. Simply put, 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 software development was a significant departure from the heavyweight document-
driven software development methodologies such as waterfall. While the publication of the
“Manifesto for Agile Software Development” didn’t start the move to agile methods, which
had been going on for some time, it did signal industry acceptance of agile philosophy. A
recent survey conducted by Dr. Dobb’s Journal shows 41 percent of development projects
have now adopted agile methodology, and agile techniques are being used on 65 percent
of such projects.

Manifesto for Agile Software Development

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.

Figure 1: The agile software development manifesto

TWO AGILE SOFTWARE DEVELOPMENT METHODOLOGIES

The most widely used methodologies based on the agile philosophy are XP and Scrum.
These differ in particulars but share the iterative approach described above.

1. XP (Extreme Programming)

XP stands for extreme programming. It concentrates on the development rather than

managerial aspects of software projects. XP was designed so that organizations would
be free to adopt all or part of the methodology.

Page 2
 Software Engineering (TK2013) - Agile Software Development

XP development

XP projects start with a release planning phase, followed by several iterations, each of
which concludes with user acceptance testing. When the product has enough features to
satisfy users, the team terminates iteration and releases the software.

Users write “user stories” to describe the need the software should fulfill. User stories help
the team to estimate the time and resources necessary to build the release and to define
user acceptance tests. A user or a representative is part of the XP team, so he or she can
add detail to requirements as the software is being built. This allows requirements to evolve
as both users and developers define what the product will look like.

To create a release plan, the team breaks up the development tasks into iterations. The
release plan defines each iteration plan, which drives the development for that iteration. At
the end of iteration, users perform acceptance tests against the user stories. If they find
bugs, fixing the bugs becomes a step in the next iteration.

Iterative user acceptance testing, in theory, can result in release of the software. If users
decide that enough user stories have been delivered, the team can choose to terminate the
project before all of the originally planned user stories have been implemented.

Figure 2: A simplified XP process

Page 3
 Software Engineering (TK2013) - Agile Software Development

XP Rules And Concepts

Here are the most important concepts:

1. Integrate Often - Development teams must integrate changes into the development
baseline at least once a day. This concept is also called continuous integration.

2. Project Velocity - Velocity is a measure of how much work is getting done on the
project. This important metric drives release planning and schedule updates.

3. Pair Programming - All code for a production release is created by two people
working together at a single computer. XP proposes that two coders working
together will satisfy user stories at the same rate as two coders working alone, but
with much higher quality.

4. User Story - A user story describes problems to be solved by the system being built.
These stories must be written by the user and should be about three sentences long.
User stories do not describe a solution, use technical language, or contain traditional
requirements- peak, such as “shall” statements. Instead, a sample user story might
go like this: Search for customers. The user tells the application to search for
customers. The application asks the user to specify which customers. After the user
specifies the search criteria, the application returns a list of customers meeting those
criteria.

Because user stories are short and somewhat vague, XP will only work if the customer
representative is on hand to review and approve user story implementations. This is one of
the main objections to the XP methodology, but also one of its greatest strengths.

2. Scrum

In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players
engaged with each other to get a job done. In software development, the job is to put out a
release. Scrum for software development came out of the rapid prototyping community
because prototypers wanted a methodology that would support an environment in which
the requirements were not only incomplete at the start, but also could change rapidly during
development.

Scrum management methodology actually originated earlier in the manufacturing

community and was adopted and adapted by software developers. Unlike XP, Scrum
methodology includes both managerial and development processes. Some development
organizations have combined Scrum managerial processes with XP development
processes. The adoption rate is still rather low but growing.

Page 4
 Software Engineering (TK2013) - Agile Software Development

Scrum Management

At the center of each Scrum project is a backlog of work to be done. This backlog is
populated during the planning phase of a release and defines the scope of the release.

After the team completes the project scope and high-level designs, it divides the
development process into a series of short iterations called sprints. Each sprint aims to
implement a fixed number of backlog items. Before each sprint, the team members identify
the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to
articulate lessons learned and check progress.

During a sprint, the team has a daily meeting called a scrum. Each team member describes
the work to be done that day, progress from the day before, and any blocks that must be
cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone
in the same room standing up for the whole meeting.

When enough of the backlog has been implemented so that the end users believe the
release is worth putting into production, management closes development. The team then
performs integration testing, training and documentation as necessary for product release.

Scrum Development

The Scrum development process concentrates on managing sprints. Before each sprint
begins, the team plans the sprint, identifying the backlog items and assigning teams to
these items. Teams develop, wrap, review, and adjust each of the backlog items. During
development, the team determines the changes necessary to implement a backlog item.
The team then writes the code, tests it, and documents the changes. During wrap, the team
creates the executable necessary to demonstrate the changes. In review, the team
demonstrates the new features, adds new backlog items, and assesses risk. Finally, the
team consolidates data from the review to update the changes as necessary.

Figure 2: A simplified SCRUM process

Page 5
 Software Engineering (TK2013) - Agile Software Development

ADVANTAGES OF AGILE

1. Revenue - The iterative nature of agile development means features are delivered
incrementally, enabling some benefits to be realized early as the product continues to
develop.

2. Speed-to-market - Research suggests about 80% of all market leaders were first to
market. As well as the higher revenue from incremental delivery, agile development
philosophy also supports the notion of early and regular releases, and 'perpetual beta'.

3. Quality - A key principle of agile development is that testing is integrated throughout the
lifecycle, enabling regular inspection of the working product as it develops. This allows the
product owner to make adjustments if necessary and gives the product team early sight of
any quality issues.

4. Visibility - Agile development principles encourage active 'user' involvement throughout

the product's development and a very cooperative collaborative approach. This provides
excellent visibility for key stakeholders, both of the project's progress and of the product
itself, which in turn helps to ensure that expectations are effectively managed.

5. Risk Management - Small incremental releases made visible to the product owner and
product team through its development help to identify any issues early and make it easier
to respond to change. The clear visibility in agile development helps to ensure that any
necessary decisions can be taken at the earliest possible opportunity, while there's still time
to make a material difference to the outcome.

6. Flexibility / Agility - In traditional development projects, we write a big spec up-front and
then tell business owners how expensive it is to change anything, particularly as the project
goes on. In fear of scope creep and a never-ending project, we resist changes and put
people through a change control committee to keep them to the essential minimum. Agile
development principles are different. In agile development, change is accepted. In fact, it's
expected. Because the one thing that's certain in life is change. Instead the timescale is
fixed and requirements emerge and evolve as the product is developed. Of course for this
to work, it's imperative to have an actively involved stakeholder who understands this
concept and makes the necessary trade-off decisions, trading existing scope for new.
Page 6
 Software Engineering (TK2013) - Agile Software Development

7. Cost Control - The above approach of fixed timescales and evolving requirements
enables a fixed budget. The scope of the product and its features are variable, rather than
the cost.

8. Business Engagement/Customer Satisfaction - The active involvement of a user

representative and/or product owner, the high visibility of the product and progress, and the
flexibility to change when change is needed, create much better business engagement and
customer satisfaction. This is an important benefit that can create much more positive and
enduring working relationships.

9. Right Product - Above all other points, the ability for agile development requirements to
emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the
team build the right product. It's all too common in more traditional projects to deliver a
"successful" project in IT terms and find that the product is not what was expected, needed
or hoped for. In agile development, the emphasis is absolutely on building the right product.

10. More Enjoyable - The active involvement, cooperation and collaboration make agile
development teams a much more enjoyable place for most people. Instead of big specs,
we discuss requirements in workshops. Instead of lengthy status reports, we collaborate
around a task-board discussing progress. Instead of long project plans and change
management committees, we discuss what's right for the product and project and the team
is empowered to make decisions. In my experience this makes it a much more rewarding
approach for everyone. In turn this helps to create highly motivated, high performance
teams that are highly cooperative.

DISADVANTAGES OF AGILE

1. Active user involvement and close collaboration are required throughout the
development cycle. This is very engaging, rewarding and ensures delivery of the
right product. It's the fundamental principle in agile that ensures expectations are
well managed. And since the definition of failure is not meeting expectations, these
are critical success factors for any project. However these principles are very
demanding on the user representative's time and require a big commitment for the
duration of the project.

Page 7
 Software Engineering (TK2013) - Agile Software Development

2. Requirements emerge and evolve throughout the development. This creates the
very meaning of agile - flexibility. Flexibility to change course as needed and to
ensure delivery of the right product. There are two big flip sides to this principle
though. One is the potential for scope creep, which we all know can create the risk
of ever-lasting projects. The other is that there is much less predictability, at the start
of the project and during, about what the project is actually going to deliver. This can
make it harder to define a business case for the project, and harder to negotiate
fixed price projects. Without the maturity of a strong and clear vision, and the
discipline of fixing timescales and trading scope, this is potentially very dangerous.

3. Agile requirements are barely sufficient. This eliminates wasted effort on

deliverables that don't last (i.e. aren't part of the finished product), which saves time
and therefore money. Requirements are clarified just in time for development and
can be documented in much less detail due to the timeliness of conversations.
However this can mean less information available to new starters in the team about
features and how they should work. It can also create potential misunderstandings if
the teamwork and communication aren't at their best, and difficulties for team
members (especially testers) that are used to everything being defined up front. The
belief in agile is that it's quicker to refactor the product along the way than to try to
define everything completely up front, which arguably is impossible. And this risk is
managed closely through the incremental approach to development and frequent
delivery of product.

4. Testing is integrated throughout the lifecycle. This helps to ensure quality throughout
the project without the need for a lengthy and unpredictable test phase at the end of
the project. However it does imply that testers are needed throughout the project
and this effectively increases the cost of resources on the project. This does have
the effect of reducing some very significant risks, that have proven through research
to cause many projects to fail. The cost of a long and unpredictable test phase can,
in my experience of waterfall, cause huge unexpected costs when a project over-
runs. However there is an additional cost to the project to adopt continuous testing
throughout.

5. Frequent delivery of product and the need to sign off each feature as done before
moving on to the next makes UAT (user acceptance testing) continuous and
therefore potentially quite onerous. The users or product owner needs to be ready
and available for prompt testing of the features as they are delivered and throughout
the entire duration of the project. This can be quite time-consuming but helps
drastically to ensure a quality product that meets user expectations.

Page 8
 Software Engineering (TK2013) - Agile Software Development

6. Common feedback is that agile development is rather intense for developers. The
need to really complete each feature 100% within each iteration, and the
relentlessness of iterations, can be mentally quite tiring so it's important to find a
sustainable pace for the team.

THE FUTURE OF AGILE DEVELOPMENT

Agile methodology is becoming very popular for software projects. Its supporters boast that
it speeds up software development and delivers precisely what the customer wants, when
the customer want it, while fostering teamwork and empowering employees. Before
implementing agile development, the purposed system and development methods should
be examined carefully. As experienced IT professional know, a one-size-fits-all solution
does not exist.

Page 9
 Software Engineering (TK2013) - Agile Software Development

REFFERENCE

http://www.agilemodeling.com/essays/introductionToAM.htm

http://balagan.org.uk/work/agile_comparison.htm

http://www.agilealliance.org/articles

http://oc.course.com/sc/sad8e/web.cfm

http://www.agile-software-development.com/2007/09/disadvantages-of-agile-software.html

Page 10