0% found this document useful (0 votes)
20 views8 pages

Sit309 Agile D Dev Lect 1n2 Slides

Uploaded by

mutisov261
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views8 pages

Sit309 Agile D Dev Lect 1n2 Slides

Uploaded by

mutisov261
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

2/2/2023

SIT309 AGILE TEST DRIVEN S/W DEVELOPMENT


Kumbuka; Software Development Method
• In software engineering & development context; a software
development methodology or system development
methodology is a framework that is used to structure, plan,
and control the process of developing an information
system.

• An information system (IS) - is any combination of


information technology (IT) and people's activities that
support operations, management and decision making in an
organizational establishment. .

• In a very broad sense, the term information system is


LECTURE 1 & 2 frequently used to refer to the interaction between people,
AGILE MANIFESTO, PRINCIPLES, & LIFE CYCLE processes, data and technology.
By Mbogo Njoroge

1 2

Agile kwanini?
Why Agile Methodologies? The Agile Approach
• Instead of phases, projects are broken down into releases
• Traditionally projects are delivered in a series of phases that and iterations. At the end of each iteration you have a fully
are based on increasing levels of certainty around the system functioning system that could be released:
being built:

• However this approach has some drawbacks:


– It is not flexible to changes in customer requirements
– Time is wasted building features that nobody needs
– The end user cannot give feedback till it’s completed coded
– You don’t know how stable the system is until the end
3 4

What is Agile?
How does Agile work?
Agile ni nini?
It works by breaking projects down into little bits of user
Agile is a time boxed, iterative approach to software delivery functionality called user stories, prioritizing them, and then
that builds software incrementally from the start of the continuously delivering them in short two week cycles
project, instead of trying to deliver it all at once near the end. called iterations.

1
2/2/2023

How is Agile different?


The Agile Model
Analysis, design, coding, and testing are continuous
activities
• Agile = “Characterized by quickness, lightness, and
ease of movement” You are never done analysis, design, coding and testing on
an Agile project. So long as there are features to build, and
the means to deliver them, these activities continue for the
• Agile Software development is about fast delivery of duration of the project.
software with more ease of development

• Emphasizes customer satisfaction through continuous


delivery of functional software

• The two most popular methods are Scrum and


eXtreme Programming (XP)

Agile vs Waterfall Agile vs Waterfall (cont’d)


Waterfall challenges Thirdly you've got schedule risk because you never
Too risky know if you are going to make it until the end.
Traditional Waterfall treats analysis, design, coding, and testing as
discrete phases in a software project. This worked OK when the cost of You've got technical risk because you don't actually
get to test your design or architecture until late in
change was high. But now that it's low it hurts us in a couple of ways.
the project.
Poor quality
First off, when the project starts to run
out of time and money, testing is the And you've got product risk because don't even
only phase left. This means good know if you are building the right until it's too late to
projects are forced to cut testing short make any changes.
and quality suffers.
Poor visibility Can't handle change

Secondly, because working software isn't And finally, most importantly, it's just
produced until the end of the project, you not a great way for handling
never really know where you are on a change.
Waterfall project. That last 20% of the
project always seems to take 80% of the
time.

Agile Software Development Manifesto Agile Manifesto


On February 11-13, 2001, at The Lodge in Snowbird ski resort in the
Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and
try to find common ground—and of course, to eat.
• The twenty-first century customer demands a quality What emerged was the Agile ‘Software Development’ Manifesto.
application delivered almost immediately (History: The Agile Manifesto)
• In 2001 a group of developers met to discuss the state of The manifesto stipulates Agile core values as follows;
lightweight (not too many rigorous rules) and rapid 1. Individuals and interactions over Process and tools
development methodologies
• They created the "Manifesto for Agile Software Development," 2. Working software over Comprehensive documentation
a document that became the cornerstone of the Agile
3. Customer collaboration over Contract negotiation
movement
4.Responding to change over Following a plan

The elements on the left side are valued more than the elements
on the right side but that does not mean elements on left side are
irrelevant 12

2
2/2/2023

Value 1: Individuals and Interactions over Value 2: Working Software over


Processes and Tools Comprehensive Documentation
• Strong players: a must, but can fail if don’t work together. • Code – not ideal medium for communicating rationale and
• Strong player: not necessarily an ‘ace;’ work well with system structure.
others! – Team needs to produce human readable documents describing
– Communication and interacting is more important than system and design decision rationale.
raw talent.
• ‘Right’ tools are vital to smooth functioning of a team. • Too much documentation is worse than too little.
• Start small. Find a free tool and use until you can demo
you’ve outgrown it. Don’t assume bigger is better. Start – Take time; more to keep in sync with code; Not kept in
with white board; flat files before going to a huge database. sync? it is a lie and misleading.
• Building a team more important than building environment.
– Some managers build the environment and expect the • Short rationale and structure document.
team to fall together.
– Doesn’t work. – Keep this in sync; Only highest level structure in the
– Let the team build the environment on the basis of need. system kept.
13 14

