DOCSLIB.ORG

A & D Modeling Need for Updating Diagrams Rapidly, 232 Actors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A & D Modeling Need for Updating Diagrams Rapidly, 232 Actors 4649_Ch13_Index_FINAL 1/17/05 9:33 AM Page 253 Index ■A planning, 73 A & D modeling recapping, 74 need for updating diagrams rapidly, 232 refactoring values, 73 actors requirements analysis, 73 overview, 43 website, 6 using interaction design to identify, 196 Agile Modeling. See AM AD (Agile Database Techniques), 18 agile planning, 67 adaptive planning adaptive planning, 176 agile projects and, 10 estimating, 177–178 estimating, 177–178 Gantt charts, 181–182 Gantt charts, 181–182 prioritizing requirements, 176 prioritizing requirements, 176 release planning, 178 release planning, 178 timeboxing, 180–181 timeboxing, 180–181 tracing requirements back to goals, 181 tracing requirements back to goals, 181 tracking project velocity, 179 tracking project velocity, 179 fitting iterative and incremental planning together, adaptive planning, 176 175 Adaptive Software Development, 18 phases AddHotels() method analysis and design, 183 AOI class, 161 construction, 184 ADF (Application Developer Framework), 100, 114 inception, 183 aggregation relationships, 135 planning for agility, 176 aggressive testing, 66 principles, 184 Agile Database Techniques, 18 costing and benefits of incremental development, Agile ICONIX 187 See also ICONIX Process. costing changes, 187 and TDD, 227 feedback, 185 compared to other agile methods, 174 release sizes, 187 core subset of agile practices, 61 release types, 186 agile practices, 64–69 software rot, 186 agile values, 69–71 types of plan, 184 ICONIX Process practices, 63 reasons for, 173 introduction, 61 flexibility and perception, 173 why define, 61 tracking defects and feature requests, 174 driving the code from the model, 146 terminology, 175 introduction, 4 agile practices, 64 mapplet project, 87 aggressive testing, 66 ArcGIS Server, 99 agile planning, 67 architecture, 96 domain analysis, 65 first release plan, 98 frequent integration, 67 goals, 92 frequent small releases, 67 introduction, 89–90 interaction design, 66 JumpStart workshop, 95 optimizing team communication, 68 requirements, 92 prefactoring/model-driven refactoring, 66 use case modeling, 97 requirements analysis and disambiguation, 65 overview, 21 responsible ownership/collective responsibility, 68 synchronizing source code and model, 123 short iterations, 69 Agile Manifesto synchronizing model and code, 67 core subset of agile practices, based on, 62 Agile Software Development goals, 62 Cockburn, Alistair, 31–32 refactoring agile values, 71 agile values contract negotiation, 72 communication, 70 documentation, 72 early feedback, 70 need for flexible processes and tools, 72 judgement and balance, 71 simplicity, 70 253 4649_Ch13_Index_FINAL 1/17/05 9:33 AM Page 254 254 ■INDEX agility ■B Agile Manifesto website, 6 BCE (Boundary-Control-Entity) as philosophy of software development, 27 robustness analysis stereotypes, 49 challenges, 11–13 behavioral requirements, defining, 47 change and change management, 78 Belbin, Dr. R. Meredith custumor and contract-related issues, 79 team-player classification, 31 definitions of agile projects, 8–11 Better Software Faster goals, 6 Carmichael, Andy and Haywood, Dan, 178 importance of, 7 Big Design Up Front introduction, 3 and TDD, 227 methodologies, 13 Boehm, Barry Adoptive Software Development, 18 Get Ready for Agile Methods, with Care, 25 Agile Database Techniques, 18 Booch method Agile Modeling, 16–17 Grady Booch, 40 Crystal Methodologies, 18–19 Booking class DSDM (Dynamic Systems Development Method), creating, 214 19 getID() method, 216 FDD (Feature-Driven Development), 20–21 toString() method, 216 Scrum, 19 updating for test, 216 TDD (Test-Driven Development), 16 bookingListsByCustomer HashMap XP (Extreme Programming), 14–16 adding to BookingManager class, 219 modeling and documentation, 75–78 BookingManager class myths and misconceptions, 22 adding bookingListsByCustomer HashMap, 219 planning and design, 83–85 as Singleton, 215 software agility, 5 clearAll method, 215 hacking, 5 createBooking method, 214 high ceremony, 5 findBooking() method, 217, 220 low levels of communication, 5 modifying, 216 requirement gathering and design, 5 numBookings() method, 218 transparency, 5 placeBooking method, 214 working practices, 80–82 updating for test, 216 AM (Agile Modeling), 203 BookingManagerDOA class communication and team work, 9 persisting data, 223 design review, 123 BookingManagerTest class overview, 16 testing for bookings for more than one customer, 219 practices, 17 testing for nothingness, 212 traveling light, 146 boundary types when to keep code and model tightly interwoven, as nouns on robustness diagrams, 231 146 Display Rollover Information use case, 129 analysis and design robustness analysis stereotypes, 49 bridging gap between, 54 Boundary-Control-Entity, 49 analysis modeling practices Browse by US Map use case, 153, 156 description, 57 build by feature, 21 analysis-level modeling, 40 BuildRolloverInfo() method AOI class HotelCluster class, 143 AddHotels() method, 161 Application Developer Framework. 100, 114 ■C ArcGIS Server, 104 CalcNewExtent method achitectecture, 96 MapViewer object, 116 ArcObjects, 96 Carmichael, Andy and Haywood, Dan figuring out new release of, 103 Better Software Faster, 178 installing, 114 change management, 11–12, 78 introduction, 90 changing software requirements leveraging out-of-the-box functionality, 92 reducing exposure to, 10 terminology, 100 checkCustomerNameUnique() method web controls, 114 Customer class, 244 ArcGIS Software Developer Kit, 99 class diagrams, 41 ArcObjects, 91, 96 designing Release 2, 159 AreaOfInterestViewer class, 118 feeding changes back into, 143 ASD (Adaptive Software Development), 18 product of analysis and design level refactorings, 136 Astels, David refactored class diagram, 146 Test-Driven Development colon A Practical Guide, 227 clearAll method automated tests BookingManager class, 215 agile development and, 80 4649_Ch13_Index_FINAL 1/17/05 9:33 AM Page 255 ■INDEX 255 clearCustomers() method customer-visible production release Database class, 247 incremental planning, 186 Cockburn, Alistair CustomerDetailsPage JSP page Agile Software Development, 31–32 sequence diagram, 238 Crystal Methodologies website, 18 CustomerDetailsValidatorTest class Writing Effective Use Cases, 195 creating, 234 code and design running test, 236–237 converging or diverging, 160 CustomerManager class coding by intention, 141 making class do something, 211 coding standards CustomerManagerTest class XP (Extreme Programming), 16 testing for nothingness, 206–208 collective ownership CustomerNotFoundTest XP (Extreme Programming), 15 passing test in JUnit TestRunner, 212 communication, 70 customers involvement in design, 12 as aspect of software development process, 27 completeness check ■D essential role of robustness analysis, 54 Database class Composite pattern clearCustomers() method, 247 Display Rollover Information, using, 135 implementing, 245 object discovery, 127 defects, Severity assigned, 174 composition relationships, 135 deliverables, Release 1, 103 concepts, proving in code as working software, 77 design continuous integration bridging gap between analysis and design, 54 XP (Extreme Programming), 15 by feature, 21 contract negotiation enhancing agility through, 8–9 gaining customer collaboration, 72 ICONIX Process compared to TDD, 203 control objects refactoring, 83–84 robustness analysis stereotypes, 49 simplicity of and XP (Extreme Programming), 15 controller code upfront design, 84 benefit of separation from presentation model in design modeling practices, 57 TDD, 205 design review controllers as verbs, 231 as code and design review, 123 cookbook-style process, 130 class diagram, 136 Create a Hotel Booking for a Customer use case, 229 Display Rollover Information use case use case diagram, 230 robustness diagram, 125–130 Create a New Customer use case sequence diagram, 130–135 revising text, 231 fine-tuning diagram, 128 robustness diagram, 230 nouns, 127 corrected version, 232 detailed design class modeling, 40 sequence diagram, 233 detailed release plan Create New Customer use case, 228 principles of agile planning, 185 createBooking method development tools BookingManager class, 214 agile development and, 76 CreateCustomerDetails controller class disambiguation, 41, 63, 65 modifying, 244 bridging gap between analysis and design, 54 unit testing, 239–242 description, 56 CreateCustomerDetailsTest class domain model, 53 setUp() method, 247 robustness analysis, 54 unit testing, 243–245 use cases, 48 critical design review, 51 Display Rollover Information use case, 111 Crystal Methodologies, 18-19 Composite pattern, 135 Alistair Cockburn’s website, 18 renaming as Show Hotel Info Pop-up, 127 customer acceptance testing, 10 robustness diagram, 112 customer and contract-related issues decluttering diagram, 125 agile development and, 79 disambiguating diagram, 126 Customer class final version, 129 adding properties, 235 fine-tuning diagram, 128 checkCustomerNameUnique() method, 244 revisiting, 125 customer collaboration sequence diagram, 112 gaining through contract negotiation, 72 first refactoring, 131-132 customer feedback, Release 1, 149 revisiting, 130 customer-visible investigative release second refactoring, 133 incremental planning, 186 4649_Ch13_Index_FINAL 1/17/05 9:33 AM Page 256 256 ■INDEX DisplayWindowText() method giving, 32 Hotel class, 140 neccessity of early feedback, 70 documentation test-driven requirements feedback, 33 agile development and, 75–76 Filter Hotels use case, 155 Doing The Simplest Thing That Could Possibly Work.
Load more

Recommended publications
  • Title of the Article: Agile Software Development Methods: a Comparative Review1
    Title of the article: Agile Software Development Methods: A Comparative Review1 Authors: Pekka Abrahamsson, Nilay Oza, Mikko T. Siponen Notes: This is the author's version of the work. The definite version was published in: Abrahamsson P., Oza N., Siponen M.T. (2010) Agile Software Development Methods: A Comparative Review1. In: Dingsøyr T., Dybå T., Moe N. (eds) Ag- ile Software Development. Springer, Berlin, Heidelberg Copyright owner’s version can be accessed at https://link.springer.com/chapter/10.1007/978-3-642-12575-1_3 This is the author's version of the work. Copyright owner’s version can be accessed at https://link.springer.com/chapter/10.1007/978-3-642-12575-1_3. Agile Software Development Methods: A Comparative Review1 Pekka Abrahamsson, Nilay Oza and Mikko T. Siponen Abstract: Although agile software development methods have caught the attention of software engineers and researchers worldwide, scientific re- search still remains quite scarce. The aim of this study is to order and make sense of the different agile approaches that have been proposed. This comparative review is performed from the standpoint of using the fol- lowing features as the analytical perspectives: project management sup- port, life-cycle coverage, type of practical guidance, adaptability in actual use, type of research objectives and existence of empirical evidence. The results show that agile software development methods cover, without offer- ing any rationale, different phases of the software development life-cycle and that most of these methods fail to provide adequate project manage- ment support. Moreover, quite a few methods continue to offer little con- crete guidance on how to use their solutions or how to adapt them in dif- ferent development situations.
    [Show full text]
  • Agile Processes in Software Engineering and Extreme
    Juan Garbajosa · Xiaofeng Wang Ademar Aguiar (Eds.) Agile Processes in Software Engineering and Extreme Programming LNBIP 314 19th International Conference, XP 2018 Porto, Portugal, May 21–25, 2018 Proceedings Lecture Notes in Business Information Processing 314 Series Editors Wil M. P. van der Aalst RWTH Aachen University, Aachen, Germany John Mylopoulos University of Trento, Trento, Italy Michael Rosemann Queensland University of Technology, Brisbane, QLD, Australia Michael J. Shaw University of Illinois, Urbana-Champaign, IL, USA Clemens Szyperski Microsoft Research, Redmond, WA, USA More information about this series at http://www.springer.com/series/7911 Juan Garbajosa • Xiaofeng Wang Ademar Aguiar (Eds.) Agile Processes in Software Engineering and Extreme Programming 19th International Conference, XP 2018 Porto, Portugal, May 21–25, 2018 Proceedings Editors Juan Garbajosa Ademar Aguiar Technical University of Madrid University of Porto Madrid, Madrid Porto Spain Portugal Xiaofeng Wang Free University of Bozen-Bolzano Bolzano Italy ISSN 1865-1348 ISSN 1865-1356 (electronic) Lecture Notes in Business Information Processing ISBN 978-3-319-91601-9 ISBN 978-3-319-91602-6 (eBook) https://doi.org/10.1007/978-3-319-91602-6 Library of Congress Control Number: 2018944291 © The Editor(s) (if applicable) and The Author(s) 2018. This book is an open access publication. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
    [Show full text]
  • Software Development: Agile Vs
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Directory of Open Access Journals 64 Informatica Economică vol. 17, no. 4/2013 Software Development: Agile vs. Traditional Marian STOICA, Marinela MIRCEA, Bogdan GHILIC-MICU Bucharest University of Economic Studies, Romania [email protected], [email protected], [email protected] Organizations face the need to adapt themselves to a complex business environment, in continuous change and transformation. Under these circumstances, organization agility is a key element in gaining strategic advantages and market success. Achieving and maintaining agility requires agile architectures, techniques, methods and tools, able to react in real time to change requirements. This paper proposes an incursion in the software development, from traditional to agile. Keywords: Software Development, Traditional Models, Agile Models, Agile Architectures, Agile Techniques, Agile Instruments Introduction (SOA) for designing and developing such 1 Increased agility is a magnet to all functionalities and Decision Management organizations, especially for those in private (DM) for management of organization sector. It will allow a rapid and efficient decisions. adaptation to market changes and gaining a strategic advantage. Moreover, increased 2 Software Development Life Cycle agility contributes to decreasing the Development models are various processes development time for new processes and or methodologies, selected to develop the increasing flexibility for existing processes, project according to its purpose and where modification and implementation is objectives. Software developments models required. All that leads to decreased time for help improve the software quality as well as solving client demands, more clients gained, the development process in general.
    [Show full text]
  • Iterative, Evolutionary, and Agile
    UML and Patterns.book Page 17 Thursday, September 16, 2004 9:48 PM Chapter 2 2 ITERATIVE, EVOLUTIONARY, AND AGILE You should use iterative development only on projects that you want to succeed. —Martin Fowler Objectives G Provide motivation for the content and order of the book. G Define an iterative and agile process. G Define fundamental concepts in the Unified Process. Introduction Iterative development lies at the heart of how OOA/D is best practiced and is presented in this book. Agile practices such as Agile Modeling are key to apply- ing the UML in an effective way. This chapter introduces these subjects, and the Unified Process as a relatively popular sample iterative method. What’s Next? Having introduced OOA/D, this chapter explores iterative development. The next introduces the case studies that are evolved throughout the book, across three iterations. Iterative, OOA/D Case Evolutionary Inception Introduction & Agile Studies 17 UML and Patterns.book Page 18 Thursday, September 16, 2004 9:48 PM 2 – ITERATIVE, EVOLUTIONARY, AND AGILE Iterative and evolutionary development—contrasted with a sequential or “waterfall” lifecycle—involves early programming and testing of a partial sys- tem, in repeating cycles. It also normally assumes development starts before all the requirements are defined in detail; feedback is used to clarify and improve the evolving specifications. We rely on short quick development steps, feedback, and adaptation to clarify the requirements and design. To contrast, waterfall values promoted big up- front speculative requirements and design steps before programming. Consis- tently, success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects and was historically promoted due to belief or hearsay rather than statistically significant evidence.
    [Show full text]
  • The Agile Model-Driven Method
    University of Plymouth PEARL https://pearl.plymouth.ac.uk 04 University of Plymouth Research Theses 01 Research Theses Main Collection 2019 The Agile Model-Driven Method Mairon, Klaus http://hdl.handle.net/10026.1/15257 University of Plymouth All content in PEARL is protected by copyright law. Author manuscripts are made available in accordance with publisher policies. Please cite only the published version using the details provided on the item record or document. In the absence of an open licence (e.g. Creative Commons), permissions for further reuse of content should be sought from the publisher or author. THE AGILE MODEL-DRIVEN METHOD by KLAUS MAIRON A thesis submitted to the University of Plymouth in partial fulfilment for the degree of DOCTOR OF PHILOSOPHY School of Engineering, Computing and Mathematics October 2019 Copyright Statement This copy of the thesis has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the thesis and no information derived from it may be published without the author's prior consent. PhD Thesis ii Acknowledgements In the first place, I have to thank my family for their support during the preparation of this work. Without her patience and consideration, I would not have been able to coordinate the family, profession, and research. Another thanks to my employer, msg systems ag, and my manager Ralf Christmann. Only through the possibilities of reduction to part-time and the understanding of the resulting restrictions has this work become possible at all. A least as great gratitude my supervisors at the universities in Furtwangen and Plymouth.
    [Show full text]
  • Agile Software Development Methods: Review and Analysis
    ESPOO 2002 VTT PUBLICATIONS 478 VTT PUBLICATIONS 478 VTT PUBLICATIONS 457 Pakanen, Jouko & Karjalainen, Sami. An ARMAX-model approach for estimating static heat flows in buildings. A method for computerised energy allocation systems. 2002. 60 p. 458 Numerical treatment of inter-phase coupling and phasic pressures in multi-fluid modelling. 2002. 62 p. + app. 51 p. 459 Hakkarainen, Tuula. Studies on fire safety assessment of construction products. 2002. 109 p. + app. 172 p. 460 Shamekh, Salem Sassi. Effects of lipids, heating and enzymatic treatment on starches. 2002. 44 p. + app. 33 p. Agile software development methods. Review and analysis 461 Pyykönen, Jouni. Computational simulation of aerosol behaviour. 2002. 68 p. + app. 154 p. 462 Suutarinen, Marjaana. Effects of prefreezing treatments on the structure of strawberries and jams. 2002. 97 p. + app. 100 p. 463 Tanayama, Tanja. Empirical analysis of processes underlying various technological inno- vations. 2002. 115 p. + app. 8 p. 464 Kolari, Juha, Laakko, Timo, Kaasinen, Eija, Aaltonen, Matti, Hiltunen, Tapio, Kasesniemi, Eija-Liisa, & Kulju, Minna. Net in Pocket? Personal mobile access to web services. 2002. 135 p. + app. 6 p. 465 Kohti oppivaa ja kehittyvää toimittajaverkostoa. Tapio Koivisto & Markku Mikkola (eds.). 2002. 230 s. 466 Vasara, Tuija. Functional analysis of the RHOIII and 14-3-3 proteins of Trichoderma reesei. 93 p. + app. 54 p. 467 Tala, Tuomas. Transport Barrier and Current Profile Studies on the JET Tokamak. 2002. 71 p. + app. 95 p. 468 Sneck, Timo. Hypoteeseista ja skenaarioista kohti yhteiskäyttäjien ennakoivia ohjanta- järjestelmiä. Enna-kointityön toiminnallinen hyödyntäminen. 2002. 259 s. + liitt. 28 s. 469 Sulankivi, Kristiina, Lakka, Antti & Luedke, Mary.
    [Show full text]
  • Disciplined Agile Delivery (DAD): the Foundation for Scaling Agile
    Disciplined Agile Delivery (DAD): The Foundation for Scaling Agile Scott W. Ambler Chief Methodologist for Agile and Lean, IBM Rational www.ibm.com/developerworks/blogs/page/ambler twitter.com/scottwambler © 2012 IBM Corporation We hope that you find these slides useful. If you would like to discuss this topic further, please contact IBM. 1 2 Agenda 1 Agile Fundamentals 2 Disciplined Agile Delivery (DAD) 3 Agility at Scale 4 Parting Thoughts 2 © 2012 IBM Corporation 2 What is agile? Agile is a highly collaborative, evolutionary, quality focused approach to software development. How agile is different: –Focus on collaboration –Focus on quality –Focus on working solutions –Agilists are generalizing specialists –Agile is based on practice, not theory 3 © 2012 IBM Corporation Focus on collaboration: Less paperwork and more conversation Stakeholders actively involved Focus on quality: Have a full regression test suite for your systems Develop loosely-coupled, highly cohesive architectures Refactor to keep them this way Focus on working solutions: Greater feedback makes agile projects easier to manage Less documentation is required Less bureaucracy Agilists are generalizing specialists: Fewer hand offs between people Fewer people required Specialists find it difficult at first to fit into the team Agile is based on practice, not theory: This is a significant change from traditional You need to see how agile works in practice to truly understand it 3 Why agile? Higher success rates Iterative Agile Lean Ad-Hoc Traditional 0% 20% 40% 60% 80% 100% Successful Challenged Failed Source: DDJ 2011 IT Project Success Survey 4 © 2012 IBM Corporation Detailed results online at www.ambysoft.com/surveys/ Success as defined by the respondent (this is the same for all slides in this deck).
    [Show full text]
  • Disciplined Agile Delivery: an Introduction 2 Disciplined Agile Delivery: an Introduction
    IBM Software Thought Leadership White Paper Design and development Disciplined Agile Delivery: An introduction 2 Disciplined Agile Delivery: An introduction Make no mistake, agile is not a fad. When mainstream agile Unfortunately, we need to take adoption rate survey results with methods such as Scrum and Extreme Programming (XP) were a grain of salt: A subsequent Ambysoft survey found that only introduced, the ideas contained in them were not new, nor were 53 percent of people claiming to be on “agile teams” actually they even revolutionary at the time. In fact, many of them have were. It is clear that agile methods have been overly hyped by been described in-depth in other methods such as Rapid various media over the years, leading to abuse and misuse; in Application Development (RAD), Evo, and various instantiations fact, the received message regarding agile appears to have justi- of the Unified Process, not to mention classic books such as fied using little or no process at all. For too many project teams Frederick Brooks’ The Mythical Man Month. It should not be sur- this resulted in anarchy and chaos, leading to project failures and prising that working together closely in co-located teams and a backlash from the IT community that prefers more traditional collaborating in a unified manner towards a goal of producing approaches. working software produces results superior to those based on working in specialized silos concerned with individual rather Properly executed, agile is not an excuse to be undisciplined. It is than team performance. It should also come as no surprise that clear that the execution of mainstream agile methods such as XP reducing documentation and administrative bureaucracy saves have always demanded a disciplined approach, certainly more money and speeds up delivery.
    [Show full text]
  • Agile Modeling: Effective Practices for Extreme Programming and the Unified Process
    Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process Scott Ambler Wiley Computer Publishing John Wiley & Sons, Inc. 72244_FMI 2/27/02 11:34 AM Page iv 72244_FMI 2/27/02 11:34 AM Page i Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process Scott Ambler Wiley Computer Publishing John Wiley & Sons, Inc. 72244_FMI 2/27/02 11:34 AM Page ii Publisher: Robert Ipsen Editor: Theresa Hudson Development Editor: Kathryn A. Malm Managing Editor: Angela Smith New Media Editor: Brian Snapp Text Design & Composition: D&G Limited, LLC Designations used by companies to distinguish their products are often claimed as trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product names appear in initial capital or ALL CAPITAL LETTERS. Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration. This book is printed on acid-free paper. Copyright © 2002 by Scott Ambler. All rights reserved. Published by John Wiley & Sons, Inc., New York Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copy- right Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, (212) 850-6011, fax (212) 850- 6008, E-Mail: PERMREQ @ WILEY.COM.
    [Show full text]
  • Agile Methods of Software Development Agilemethods.Pptx
    Agile Methods of Software Development http://www-public.int-evry.fr/~gibson/Teaching/Agile/AgileMethods.pdf AgileMethods.pptx Dr J Paul Gibson, Dept. LOR, TSP, Evry, France October 2011 J Paul Gibson: Agile Methods 1 Structure of the Presentation Secondary Sources I Source Texts/ References 1. Software Process and the Software Life Cycle Geetesh Bajaj. 2005. Cutting Edge Powerpoint for Dummies . For Dummies. 2. History of Agile: More or less a process? II Quotes “PowerPoint makes us stupid .” 3. Agile Fundamentals Gen. James N. Mattis, US Marine Corps, http://www.nytimes.com/2010/04/27/world/27powerpoint.html 4. Comparing Agile Methods III Videos (youtube) 5. Agile Resources Boring Powerpoint (0:52) http://www.youtube.com/watch 6. Current Agile Research ?v=ZVFcagL1nsA October 2011 J Paul Gibson: Agile Methods 2 1. Software Process and the Software Life Cycle How important is a software development process? "... the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take ." Frederick P. Brooks , 1995, The Mythical Man-Month: Essays on Software Engineering October 2011 J Paul Gibson: Agile Methods 3 1. Software Process and the Software Life Cycle Why Do Software Projects Fail (Often) ? Grady Booch . 1995. Object Most often it is because of: Solutions: Managing the •A failure to properly manage the risks Object-Oriented •Building the wrong thing Project . Addison Wesley Longman •Being blinded by technology Publishing Co., Adopting a good software process & life cycle will help address these failure modes.
    [Show full text]
  • DHS Agile Development and Delivery for Information Technology Instruction States That Agile Is the Preferred IT Development Approach
    DHS Agile Development and Delivery for IT Testimonial “The Department of Homeland Security is visionary for its embrace of Agile methods. The private sector uses Agile to deliver software faster, better, and cheaper than their competitors. DHS has realized the country can’t afford for them to do anything less.” - Jeff Sutherland, CEO of Scrum Inc. and co-creator of Scrum Instruction Manual # 102-01-004-01 Revision #00 ii DHS Agile Development and Delivery for IT TABLE OF CONTENTS 1. Introduction ..................................................................................................................................................................... 1 1.1 Purpose and Scope ............................................................................................................................................... 1 1.2 Why Agile? ............................................................................................................................................................... 2 1.3 Document Structure ............................................................................................................................................ 3 2. Agile: The Basics ............................................................................................................................................................ 5 2.1 Understanding the Agile Approach ............................................................................................................... 5 2.2 Agile Methodologies and Frameworks .......................................................................................................
    [Show full text]
  • A Manager's Introduction to the Rational Unified Process (RUP)
    A Manager’s Introduction to The Rational Unified Process (RUP) Scott W. Ambler This version: December 4, 2005 Copyright 1999-2005 Scott W. Ambler Executive Summary Software development is a complex endeavor, one which is fraught with peril if you do not follow a proven software method. The Rational Unified Process (RUP) is one such method. The RUP takes an evolutionary approach to development which has been shown in practice to be far more effective than the traditional, serial “waterfall” approach which is prevalent in many organizations. This white paper overviews the lifecycle, phases, disciplines, and best practices of the RUP. It also provides suggested web-based resources which you may find useful if you are looking for more detailed information. Although written for managers, IT practitioners will also find this paper a valuable introductory resource to the RUP. Acknowledgements I would like to thank Peter Alfvin, Rob Exley, Mark Lines, and Frank Schophuizen for their insightful feedback which I have incorporated into this paper. Table of Contents 1 Serial in the Large................................................................................... 2 1.1 The Inception Phase........................................................................ 3 1.2 The Elaboration Phase .................................................................... 3 1.3 The Construction Phase .................................................................. 4 1.4 The Transition Phase .....................................................................
    [Show full text]