Agile Methods Of Software Development

3y ago
3.13 MB
88 Pages
Last View : 2d ago
Last Download : 3m ago
Upload by : Nadine Tse

Agile Methods of Software Development .pptxDr J Paul Gibson, Dept. LOR,TSP, Evry, FranceOctober 2011J Paul Gibson: Agile Methods1

Structure of thePresentation1. Software Process and theSoftware Life CycleSecondary SourcesI Source Texts/ ReferencesGeetesh Bajaj. 2005. CuttingEdge Powerpoint forDummies. For Dummies.2. History of Agile: More orless a process?II Quotes3. Agile Fundamentals“PowerPoint makes us stupid.”Gen. James N. Mattis,US Marine werpoint.html4. Comparing Agile MethodsIII Videos (youtube)5. Agile Resources6. Current Agile ResearchOctober 2011Boring Powerpoint (0:52) ZVFcagL1nsAJ Paul Gibson: Agile Methods2

1.Software Process and the Software Life CycleHow important is a software development process?". the quality of thepeople on a project, andtheir organization andmanagement, are muchmore important factorsin the success than arethe tools they use or thetechnical approachesthey take."Frederick P.Brooks, 1995, TheMythical Man-Month:Essays on SoftwareEngineeringOctober 2011J Paul Gibson: Agile Methods3

1.Software Process and the Software Life CycleWhy Do Software Projects Fail (Often) ?Most often it is because of: A failure to properly manage the risks Building the wrong thing Being blinded by technologyGrady Booch.1995. ObjectSolutions:Managing theObject-OrientedProject. AddisonWesley LongmanPublishing Co.,Adopting a good software process & life cycle will help address these failure modes.Adopting a good software process & life cycle does not guarantee success.We can never have a completely rational development processOctober 2011J Paul Gibson: Agile Methods4

1.Software Process and the Software Life CycleFailure to Properly Manage The RisksAs projects progress, they often seem to lose their way: Unrealistic schedules and plans are drawn up No-one has the nerve to stand up and acknowledge reality Many problems are viewed as ‘a simple programming matter’, evenwhen they are process or architecture concerns Project direction is set by the most ‘stubborn’ participants because it iseasier for management to let these people have their way. Free fall --- No one takes responsibility and everyone waits for theimpact. Petty empires form issues become politicalOctober 2011J Paul Gibson: Agile Methods5

1.Software Process and the Software Life CycleFailure from Building the Wrong ThingProjects can also lose their way because they go adrift in completelyuncharted territory: There is no shared vision of the problem being solved. The (development) team is clueless as to the final destination No-one takes time to validate what is being built with end-users ordomain experts Analysts understand the real requirements, but for a number ofpolitical/social reasons, this understanding never reaches thedesigners/implementers A false air of understanding pervades the project. Everyone will be shocked when users reject the delivered software. This is known as working in a vacuum.October 2011J Paul Gibson: Agile Methods6

1.Software Process and the Software Life CycleFailure from Being Blinded By TechnologyDon’t be blinded by the technology being used to build the software itself: Tools can break (be erroneous) be ready for it Project complexity can grow exponentially can your tools scale upaccordingly? Third-party suppliers of new technology often do not deliver on promises(if at all) Hardware advances can out-run software development Technology can fuel changes to users’ expectations New languages/tools/methods are prone to premature adoptionOctober 2011J Paul Gibson: Agile Methods7

1.Software Process and the Software Life CycleProject Styles --- providing a focus --- moving towards a processThere are many different ways of balancing project characteristics. Certain stylesare commonly seen in most industrial projects. These styles correspond to thedrive towards a certain focus: Calendar-driven Requirements-driven Documentation-driven Architecture-driven Quality-drivenOctober 2011J Paul Gibson: Agile Methods8

1.Software Process and the Software Life CycleWhat is the Software Process?A process is a systematic approach performed to achieve a specificpurpose.A software process is the set of activities, methods, practices, andtransformations used to develop software and associated products thatare released with it.Software Process Capability is the range of expected results that areachievable by following the software process.Software process performance is the actual result achieved in thedevelopment of software by following a software process.Software Process Maturity is the extent to which a Software Process isdefined, managed, controlled, measured and effective.October 2011J Paul Gibson: Agile Methods9