Value 2(cont’d): Working Software over Value 3: Customer Collaboration over Contract
Comprehensive Documentation Negotiation
• How to train newbees if short & sweet?
– Work closely with them.
• Not possible to describe software requirements
– Transfer knowledge by sitting with them; make part of team via
close training and interaction
up front and leave someone else to develop it
• Two essentials for transferring info to new team members:
within cost and on time.
– Code is the only unambiguous source of information.
– Team holds every-changing roadmap of systems in their heads; • Customers cannot just cite needs and go away
cannot put on paper.
– Best way to transfer info- interact with them.
• Fatal flaw: Pursue documentation instead of software:
• Successful projects require customer feedback
• Rule: Produce no document unless need is immediate and
on a regular and frequent basis – and not
significant. dependent upon a contract or SOW.
15 16

Value 3(cont’d): Customer Collaboration over Value 4: Responding to Change over Following
Contract Negotiation a Plan
• Best contracts are NOT those specifying requirements, • Our plans and the ability to respond to changes is critical!
schedule and cost. • Course of a project cannot be predicted far into the future.
– Become meaningless shortly. – Too many variables; not many good ways at estimating cost.
• Far better are contracts that govern the way the • Tempting to create a PERT or Ghant chart for whole project.
development team and customer will work together.
– This does Not give novice managers control.
• Key is intense collaboration with customer and a – Can track individual tasks, compare to actual dates w/planned dates
contract that governed collaboration rather than details and react to discrepancies.
of scope and schedule – But the structure of the chart will degrade
– Details ideally not specified in contract. – As developers gain knowledge of the system and as customer gains
– Rather contracts could pay when a block passed customer’s knowledge about their needs, some tasks will become unnecessary;
acceptance tests. others will be discovered and will be added to ‘the list.’
– With frequent deliverables and feedback, acceptance tests – In short, the plan will undergo changes in shape, not just dates.
never an issue.
17 18

3
2/2/2023

Value 4(cont’d): Responding to Change over The Twelve Principles of Agile Software
Following a Plan The signatories of the Agile s/w manifesto explicitly stated the
principles upon which the formulated manifesto would best be
• Better planning strategy – make detailed plans for the fulfilled and differentiate agile processes from others s/w
next few weeks, very rough plans for the next few development process. They stated; We follow these principles:
months, and extremely crude plans beyond that.
i. Our highest priority is to satisfy the customer through early
• Need to know what we will be working on the next few and continuous delivery of valuable software.
weeks; roughly for the next few months; a vague idea ii. Welcome changing requirements, even late in development.
what system will do after a year. Agile processes harness change for the customer's
• Only invest in a detailed plan for immediate tasks; competitive advantage.
once plan is made, difficult to change due to iii. Deliver working software frequently, from a couple of weeks
momentum and commitment. to a couple of months, with a preference to the shorter
– But rest of plan remains flexible. The lower resolution timescale.
parts of the plan can be changed with relative ease. iv. Business people and developers must work together daily
throughout the project.
19 20

vi. Build projects around motivated individuals. Give them the


environment and support they need, and trust them to get the job Principle 1: Our Highest Priority is to Satisfy the Customer
done. through Early and Continuous Delivery of Valuable Software
vii. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation. Number of practices have significant impact upon quality of final system:
viii. Working software is the primary measure of progress. • Strong correlation between quality and early delivery of a partially
ix. Agile processes promote sustainable development. The sponsors, functioning system.
developers, and users should be able to maintain a constant pace – The less functional the initial delivery, the higher the quality of the final
indefinitely. delivery.
x. Continuous attention to technical excellence and good design • Another strong correlation exists between final quality and frequently
enhances agility. deliveries of increasing functionality.
xi. Simplicity--the art of maximizing the amount of work not done--is – The more frequent the deliveries, the higher the final quality.
essential.
xii. The best architectures, requirements, and designs emerge from self- • Agile processes deliver early and often.
organizing teams. – Rudimentary system first followed by systems of increasing
xiii. At regular intervals, the team reflects on how to become more functionality every few weeks.
effective, then tunes and adjusts its behavior accordingly. – Customers my use these systems in production, or
– May choose to review existing functionality and report on changes to be
Ufafanuzi wa kina wa kila kiungo cha principia hizi 12 wa fuata made.
kwenye slidi zifuatozo 21
– Regardless, they must provide meaningful feedback. 22

