Software

Engineering
AGILE SOFTWARE ENGINEERING
Plan Driven Problems
•Rapid development and delivery is now often the most important requirement for
software systems in todays world
•Plan-driven development involves significant overheads and documentation and it does
not support the rapid development and delivery of software.
•Software has to evolve quickly to reflect changing business needs
•Plan-driven development evolved to support the engineering of large, long-lifetime
systems (such as aircraft control systems) where teams may be geographically
dispersed and work on the software for several years.
•This approach is based on controlled and rigorous software development processes
that include detailed project planning, requirements specification and analysis and
system modelling.
•These issues led to a number of software developers in the 1990s to propose new ‘agile
methods’
What is Agile?
•Agile software engineering focuses on delivering functionality quickly,
responding to changing product specifications and minimizing development
overheads.
•Software products must be brought to market quickly so rapid software
development and delivery is essential.
•Virtually all software products are now developed using an agile approach.
What is Agile?
•Effective (rapid and adaptive) response to change (team members, new
technology, requirements)
•Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers
•Drawing the customer into the team. Eliminate “us and them” attitude. Planning
in an uncertain world has its limits and plan must be flexible
•Organizing a team so that it is in control of the work performed
•Eliminate all but the most essential work products and keep them lean
•Emphasize an incremental delivery strategy as opposed to intermediate
products that gets working software to the customer as rapidly as feasible
Manifesto for Agile 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.”

-Kent Beck et al
Agile Methods
•Best Known Agile Methods:
• extreme programming
• Scrum
• Adaptive Software Development
• Feature Driven Development
•These agile methods are all based around the notion of incremental
development and delivery, they propose different processes to achieve this
•However, they share a set of principles, based on the agile manifesto
Agility Principles in Detail
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.
Incremental Development
•All agile methods are based around incremental development and delivery
•Product development focuses on the software features, where a feature does
something for the software user.
•With incremental development, you start by prioritizing the features so that the
most important features are implemented first.
•Users or surrogate users can try it out and provide feedback to the development
team. You then go on to define and implement the next feature of the system.
•Choose features to be included in an increment: Using the list of features in the
planned product, select those features that can be implemented in the next
product increment.
•Refine feature descriptions: Add detail to the feature descriptions so that the
team have a common understanding of each feature and there is sufficient
detail to begin implementation.
•Implement and test: Implement the feature and develop automated tests for
that feature that show that its behaviour is consistent with its description.
•Integrate feature and test: Integrate the developed feature with the existing
system and test it to check that it works in conjunction with other features.
•Deliver system increment: Deliver the system increment to the customer or
product manager for checking and comments. If enough features have been
implemented, release a version of the system for customer use.

Remember our focus on the core Agile principles!

Extreme Programming (XP)
•The most influential work that has changed software development culture was
the development of Extreme Programming (XP).
•The name was coined by Kent Beck in 1998 because the approach was
developed by pushing recognized good practice, such as iterative development,
to ‘extreme’ levels.
•Extreme programming focused on 12 new development techniques that were
geared to rapid, incremental software development, change and delivery.
•Some of these techniques are now widely used; others have been less popular.
Extreme Programming (XP)
Practices
Extreme Programming (XP)
Values
Agile Methods Applicability
Agile methods have been very successful for
•Product development where a software company is developing a small or
medium-sized product for sale.
•Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development
process and where there are not a lot of external rules and regulations that
affect the software.
•Because of their focus on small, tightly-integrated teams, there are problems in
scaling agile methods to large systems
Human Factors
the process molds to the needs of the people and team, not the other way
around
key traits must exist among the people on an agile team and the team itself:
◦ Competence. ( talent, skills, knowledge)
◦ Common focus. ( deliver a working software increment )
◦ Collaboration. ( peers and stakeholders)
◦ Decision-making ability. ( freedom to control its own destiny)
◦ Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may
not be tomorrow’s problem)
◦ Mutual trust and respect.
◦ Self-organization. ( themselves for the work done, process for its local environment,
the work schedule)
Agility and the Cost of Change
•Conventional wisdom is that the cost of change increases nonlinearly as a
project progresses
• if the middle of validation testing, a stakeholder is requesting a major
functional change. Then the change requires a modification to the
architectural design, construction of new components, changes to other
existing components, new testing and so on. Costs escalate quickly

•A well-designed agile process may “flatten” the cost of change curve by coupling
incremental delivery with agile practices such as continuous unit testing and pair
programming. Thus team can accommodate changes late in the software project
without dramatic cost and time impact
Problems
•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
•Many organizations, especially large companies, have spent years changing their
culture so that processes are defined and followed
•Contracts may be a problem as with other approaches to iterative development.
Plan Driven & Agile
•Agile approaches to software development consider design and implementation
to be the central activities in the software process
•They incorporate other activities, such as requirements elicitation and testing,
into design and implementation
•A plan-driven approach to software engineering identifies separate stages in the
software process with outputs associated with each stage
Plan Driven & Agile
•In a plan-driven approach, iteration occurs within activities with formal
documents
•E.g. A requirements specification will be produced in the initial step and it will
be used as input to the design and implementation process
•In an agile approach, iteration occurs across activities
•I.e. the requirements and the design are developed together, rather than
separately
Should You Implement Agile?
Most projects include elements of plan-driven and agile processes. Deciding on
the balance depends on
•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, where you deliver the software to customers
and get rapid feedback from them, realistic?
• If so, consider using agile methods
•How large is the system that is being developed?
• Agile methods are most effective when the system can be developed with a small co-
located team who can communicate informally. This may not be possible for large
systems that require larger development teams so a plan-driven approach may have
to be used

•What type of system is being developed?

• Plan-driven approaches may be required for systems that require a lot of analysis
before implementation (e.g. real-time system with complex timing requirements)
•What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to communicate the
original intentions of the system developers to the support team
•What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving design
•How is the development team organized?
• If the development team is distributed or if part of the development is being
outsourced, then you may need to develop design documents to communicate across
the development teams
•Are there cultural or organizational issues that may affect the system
development?
• Traditional engineering organizations have a culture of plan-based development, as
this is the norm in engineering
•How good are the designers and programmers in the development team?
• It is sometimes argued that agile methods require higher skill levels than plan-based
approaches in which programmers simply translate a detailed design into code
•Is the system subject to external regulation?
• If a system has to be approved by an external regulator then you will probably
be required to produce detailed documentation as part of the system safety
case