1.Software Process and the Software Life CycleNo process is perfectEven the most successful projects seem totake longer, involve more effort, andrequire more crisis management than wereally believe they ever should. We mustnever rely on the process pulling a projectthrough. The process can never becompletely rational:Parnas, D. and Clements, P.1986. A Rational Design Process:How and why to Fake It. IEEETransactions on SoftwareEngineering vol. SE-12(2) p251 Users typically don’t know what they want Users typically can’t express what they want Requirements are incomplete and/or change Implementation architectures change We all bring intellectual/technological baggage to projects Systems built by humans are always subject to human error Fundamental limits to the amount of complexity which can be handledOctober 2011J Paul Gibson: Agile Methods10

1.Software Process and the Software Life CycleWhat is the Software Life Cycle?The software life cycle is the collection of phases through which a software productpasses from initial conception through to retirement from service. Every software product has a life cycle. Life cycles used to be typically quite long—some software productshave been “alive” for 30 years. Life cycles are shortening due to technological advancesLife Cycle Phases - Implicitly or explicitly, all software products go through at least thefollowing phases: Requirements—determine customer needs and product constraints Design—determine the structure/organisation of the software system Coding—write the software Testing—exercise the system to find and remove defects Maintenance—correct and enhance product after customer deploymentOctober 2011J Paul Gibson: Agile Methods11

1.Software Process and the Software Life CycleSoftware Life Cycle ModelsA process is a collection of activities, with well-defined inputs and outputs, foraccomplishing some task.A life cycle model is a description of a process for carrying a software product throughall or part of its life cycle. Life cycle models tend to focus on major life cycle phases and theirrelationships to one another. Recent work on software processes has examined many aspects ofdevelopment and maintenance in great detail. A life cycle model is a software process description, but the term lifecycle model predates recent discussions of software processes.October 2011J Paul Gibson: Agile Methods12

1.Software Process and the Software Life CycleLife Cycle Models and the Software ProcessThe core of any software project is the coding ---architecture, abstraction, implementationLife cycle models revolve around this core --- how does the software evolve as the projectprogresses?All life-cycle models are based on the simple idea of feedback --- synthesis and analysis aremutually defined and recursively interdependent.The differences between the life-cycle models lie in the ways in which the feedback isorganised, for example: Trial and error Exploratory Programming The Waterfall Model Iterative Feedback Model Prototyping Test-Driven Design/Model-Driven AgileOctober 2011J Paul Gibson: Agile Methods13

1.Software Process and the Software Life CycleTrial and Error : “Hacking” The most primitive life cycle model is trial and error, sometimes called build-and-fix orhack-and-foist In this life cycle model, the first version of the system is built without planning,documentation, or control If the product is accepted, the developers face an interminable period of confusion,frustration, and drudgery fixing an endless stream of problemsThe feedback can be very primitive --- will we accept the first and only version ofthe system (yes/no)October 2011J Paul Gibson: Agile Methods14

1.Software Process and the Software Life CycleExploratory ProgrammingA bit better than trial-and-error (but not much): it establishes feedback before delivery to customer it allows multiple feedback it separates specification from implementationOctober 2011J Paul Gibson: Agile Methods15