Principle 2: Welcome Changing Requirements, even late in Principle 3: Deliver Working Software Frequently
Development. Agile Processes harness change for the (From a couple of weeks to a couple of months with a
Customer’s Competitive Advantage. preference to the shorter time scale.
• This is a statement of attitude.
• Participants in an agile process are not afraid of change. • We deliver working software.
– Deliver early and often.
– Requirement changes are good;
– Be not content with delivering bundles of
– Mean team has learned more about what it will take to documents, or plans.
satisfy the market.
– Don’t count those as true deliverables.

• Agile teams work to keep the software structure flexible, • The goal of delivering software that satisfies the
so requirement change impact is minimal. customer’s needs.

• Moreso, the principles of object oriented design help us to


maintain this kind of flexibility. 23 24

4
2/2/2023

Principle 4: Business People and Developers Must Work Principle 5: Build Projects around Motivated Individuals.
Together Daily throughout the Project. (Give them the environment and support they need, and
trust them to get the job done.)
• For agile projects, there must be significant and frequent • An agile project has people the most important factor
interaction between the of success.
– customers, – All other factors, process, environment,
management, etc., are considered to be second
– developers, and order effects, and are subject to change if they are
– stakeholders. having an adverse effect upon the people.

An agile project must be continuously guided. • Example: if the office environment is an obstacle to the
team, change the office environment.
• If certain process steps are obstacles to the team,
change the process steps.

25 26

Principle 6: The Most Efficient and Effective Method of Principle 7: Working Software is the Primary Measure
Conveying Information to and within a Development of Progress
Team is face-to-face Communications.
• Agile projects measure their progress by measuring the
• In agile projects, developers talk to each other.
amount of working software.
– The primary mode of communication is
– Progress not measusred by phase we are in, or
conversation.
– by the volume of produced documentation or
– Documents may be created, but there is no attempt
to capture all project information in writing. – by the amount of code they have created.
• An agile project team does not demand written specs,
written plans, or written designs. • Agile teams are 30% done when 30% of the necessary
– They may create them if they perceive an immediate functionality is working.
and significant need, but they are not the default.
– The default is conversation.
27 28

Principle 8: Agile Processes promote sustainable


Principle 9: Continuous Attention to Technical
development The sponsors, developers, and users
should be able to maintain a constant pace indefinitely. Excellence and Good Design enhances Agility.

• An agile project is not run like a 50 yard dash; it is run like a


• High quality is the key to high speed.
marathon. – The way to go fast is to keep the software as clean
– The team does not take off at full speed and try to maintain that and robust as possible.
speed for the duration.
– Rather they run at a fast, but sustainable, pace.

– Thus, all agile team-members are committed to


• Running too fast leads to burnout, shortcuts, and debacle.
• Agile teams pace themselves. producing only the highest quality code they can.
– They don’t allow themselves to get too tired.
– They don’t borrow tomorrow’s energy to get a bit more done today.
– They work at a rate that allows them to maintain the highest quality – They do not make messes and then tell themselves
standards for the duration of the project. they’ll clean it up when they have more time.
– Do it right the first time!
29 30

5
2/2/2023

Principle 10: Simplicity – the art of maximizing the Principle 11: The Best Architectures, Requirements, and
amount of work not done – is essential. Designs emerge from Self-Organizing Teams

• Agile teams take the simplest path that is consistent • An agile team is a self organizing team.
– Responsibilities are not handed to individual team
with their goals. members from the outside.
– Responsibilities are communicated to the team as a whole,
and the team determines the best way to fulfill them.
– They don’t anticipate tomorrow’s problems and
try to defend against them today. • Agile team members work together on all project
aspects.
– Each is allowed input into the whole.
– No single team member is responsible for the architecture,
– Rather they do the simplest and highest quality or the requirements, or the tests, etc.
work today, confident that it will be easy to – The team shares those responsibilities and each team
member has influence over them.
change if and when tomorrows problems arise.

31 32

Principle 12: At regular Intervals, the Team reflects on


how to become more effective, then tunes and adjusts
Conclusions
its behavior accordingly. • The professional goal of every software engineer, and every
development team, is to deliver the highest possible value to our
employers and customers.
– And yet, our projects fail, or fail to deliver value, at a dismaying rate.
• Though well intentioned, the upward spiral of process inflation is
• An agile team continually adjusts its organization, culpable for at least some of this failure.
rules, conventions, relationships, etc. • The principles and values of agile software development were
formed as a way
– to help teams break the cycle of process inflation, and
– to focus on simple techniques for reaching their goals.
• An agile team knows that its environment is
continuously changing, and knows that they must • At the time of this writing there were many agile processes to
choose from. These include
change with that environment to remain agile. – SCRUM,
– Crystal,
– Feature Driven Development (FDD),
– Adaptive Software Development (ADP), and most significantly,
– Extreme Programming (XP).
– Others…
33 34

Key Features of Agile Development vi. Adaptive: The methodology in general is very adaptive, so that the
application that is developed can cater to the arrival of new
i. Iterative: Entire application is distributed in incremental units requirements throughout its development. Goal is not to remove the
called iterations. Development time of each iteration is small
(couple of weeks), fixed and strictly adhered to. Every Iteration is uncertainty in the very beginning, but is to adapt to the changing needs.
a mini-increment of the functionality and is build on top of vii. Empowered Teams: Project teams are generally small and have lot of
previous iteration. interaction and communication. Since the entire team is actively
ii. Active Customer Involvement: There is a lot of client
involvement and face-to-face interaction. Every iteration is involved, the team is empowered to make decisions
tested and approved by the client. The feedback obtained is viii. People Centric: More emphasis is on using well-skilled people to do the
implemented in subsequent iterations; thus minimizing risk and development than on following specific processes. Documentation and
ensuring higher client satisfaction.
other non-development activities are minimized and more time is
iii. Feature Driven: More emphasis is on providing the required
features in the application. 80/20 principle is applied to decide devoted to development and testing.
the 20% of features which will be used 80% of the time. ix. More Disciplined: Everything should be delivered correctly the first
iv. Fixed Time: Each iteration has a fixed time span (couple of time. So the process involves a lot of team discipline and self-discipline.
weeks) in which it is delivered.
Thus, it requires highly-skilled and organized team members.
v. Priority-Based Delivery: Features are prioritized depending on
customer need, development risk, etc. High priority features are x. Simplicity: Emphasis is on keeping things as simple as possible and
developed first. After every iteration, the project priorities are being open to change.
re-evaluated. 35 36

6
2/2/2023

Benefits of Agile Development Approach Benefits to the Project Team


i. Project team is involved more actively in all the stages. The
team members collaboratively make decisions and are more
Benefits to the Customer empowered.
i. Customer is more actively involved, and gets higher ii. Since the development is incremental, team can focus on
priority the current requirements at any given point of time.
ii. Customer gets regular and frequent status updates iii. More emphasis is on developing the application only, and
not on documentation. Simple and minimal documents are
iii. Requirements are "accepted" after each iteration used.
iv. Agile methodology emphasizes rapid delivery. So iv. Less time is spent in gathering requirements as all the
the key functionalities can be available to use requirements are not gathered up front and are
sooner. implemented only when they arise.
v. Delivery is defined by a fixed timescale. So the v. Less time is required for planning.
customer is assured of receiving some functionality vi. Less cost of development as rework, management,
by a fixed time period. documentation, and other non-development work-related
cost is reduced.
vi. More testing is done, so better software quality is vii. Team develops application collaboratively and in a
delivered cooperative environment.
37 38

Problems with agile methods


S/W Projects Best Suited for Agile are Projects;
i. It can be difficult to keep the interest of customers / users who are
involved in the process.
ii. Highly skilled and flexible people with passion should be involved.
Team members may be unsuited to the intense technical i. That frequently changing requirements
involvement that characterizes agile methods.
ii. Whose team and the customer are co-located
iii. Prioritizing changes can be difficult where there are multiple
stakeholders. iii. Whose client is open to lot of involvement and ready to
iv. Maintaining simplicity requires extra work. It requires more testing invest time
and active customer involvement. Code will be integrated
continuously. To ensure the application is always in a workable
state, all the code has to work … always.
v. It impacts management more than developers. Management has
to be more open, be actively involved in the development process
and (most importantly) allow the team to make decisions.
vi. Because of their focus on small, tightly-integrated teams, there are
problems in scaling agile methods to large systems.
vii. Less emphasis on documentation - harder to maintain when you
get a new team for maintenance
39 40

Agile Iteration Life Cycle Stages The Process of Agile Software Development
I. Kick-off meeting.
II. Known requirements are understood and prioritized.
Development plan is proposed accordingly.
III. Relative complexity of each requirement is estimated.
IV. Sufficient design using simple diagrams is done.
V. Test Driven Development (TDD) approach may be used.
TDD emphases “writing test first and then writing code
to pass the test”. It can help in avoiding over-coding.
VI. Development is done sometimes in pairs with a lot of
team interaction. Ownership of code is shared when
pair programming is done.
VII. Code is tested more frequently.

41 42

7
2/2/2023

Some Agile Methods of S/W Development


• Rapid Application Development (RAD)
• Incremental SDLC
• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Crystal Clear
• Dynamic Software Development Method (DSDM)
• Rational Unify Process (RUP)

43

You might also like