Chapter 3 Flashcards
Agile Software Development
Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods:
▪ Focus on the code rather than the design
▪ Are based on an iterative approach to software development
▪ Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.
What is the aim of Agile models?
The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements
without excessive rework.
Agile Manifesto
Individuals and interactions over processes and tools (we care about fulfilling the needs)
Working software over comprehensive documentation (we don’t focus on documentation since we don’t have time)
Customer collaboration over contract negotiation (not a clear contract to stick to, since things/client’s needs change)
Responding to change over following a plan (you don’t have a design, so you accept change)
The principles of agile methods
Customer involvement: Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.
Incremental delivery: The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process: The skills of the development team should be recognized.
Embrace change: Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity: Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work to eliminate complexity from the system.
Agile method applicability
▪ Cannot be used for every type of product.
▪ If you have a good collaborative team that communicates and has soft skills.
▪ If you have a client that is involved/committed.
▪ If you have a small/medium sized product.
Problems with agile methods
It can be difficult to keep the interest of customers who are involved in the process.
Team members may be unsuited to the intense involvement that characterizes agile methods.
Prioritizing changes can be difficult where there are multiple stakeholders.
Maintaining simplicity requires extra work.
Contracts may be a problem since in Agile models we don’t have a clear one.
Choosing between Plan-Driven vs. Agile Models
Is it important to have a very detailed specification and design before moving to implementation? If so, you probably need to use a plan-driven approach.
Is an incremental delivery strategy realistic? If so, consider using agile methods.
How large is the system that is being developed? Agile -> small / Plan-Driven -> large.
What type of system is being developed?
Plan-driven approaches may be required for systems that require a lot of analysis before implementation.
What is the expected system lifetime?
not long-term -> Agile / not change & stable -> Plan-Driven
What technologies are available to support system development?
Agile relies on good tools to keep track of evolving design.
How is the development team organized?
Are there cultural or organizational issues that may affect the system development?
How good are the designers and programmers in the development team?
Extreme Programming (XP), XP and agile principles, The cycle
To push things to the extreme.
▪ New versions may be build several times per day.
▪ Increments are delivered to the customers every two weeks.
▪ The build is only accepted if the tests run successfully.
▪ Supports peer-programming (where people work in pairs for the same project)
▪ Customer involvement means full-time customer engagement with the team.
▪ Testing before implementation (you create tests while developing the code)
The cycle:
▪ Select user stories (requirements document) for this release.
▪ Break down stories into tasks.
▪ Plan Release.
▪ Develop/Integrate/Test Software
▪ Release Software
▪ Evaluate System
Extreme programming practices
Incremental planning: We break down the product into stories then we start to plan based on these stories.
Small releases: Every two weeks we deliver the product to the client.
Simple design: Enough design is carried out to meet the current requirements and no more.
Test-first development: We test while we’re developing.
Refactoring: To improve the quality of the code.
Pair programming: Developers work in pairs, checking each other’s work and providing the support to always do a good job.
Collective ownership: Working together on all areas of the system.
Continuous integration: As soon as the work on a task is complete, it is integrated into the whole system.
Sustainable pace: Working too much overtime isn’t ideal since it often leads to lower quality code.
On-site customer: The customer who is involved, needs to be available all the time to work with the XP Team.
Refactoring
▪ Improving the quality of the code, not changing the functionality.
▪ Changes are easier to made.
▪ Reduces the need for documentation.
Testing in XP / Testing Features
The program is tested after every
change has been made.
XP testing features:
▪ Test-first development (writing tests before code)
▪ User involvement in test development and validation.
▪ All previous and new tests are run automatically when new functionality is added.
Test automation
When tests are created as computer programs before the actual task is done.