1.Software Process and the Software Life CycleThe Waterfall Model (dominated the 70’s)The waterfall model is the oldest life cycle model; is was proposed byWinston Royce in 1970.This model is called a waterfall because it is usually drawn with acascade of activities through the phases of the life cycle “downhill”from left to right: analysis, requirements, specification, design,implementation, testing, maintenanceThere are many versions of the waterfall model: the phases/activities can be structured to different levelsof detail the feedback can be more or less flexibleOctober 2011J Paul Gibson: Agile MethodsW. W. Royce. 1987.Managing thedevelopment of largesoftware systems:concepts andtechniques. InProceedings of the9th internationalconference onSoftware Engineering(ICSE '87). IEEEComputer SocietyPress, 328-338.(Reprinted fromProceedings, IEEEWESCON, August1970, pages 1-9.)16

1.Software Process and the Software Life CycleLife Cycle Chaos - A Complete Feedback Graph Between ionTestingQuestion: Why not just reducethe number of activities tomanage the complexity?October 2011J Paul Gibson: Agile Methods17

1.Software Process and the Software Life CycleLife Cycle Ideal - (Strict) Waterfall With No FeedbackQuestion: Why not have a completelydeterministic process path?October 2011J Paul Gibson: Agile Methods18

1.Software Process and the Software Life CycleNon-strict Waterfall ModelAlthough the waterfall model stresses a linear sequence of phases, in fact there is inpractice always an enormous amount of iteration back to earlier phases, a pointmade by the arrows leading back up the waterfall, in the following diagram.Note: In this variation, feedback is only from testing phase to any previous stageOctober 2011J Paul Gibson: Agile Methods19

1.Software Process and the Software Life CycleIterative Feedback ModelLike the non-strict waterfall method except that feedback is allowed from any phaseto the previous phase.Note that we can still jump anywhere from testing!Question: why not add even more feedback?October 2011J Paul Gibson: Agile Methods20

1.Software Process and the Software Life CycleAnalysis of waterfall methodStrengths: Emphasises completion of one phase before moving on Emphasises early planning, customer input, and design Emphasises testing as an integral part of the life cycle Provides quality gates at each life cycle phaseWeaknesses: Depends on capturing and freezing requirements early in the life cycle Depends on separating requirements from design Not politically feasible in some organisations Emphasises products rather than processesOctober 2011J Paul Gibson: Agile Methods21

1.Software Process and the Software Life CycleAway From WaterfallDaniel D. McCracken and Michael A. Jackson. 1982. Life cycle concept consideredharmful. SIGSOFT Softw. Eng. Notes 7, 2 (April 1982), 29-32.“Any form of life cycle is a project managementstructure imposed on system development. Tocontend that any life cycle scheme, even withvariations, can be applied to all systemdevelopment is either to fly in the face of reality orto assume a life cycle so rudimentary as to bevacuous.""The life cycle concept is simply unsuited to the needs of the1980‘s in developing systems."October 2011J Paul Gibson: Agile Methods22

1.Software Process and the Software Life CyclePrototyping Models (become popular in the 80’s)A prototype is a working model of (part of) a final systemPrototyping is becoming more popular all the time, and people often refer to prototypesin. the literature.Unfortunately, a variety of terminology is used, so it is often difficult to tell what is meantwhen people discuss prototyping.Note there are different types of prototyping model, with different characteristics, eg: Rapid Prototyping Evolutionary Prototyping Operational PrototypingMaryam Alavi. 1984. An assessment of theprototyping approach to informationsystems development. Commun. ACM 27, 6(June 1984), 556-563.R. N. Burns and A. R. Dennis. 1985.Selecting the appropriate applicationdevelopment methodology. SIGMISDatabase 17, 1 (September 1985), 19-23October 2011J Paul Gibson: Agile Methods23

1.Software Process and the Software Life CycleFrom Waterfall to Spiral (dominates the 90’s)B. Boehm, “A SpiralModel of SoftwareDevelopment andEnhancement,”Computer, May 1988, pp.61-72.October 2011J Paul Gibson: Agile Methods24

1.Software Process and the Software Life CycleAgile: A lightweight alternative to heavy-weight waterfall-like processes?Claim:With heavyweightprocesses, there istoo much emphasison analysis anddesigndocumentation.Agile is lightweight.It combinesprototyping andtest-basedprocesses: wherethere is continualdevelopment ofcode and continualvalidation ofcustomerrequirementsOctober 2011J Paul Gibson: Agile Methods25

2. History of Agile: More or less a process?The History of Agile Methods:what can we learn?October 2011J Paul Gibson: Agile Methods26

2. History of Agile: More or less a process?History of Agile:Where Did itCome From?Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, and JussiRonkainen. 2003. New directions on agile methods: a comparativeanalysis. In Proceedings of the 25th International Conference onSoftware Engineering (ICSE '03). IEEE Computer Society, Washington,DC, USA, 244-254.19902000October 2011J Paul Gibson: Agile Methods27

2. History of Agile: More or less a process?History of AgileAgile software development isn’t a set of tools or a single methodology,but a philosophy put to paper in 2001 with an initial 17 signatories.Agile was a significant departure from the heavyweight document-drivensoftware development methodologies—such as waterfall—in general useat the time.While the publication of the “Manifesto for Agile Software Development”didn’t start the move to agile methods, which had been going on forsome time, it did signal industry acceptance of agile philosophy."Many people may think that agile is just another software development process.Although that is true to a degree, there is a lot more to agile than just a process orjust a set of practices. Agile (or agility) is more of a mindset - a way of thnkingabout software development."Greg Smith, Ahmed Sidky, 2009, Becoming Agile: .in an imperfect worldOctober 2011J Paul Gibson: Agile Methods28

2. History of Agile: More or less a process?Manifesto for Agile Software Development are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value: Individuals and interactions Working software Customer collaboration Responding to changeoveroveroveroverprocesses and toolscomprehensive documentationcontract negotiationfollowing a planThat is, while there is value in the items onthe right, we value the items on the left more.Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerOctober 2011James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave ThomasJ Paul Gibson: Agile Methods29

2. History of Agile: More or less a process?Kent Beck: Industrial experience with design patterns. ICSE 1996, IEEE Computer Society. Embracing Change with Extreme Programming, 1999, IEEE Computer. Test Driven Development: By Example. 2002 Addison-Wesley.Mike Beedle & Ken Schwaber: Agile Software Development with Scrum , 2001, Prentice Hall.Arie van BennekumAlistair Cockburn : Writing Effective Use-Cases, 2000, Addison-Wesley. The Costs and Benefits of Pair Programming, In Extreme programming examined,Giancarlo Succi and Michele Marchesi (Eds.)., 2001, Addison-Wesley Longman PublishingWard Cunningham & KB:A laboratory for teaching object oriented thinking, SIGPLAN Not. 24, 10 (September 1989)Martin Fowler Refactoring: Improving the Design of Existing Code, 1999, Addison-Wesley.October 2011J Paul Gibson: Agile Methods30

2. History of Agile: More or less a process?James Grenning: Launching Extreme Programming at a Process-Intensive Company, 2001, IEEE Softw. 18Jim Highsmith and Alistair Cockburn: Agile Software Development: The Business of Innovation, 2001, Computer 34,Andrew HuntRon Jeffries and Grigori Melnik: TDD--The Art of Fearless Programming, 2007, IEEE Softw. 24, 3Jon KernBrian Marick: The Craft of Software Testing: Subsystem Testing Including Object-Based and ObjectOriented Testing. Prentice-Hall, 1994. When Should a Test Be Automated?, 1998.October 2011J Paul Gibson: Agile Methods31

2. History of Agile: More or less a process?Robert C. Martin: SoapBox - eXtreme Programming Development through Dialog, IEEE Software 17, 2000 Professionalism and Test-Driven Development. IEEE Software 24(3), 2007Steve Mellor: An object-oriented approach to domain analysis. SIGSOFT Softw. Eng. Notes 14, 5, 1989 Make models be assets. Commun. ACM 45(11): 76-78, 2002.Jeff Sutherland: Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies, Cutter IT Journal,2001 Agile development: Lessons learned from the first scrum, Cutter IT Journal, 2004 Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. AGILE 2005: 90-102Dave Thomas: Orwell: a configuration management system for team programming. In OOPSLA’88. Model driven development: the case for domain oriented programming. In OOPLSA’03. MDA: Revenge of the Modelers or UML Utopia?, IEEE Software, 21(3) , 2004 Agile Programming: Design to Accommodate Change. IEEE Software 22(3), 2005October 2011J Paul Gibson: Agile Methods32

2. History of Agile: More or less a process?Agile: Values, Principles and MethodsOctober 2011J Paul Gibson: Agile Methods33

2. History of Agile: More or less a process?Agile: 12 Principles1. Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software.2. Welcome changing requirements, even late in development. Agile processesharness change for the customer's competitive advantage.3. Deliver working software frequently, from a couple of weeks to a couple ofmonths, with a preference to the shorter timescale.4. Business people and developers must work together daily throughout theproject.5. Build projects around motivated individuals. Give them the environment andsupport they need, and trust them to get the job done.6. The most efficient and effective method of conveying information to and withina development team is face-to-face conversation.October 2011J Paul Gibson: Agile Methods34

2. History of Agile: More or less a process?Agile: 12 Principles7. 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-organizingteams.12. At regular intervals, the team reflects on how to become more effective, thentunes and adjus

Software Process Capability is the range of expected results that are achievable by following the software process. 1. Software Processand the Software Life Cycle October 2011 J Paul Gibson: Agile Methods Software process performance is the actual result achieved in the development of software by following a software process.

Related Documents:

1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.

The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .

1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18

Agile Manifesto (Agile Principles) The Agile Manifesto is the foundation of most Agile Software Development methods. It has 4 core values supplemented by 12 Principles. The document was developed in 2001 by a group of 17 pioneer software engineers ( Agile Software Development Methods Agile Software .

2. Quality Assurance AND Methods of Agile 3. Metrics of quality AND Agile quality assurance 4. Agile AND Quality 5. Agile Quality AND Software Development 6. Agile quality AND Agile methods The search keywords for agile particulars have been merged by using the Boolean ''OR" operator, which

Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.

Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .

1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma