1 Agility and Architecture Can they coexist? Philippe Kruchten University of British Columbia Vancouver BC, Canada Office Fax : Abstract: Software architecture is taking a bad rap with many agile proponents; big up-front design, massive documentation, smell of waterfall, it is pictured as a non-agile practice, something we do not want to even consider; though everybody want to be called an architect. However, certain classes of system, ignoring architectural issues too long hit a wall and collapse by lack of an architectural focus. Agile architecture: a paradox, an oxymoron, two totally incompatible approaches? In this paper we review the real issues at stake, past the rhetoric and posturing, and we suggest that the two cultures can coexist and support each other, where appropriate. Keywords : software architecture, agile development methods 1. Paradox, oxymoron, incompatibility? Jim Highsmith (2002) defines agility as the ability of an organization to both create and respond to change in order to profit in a turbulent business environment. And Sanjiv Augustine (2005, p. 21) notes that the common characteristics of agile software development methods (XP, Scrum, FDD, Lean, Crystal, etc.) are: iterative and incremental lifecycle, focus on small releases, collocated teams, a planning strategy based on two levels: release plan driven by a feature or product backlog, and an iteration plan handling a task backlog. They all also more or less adhere to the values of the agile manifesto (Agile Alliance, 2001). The Rational Unified Process or RUP (IBM, 2007) defines software architecture as the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition. Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics (Kruchten, 1998, p. 80). So far so good. But agilistas world-wide continue to perceive and describe software architecture a something of the past; they equate it with Big Up-Front Design
2 (BUFD) (a bad thing), leading to massive amount of documentation, implementing features YAGNI (You Ain t Gonna Need It). They see a low value of architectural design, a metaphor should suffice in most cases (Beck, 2000), and the architecture should emerge gradually sprint after sprint, as a result of succession of small refactoring. Conversely, in places where architectural practices are well developed, agile practices are often seen as amateurish, unproven, limited to very small web-based sociotechnical systems (Kruchten, 2007). The tension seems to lie on the axis of adaptation versus anticipation, where agile methods want to be resolutely adaptive: deciding at the last responsible moment or when changes occur, and they perceive software architecture to be pushing too much on the anticipation side: planning too much in advance. And where architects may be tempted to anticipate too much, too early. 2. A field story: hitting the wall A large international financial corporation wants to re-implement a large legacy IT system, result of years of evolutions, acquisitions, and integrations, several millions ines of Cobol, C, C++, RPG. It decides to proceed with agile methods, hire the proper consultants, get the training, and starts reim-plementing. The team is large, but collocated and has direct access to the internal customers (users of the legacy system), as well as the legacy code and documentation. Things proceed pretty fast at the beginning, with every 2 weeks some prototype demonstrating actual valuable progress. After some 6 months or so, things become harder. The team has now grown to about 50 people. The refactoring driven by new functionality added to the system hardly fit in one iteration, and are destabilizing everyone. Little visible progress is done, though everybody is really busy. Internal crisis ensue, turn over increases dramatically, lots of finger pointing. The system comes to a complete halt. Like marathonians after km 40, they have hit a wall. Focusing solely on user stories valuable for their users upstairs, they completely neglected any architectural activities, and having accumulated a rather large code base, some of the decisions they have now to make are pretty dramatic. The blame goes to the agile methods. The project is restarted with more conservative approaches, and a stronger focus on mitigating technical risks, in particular putting in place some minimal architectural skeleton. 3. The real issues The issues of trying to understand the apparent conflict and reconcile the two sides are in multiple levels: semantics (what do you really mean by software architecture), scope (how much architecture need to be done), lifecycle (when), role (by whom), documentation (how does architecture manifest itself), methods (how to proceed), value and cost (what value does it bring anyhow?) 3.1 Semantics What do we mean by software architecture? I have given above the RUP definition. It is about the important stuff, the decisions that will be taken early and will be the hardest to undo, to modify, to remove (Fowler, 2004). Software architecture is about design, decisions that will be binding in the final product. But we witness a certain dilution of the term architecture.
3 Fig. 1 Decisions and when architecture equates design If the yellow circle represent all decisions that will be made for a software system, a subset will be labeled design decisions (blue), leaving a large amount of decision at the level of programming. In turn a very small subset of these design decisions will be architecturally significant (red), i.e., will be overarching, long-lived, very hard to change. Note that some decisions are made upstream in the form of requirements constraints (green). Unfortunately, more and more, we see the decision landscape look more like the figure on the right, where not much distinction is left between design and architecture (blue equals red). Mary Shaw had warned us a long time ago: Do not dilute the meaning of the term architecture by applying it to everything in sight (cited by Garlan, 1995). Not all design decisions are architectural. Very few are, actually, and in many projects as we will see below, they are already taken on day one. 3.2 Scope How much architectural activity will you need to have on your project? Here the response it a loud it depends. It fluctuates widely depending on the context of the software project. By context I mean the environment of the project: the organization, the domain, etc, and then the specific factors of a given project. Fig. 3 Factors making up the context of a project
4 1. Size The overall size of the system under development is by far the greatest factor, as it will drive in turn the size of the team, the number of teams, the needs for communication and coordination between teams, the impact of changes, etc. 2. Stable architecture Is there an implicit, obvious, de facto architecture already in place at the start of the project? Most projects are not novel enough to require a lot of architectural effort. They follow commonly accepted patterns in their respective domain. Many of the key architectural decisions are done in the first few days, by choice of middleware, operating system, languages, etc. 3. Business model What is the money flow? Are you developing an internal system, a commercial product, a bespoke system on contract for a customer, a component of a large system involving many different parties? 4. Team distribution Linked sometimes to the size of the project, how many teams are involved and are not collocated? This increases the need for more explicit communication and coordination of decisions, as well as more stable interfaces between teams, and between the software components that they are responsible for. 5. Rate of change Though agile methods are embracing changes, not all domains and system experience a very rapid pace of change in their environment. How stable is your business environment and how much risks (and unknowns) are you facing? 6. Age of system Are we looking at the evolution of a large legacy system, bringing in turn many hidden assumptions regarding the architecture, or the creation of a new system with fewer constraints? 7. Criticality How many people die or are hurt if the system fail? Documentation needs increase dramatically to satisfy external agencies who will want to make sure the safety of the public is assured. 8. Governance How are project started, terminated, who decide what happens when things go wrong? In the sweet spot of agile project, in my experience, little architectural activities need to take place in most projects. But this still lives room for the large, complicated, projects where significant architectural efforts will be needed. Many agilistas have not seen such projects (yet). Not that agile practices cannot be applied to such projects, but they need
5 some adjustments to fit their practices to the specific circumstances: criticality, distribution, governance, business model, etc. 3.3 Lifecycle When will architectural activities take place? As much as we d love to defer decisions to the last responsible moment, for architectural decisions, because many of other design decisions will depend on them, they have to take place in the early phase of the project, or at least well identified. This does not necessarily mean Big Up-Front Design, where all sorts of design take place early, in a void, not driven by any immediate needs. Also we d love to see the architecture gradually emerge as the result of successive refactoring, but for large novel systems, this may need a bit of anticipation. You Ain t Going to Need It (YAGNI) requires at least that you identify the it ; same for deferring the decision to the last responsible moment implies that you know what it is that you are deferring. Putting in place a robust architecture is the purpose of the Elaboration phase in the RUP lifecycle (figure 4). This is driven by functional needs, not a pure architectural exercise in a void. Fig.4 Architectural activities in the RUP lifecycle are mostly in elaboration phase And if an architecture is in place on day one, the elaboration phase is basically empty, or takes one quick iteration to validate (fig. 4). The key criterion to enter the construction phase is: have we mitigated all our technical risks? And not: have we finished the design? When some significant architectural activities must happen, the early iterations (sprints) will integrate enough technical elements and focus more on architectural validation than delivering functionality (as shown in figure 5).
6 Fig.5 change of focus through the lifecycle They key here is not to focus on doing all the design (and implementation) of the architecture up-front, but on reaching rapidly a point where enough architectural elements are in place to enable multiple teams to proceed rapidly without too much interference between them or changes with dramatic effect. Figure 6 shows how an large software development organization (from 5 to 150 people) evolved through the RUP lifecycle. The groups in green operate very naturally using agile practices. The other one provide more of a glue and coordination function. Fig. 6 Evolution of large organizations; from (Kruchten, 2004) Agile approaches put emphasis on delivering value, but there is also in some contexts a large amount of unknowns and of risks that must be addressed early, if only to discover early that certain approaches are unfeasible, do not scale up, rely on immature technologies, assume skills or productivity not available, etc. Many of the technical risks are mitigated by some architectural design and prototyping. But not all projects are facing such risks.
7 3.4 Role Who are the architects? While on a small systems everyone may contribute to the role, on larger systems the architect(s) will play a combination of roles (Kruchten, 1999; Mills, 1985; Rechtin, 1994): 1. Visionary, shaping the system 2. Designer, making important technical choices 3. Communicator, playing go-between multiples stakeholders and groups 4. Troubleshooter, giving direction when things get hard or wrong 5. Herald, being the window of the project to the outside world 6. And even sometimes Janitor, cleaning up the mess behind project managers, product managers or developers. These often partition into 2 types of individuals: 1. Maker and keeper of big decisions, bringing technological changes, focusing on external coordination, more requirements-facing, gatekeeper 2. Mentor, troubleshooter, prototyper, implementing elements of the architecture, focusing on intense internal communication, more code-facing. These correspond to Architectus Reloadus, and Architectus Aryzus in (Fowler, 2003), and their respective ecological niche on fig. is architecture team and prototyping team, the architectus aryzus becoming naturally technical leads of the various teams down the line. 3.5 Documentation How is architecture communicated to the various parties who need to know about it? Her again there is a wide spectrum of possibilities: An architectural prototype: the architecture is defined in the code A metaphor or a set of metaphors with carefully selected names to provides a good narrative to explain who the system is organized and how it works (Beck, 2000) A large component or class diagram on the wall A software architecture document, as suggested in RUP (IBM, 2007) or defined eloquently by (Paul Clements, et al., 2002; P. Clements, Ivers, Little, Nord, & Stafford, 2003). An architecture specific tool Or a combination of these. The key idea is communication: choosing the best vehicle in the context of the project. The goal is not documentation for the sake of it. It will again depend much on the context (see figure 3). 3.6 Methods How are we identifying and resolving architectural issues? Many agile approaches are rather silent on the topic. A pity, as a study of 5 architectural methods (Hofmeister, et al., 2007), shows that they all have underlying an iterative pattern (see figure ) not too different from Scrum (Schwaber & Beedle, 2002): Identification of architectural issue (from requirements: stories, other constraints, assets, etc.), incremental design, validation by prototyping, and evaluation by testing, review or otherwise.
8 Architectural Assets Architecture Ideas Architectural Synthesis Context, Constraints Backlog Architectural Analysis Architectural Evaluation Architecturally Significant Requirements Evaluation results Fig. 7-- Pattern at the core of 5 architectural methods (Hofmeister, et al., 2007, p. 114) Here the issue seems to be mostly ignorance of architectural practices by a large segment of software developers, architects included. 3.7 Value and cost Agile approaches strive to deliver business value, early and often. Though not all domains and business context allow doing this, it is still a useful way to pace the project, by defining small increments, leading to internal releases. However, if the value for the business can be defined in relative terms (priorities) or even in absolute terms by financial analysis (Denne & Cleland-Huang, 2004b), the value of architecture is not externally visible, and some of the necessary architectural thinking will not occur until too late to efficiently alter the course of the project. This will be the case mostly for large, novel systems. On non trivial systems, there is a balance to strike between business value and technical risk (Fowler, 2004). Scrum allow for provision for technical stories or activities in the backlog. Though the cost of the architectural effort can bed known, much of its value is realized much later in the project. An approach like the Incremental Funding Method (Denne & Cleland-Huang, 2004a) allows to cast the right compromise, without falling into the trap of Big Up-Front Design. 4. Planning For system development that require some non trivial of architectural work, the planning could follow the zipper pattern. From requirements and constraints, functional and non functional, separate architecturally significant issues and purely functional issues. Establish dependencies between them; this is the architectural analysis step of fig. ^. Create additional stories for architectural issues and risks. Derive their value from the functional elements that depend on it. All the architectural issues do not need to be resolved up-front, but at least they are now visible in the backlog. Temporary, simple strategies can be put in place to allow early development of some functional aspects, while retaining in the project memory of further actions that may have to take place later: design, refactoring, validation.
9 Fig. 8 Zipper metaphor: Weaving functional and architectural activities 5. A conflict of cultures Spencer-Oatey (2000, p. 4) defines culture as a fuzzy set of attitudes, beliefs, behavioural norms, and basic assumptions and values that are shared by a group of people, and that influence each member s behaviour and his/her interpretations of the meaning of other people s behaviour. Agility is more a culture than an engineering method and probably to a lesser extent is the less visible community of software architecture. They both have developed, based on specific beliefs, a set of values ( agile manifesto ), and behaviours (methods, practices, artifacts), sometimes also rituals and jargon that tend to detract outsiders (Kruchten, 2007). As for any clash of two cultures, the members of one culture go through several phases (Ting-Toomey, 1999, pp ): Ethnocentrism: my culture is right, is the reference by which other cultures must be judged, others are bad, etc. The attitude is defensive, dismissive, coercive. Ethnorelativism: leading to acceptance of other view-points, values, and possibly attempts to coexistence and integration. It may guide the definition of new behaviours, and from this new values and possibly evolution of the beliefs. I personally stand with one foot in each of these two cultures: architecture and agility, and like other ethnic cultures, I see two parties not really understanding the real issues at hand, stopping at a very shallow, caricatural view of the other culture, not understanding enough of the surroundings, beliefs, values of the other one, and stopping very quickly at judging behaviours.
10 Fig. 9 Agility (or architecture) as a culture, after (Thomsett, 2007) 6. Burying the hatchet What lessons could both these cultures take away? Understand the context. There is a vast array of software development situation, and although agile practices out of the box address many of these, there are outliers for which we need to understand. What is the size, domain, age of the system? What are the business model, degree of novelty, hence of risk? How critical must the system be? How many parties will be involved? Define architecture clearly: the scope of the word, the role and responsibility of the architect. Do not assume a tacit, implicit understanding (Kruchten, 1999). Define an architecture owner, like there should be a product owner and a project leader. But do not let the architects lock themselves in some ivory tower, polishing the ultimate architecture for an improbably future system. Architect or architects are part of the development group. Exploit architecture to better communicate and coordinate between various parties, in particular multiple distributed teams, if any. Define how it will be represented, based on the need-to-know of the various aprties. Use important, critical, valuable functionality to identify architectural issues, and assess them. Understand interdependencies between technical architectural issues, and user visible functionality, so as to weave them appropriately over time (zipper metaphor). Understand when it is appropriate to freeze the architecture to provide the necessary stability for developers to finish a product release, and what amount of technical debt is then accumulated. Keep track of unresolved architectural issues, either in the backlog or in the risks. Deferring decisions to the last responsible moment does not equate to ignoring them, but may be adding risks to be managed like other risks in the project. In the movie The Matrix Reloaded (Wachowski & Wachowski, 2003), the Architect says: The first matrix I designed was quite naturally perfect. a triumph equaled only by its monumental failure. I have since come to understand that the answer eluded me because it required a lesser mind, or perhaps a mind less bound by the parameters of perfection.
11 References Agile Alliance (2001). Manifesto for Agile Software Development. Retrieved June 24, 2008, from Augustine, S. (2005). Managing Agile Projects. Upper Saddle River, N.J.: Prentice Hall. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Boston: Addison- Wesley. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., et al. (2002). Documenting Software Architectures: Views and Beyond. Boston: Addison- Wesley. Clements, P., Ivers, J., Little, R., Nord, R., & Stafford, J. (2003). Documenting Software Architectures in an Agile World (Vol. CMU/SEI-2003-TN-023). Pittsburgh: Software Engineering Institute. Denne, M., & Cleland-Huang, J. (2004a). The Incremental Funding Method: Data-Driven Software Development. IEEE Software, 21(3), Denne, M., & Cleland-Huang, J. (2004b). Software by Numbers: Low-Risk, High-Return Development. Upper Saddle River, N.J.: Prentice Hall. Fowler, M. (2003). Who needs an architect? IEEE Software, 20(4), 2-4. Fowler, M. (2004). Is Design Dead? Retrieved June 24, 2008 from Garlan, D. (1995). First International Workshop on Architectures for Software Systems Workshop Summary. Software Engineering Notes, 20(3), Highsmith, J. A. (2002). Agile software development ecosystems. Boston: Addison- Wesley. Hofmeister, C., Kruchten, P., Nord, R., Obbink, H., Ran, A., & America, P. (2007). A General Model of Software Architecture Design derived from Five Industrial Approaches. Journal of Systems & Software, 80(1), IBM (2007). Rational Unified Process. Retrieved June 24, 2008 from ibm.com/software/awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca =dtl-08rupsite Kruchten, P. (1998). The Rational Unified Process--An Introduction (1 ed.). Boston, MA: Addison-Wesley. Kruchten, P. (1999). The Software Architect, and the Software Architecture Team. In P. Donohue (Ed.), Software Architecture (pp ). Boston: Kluwer Academic Publishers. Kruchten, P. (2004). Scaling down projects to meet the Agile sweet spot. The Rational Edge, (August 2004). Retrieved June 24, 2008 from ibm.com/developerworks/rational/library/content/RationalEdge/aug04/5558.h tml Kruchten, P. (2007). Voyage in the Agile Memeplex: Agility, Agilese, Agilitis, Agilology. ACM Queue, 5(5), Mills, J. A. (1985). A Pragmatic View of the System Architect. Comm. ACM, 28(7), Rechtin, E. (1994). The Systems Architect: Specialty, Role and Responsibility. Paper presented at the 1994 NCOSE Symposium, San Jose, CA. Schwaber, K., & Beedle, M. (2002). Agile Software Development with SCRUM. Upper Saddle River, NJ: Prentice-Hall.
12 Spencer-Oatey, H. (2000). Culturally Speaking: Managing Rapport through Talk across Cultures. New York: Cassel. Thomsett, R. (2007). Project Management Cultures: the Hidden Challenge. Agile Product and Project Management, 8(7). Ting-Toomey, S. (1999). Communicating acrosss cultures. New-York: The Guilford Press. Wachowski, A., & Wachowski, L. (Directors) (2003). The Matrix Reloaded. Warner Bros. Philippe Kruchten is a professor of software engineering at the University of British Columbia in Vancouver, Canada. He is a founding member of the IFIP working group 2.10 on software architecture, and the co-founder and chair of Agile Vancouver--an agile method fan club. In a previous life he led the development of the Rational Unified Process, which was more agile in its intent that practitioners have made of it, and which embodied an architectural method.
Scaling Down Large Projects to Meet the Agile Sweet Spot Philippe Kruchten Kruchten Engineering Services Ltd Presenter Philippe Kruchten, Ph. D., P. Eng. KESL 2906 West 37 th avenue Vancouver BC V5Z 2M9
Agile Development and Software Architecture: Understanding Scale and Risk Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Robert L. Nord SSTC, April 2012 In collaboration
Agile Processes Software processes that are: Incremental (small software releases with rapid cycles) Cooperative (customer and developer working together with close communication) Straightforward (method
A Cynical View on Agile Software Development from the Perspective of a new Small-Scale Software Industry Apoorva Mishra Computer Science & Engineering C.S.I.T, Durg, India Deepty Dubey Computer Science
International Journal of Information and Computation Technology. ISSN 0974-2239 Volume 3, Number 3 (2013), pp. 153-162 International Research Publications House http://www. irphouse.com /ijict.htm Strategic
PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, email@example.com 2 Faculty
International Journal of Recent Research and Review, Vol. VI, June 2013 Comparative Study of Agile Methods and Their Comparison with Heavyweight Methods in Indian Organizations Uma Kumari 1, Abhay Upadhyaya
Requirements Analysis and Emergent Design in Agile Software Development Practices Bruno Rossi Department of Computer Systems and Communications, Lasaris (Lab of Software Architectures and Information Systems)
Agile Modeling: A Brief Overview Scott W. Ambler President, Ronin International firstname.lastname@example.org Abstract: Agile Modeling (AM) is a practice-based methodology for effective modeling of software-based
1 Software Engineering Lecture 2: Software Life Cycles Stefan Hallerstede Århus School of Engineering 25 August 2011 2 Contents Naive Software Development Code & Fix Towards A Software Process Software
Factors Influencing Agile Practices: A Survey Akhil Kumar 1, Bindu Goel 2 1 (University School of Information Technology, GGS Indraprastha University, New Delhi-110075) 2 (University School of Information
TALKING POINTS Quality is an inherent aspect of true agile software development. The majority of agilists take a test-driven approach to development where they write a unit test before they write the domain
Strategic Management of Architectural Technical Debt Ipek Ozkaya Senior Researcher A senior member of the SEI technical staff, Ipek Ozkaya is the co-organizer of the Third International Workshop on Managing
db4o The Open Source Object Database Java and.net Agile Techniques for Object Databases By Scott Ambler 1 Modern software processes such as Rational Unified Process (RUP), Extreme Programming (XP), and
Agile and Secure: Can We Be Both? OWASP AppSec Seattle Oct 2006 Keith Landrus Director of Technology Denim Group Ltd. email@example.com (210) 572-4400 Copyright 2006 - The OWASP Foundation Permission
EMC PERSPECTIVE Adopting an Agile Approach to OSS/BSS Development Reader ROI The agile software methodology is different from the traditional approach in that requirements gathering and analysis, design,
Versions 2.0 Version Date Remarks 1.0 12/4/2012 Initial version 2.0 3/8/2008 REVISION HISTORY Updated knowledge areas Added questions examples Updated suggested readings section Page 2 of 15 Version 2.0
Journal of Applied Economics and Business USAGE OF KANBAN METHODOLOGY AT SOFTWARE DEVELOPMENT TEAMS Nevenka Kirovska 1, Saso Koceski 2 Faculty of Computer Science, University Goce Delchev, Stip, Macedonia
10 Int'l Conf. Software Eng. Research and Practice SERP'15 On the Agile Development of Virtual Reality Systems F. Mattioli 1, D. Caetano 1, A. Cardoso 1, and E. Lamounier 1 1 Faculty of Electrical Engineering,
Agile Project Management Jim Highsmith Chapter 5 An Agile Project Management Model We improve effectiveness and reliability through situationally specific strategies, processes, and practices. One of the
Neglecting Agile Principles and Practices: A Case Study Patrícia Vilain Departament de Informatics and Statistics (INE) Federal University of Santa Catarina Florianópolis, Brazil firstname.lastname@example.org Alexandre
University of Dublin Trinity College ST3006 - Software Engineering Anthony Harrington Department of Computer Science Trinity College Dublin Anthony.Harrington@cs.tcd.ie Lifecycles A software project goes
Scrum Is Not Just for Software A real-life application of Scrum outside IT. Robbie Mac Iver 2/9/2009. Agile methods like Scrum can be applied to any project effort to deliver improved results in ever evolving
REVIEW OF AGILE METHODOLOGIES IN SOFTWARE DEVELOPMENT 1 MALIK HNEIF, 2 SIEW HOCK OW 1 Department of Software Engineering, University of Malaya, Kuala Lumpur, Malaysia-50603 2 Assoc. Prof., Department of
Theory Lecture Plan 2 Software Configuration Lecture 11 Software Engineering TDDC88/TDDC93 autumn 2008 Department of Computer and Information Science Linköping University, Sweden L1 - Course Introduction
Agile Software Project Management with Scrum Viljan Mahnic, Slavko Drnovscek University of Ljubljana, Faculty of Computer and Information Science Trzaska 25, SI-1000 Ljubljana, Slovenia email@example.com,
1(37) Agile development of safety-critical software while meetings standards' requirements Matti Vuori, Tampere University of Technology 2011-11-04 Contents 1/2 A study in Ohjelmaturva 4 Tendency to be
Software Developing with Agile Methods and Combination of Architecture Mehdi Yaghoubi Department of Computer Sciences, Faculty of Sciences, Golestan University, Gorgan, Golestan, Iran Manoochehr Babanezhad
AGILE METHODOLOGY IN SOFTWARE DEVELOPMENT Shivangi Shandilya, Surekha Sangwan, Ritu Yadav Dept. of Computer Science Engineering Dronacharya College Of Engineering, Gurgaon Abstract- Looking at the software
An Exploratory Study of Architectural Practices and Challenges in Using Agile Software Development Approaches Muhammad Ali Babar Lero, University of Limerick, Ireland firstname.lastname@example.org Abstract Agile software
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
Software Corporation Software Project Management using an Iterative Lifecycle Model 1 Objectives of this Presentation To understand what the Unified Process is To understand the iterative lifecycle approach
Estimate Agile Projects and Improve Success David DeWitt Director Commercial and International Programs Galorath Webinar August 5 th 2015 Copyright Galorath Incorporated 2015 In The Beginning. Thirty-five
Agile Software Development Chapter 3 Agile Software Development Outline: 1. The problem with traditional development processes 2. What are agile processes? 3. Extreme programming (XP) 4. Agile versions
Transitioning Your Software Process To Agile Jeffery Payne Chief Executive Officer Coveros, Inc. email@example.com www.coveros.com 1 About Coveros Coveros helps organizations accelerate the delivery
COMPARATIVE STUDY ON SOFTWARE PROJECT MANAGEMENT MODELS *1 Mrs. Kalaivani S., * 2 Mrs. Kavitha S., *1 M.Phil Research Scholar, Department of Computer Science Auxilium College (Autonomous), Vellore, TamilNadu,
Introduction to Agile Software Development Word Association Write down the first word or phrase that pops in your head when you hear: Extreme Programming (XP) Team (or Personal) Software Process (TSP/PSP)
Success Factors of Agile Software Development Subhas C. Misra, Vinod Kumar, and Uma Kumar Carleton University, Ottawa, Canada Abstract Agile software development methodologies have recently gained widespread
Hamid Faridani (firstname.lastname@example.org) March 2011 Introduction Methodologies like Waterfall, RUP and Agile have all become key tools for software developers and project manager s to aid them in delivering
Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability
Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky
08 Experience, Intelligence, Pragmatism, Commitment. Always striving to ensure outstanding delivery Agile and Enterprise Architecture Steve Marchant July 2013 Abstract The IT industry is evolving at an
Scrum with XP By Kane Mar, Ken Schwaber. Introduction Scrum and extreme programming (XP) are both Agile methodologies. We've heard controversy regarding the value of each, with people familiar with each
Conducting an Architecture Group in a Multi-team Agile Environment Mauricio José de Oliveira De Diana 1, Fabio Kon 1, Marco Aurélio Gerosa 1 1 Department of Computer Science University of São Paulo (USP)
International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Journal of Engineering, Business and Enterprise
www.ijcsi.org 441 A Comprehensive Study of Commonly Practiced Heavy and Light Weight Software Methodologies 1 Asif Irshad Khan, 2 Rizwan Jameel Qurashi and 3 Usman Ali Khan 1 Department of Computer Science
Issues in Internet Design and Development Course of Instructions on Issues in Internet Design and Development Week-2 Agile Methods Saad Bin Saleem PhD Candidate (Software Engineering) Users.mct.open.ac.uk/sbs85
AGILE SOFTWARE DEVELOPMENT: INTRODUCTION, CURRENT STATUS & FUTURE Pekka Abrahamsson 23.11.2005 Jyväskylä Fact corner: SME of 250 developers Mobile & desktop sw Products sold globally EXAMPLE OF AN INNOVATIVE
SAFETY & RESILIENCE ISSUES IN AUTOMOTIVE SOFTWARE DEVELOPMENT PANEL 1 Safety Panel when 26262 will be issued, enforced? What about 61508? by whom, which authorities? who and how will verify conformance?
CIMCA 2008, IAWTIC 2008, and ISE 2008 Comparing Agile Software Processes Based on the Software Development Project Requirements Malik Qasaimeh, Hossein Mehrfard, Abdelwahab Hamou-Lhadj Department of Electrical
Laboratório de Desenvolvimento de Software FEUP/MIEIC, 2015/16 Ademar Aguiar Nuno Flores Rui Maranhão Hugo Ferreira Luís Teixeira url: moodle http://www.facebook.com/notes/facebook-engineering/visualizing-friendships/469716398919
Automated Acceptance Testing of High Capacity Network Gateway Ran Nyman 1, Ismo Aro 2, Roland Wagner 3, 1,2,3 Nokia Siemens Network, PO Box 1 FI-02022 Nokia Siemens Networks 1 email@example.com, 2 firstname.lastname@example.org,
Web Applications Development and Software Process Improvement in Small Software Firms: a Review Haroon Tarawneh Al-balqa Applied University email@example.com Sattam Allahawiah Al-balqa Applied University
Software Development Process A software development process, also known as software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software
The Oregon Software Development Process Till Schümmer 1 and Robert Slagter 2 1 Computer Science Department, FernUniversität in Hagen, Universitätsstrasse 1, 58084 Hagen, Germany Till.Schuemmer@fernuni-hagen.de
PERFORMANCE ENGINEERING IN SCRUM Balasubramanian, Infosys Technologies Limited This paper describes how performance engineering as a software discipline should be planned and executed in an agile development
Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum
Investigation of Adherence Degree of Agile Requirements Engineering Practices in Non-Agile Software Development Organizations Mennatallah H. Ibrahim Department of Computers and Information Sciences Institute
Agile Software Development Application in the Medical Device Industry Kelly Weyrauch Medtronic, Inc. (29 April 2008) Introduction Purpose Provide an introduction to Agile Software Development as it applies
An Efficient Objective Quality Model for Agile Application Development M.Usman Malik M. Haseeb Nasir Ali Javed UET Taxila UET Taxila UET Taxila Rawalpindi, Pakistan Rawalpindi, Pakistan Rawalpindi, Pakistan
New Developments in an Agile World: Drafting Software Development Agreements By: Paul H. Arne 1,2 A few months before this article was prepared, a group of senior IT professionals from some of the largest
Managing Software Debt Continued Delivery of High Values as Systems Age Speaker - Chris Sterling Certified Scrum Trainer Managing Consultant, Agile Coach, and Architect at SolutionsIQ Consults on enterprise
Business Analysts in an Agile World Christian Antoine What is this about Value of software Building the right product Building the product right Where do BA s fit in this What this is not Back to basics
A Roadmap to Agile Development: A Strategy to Increase Adoption Success Executive Summary Organizations that try to adopt Agile too quickly are often discouraged with less than stellar results, and they
What Agile Architects Do and What They Need Viktor Clerc Rik Farenhorst Daan Kalmeijer Who we are Inspearit: Consultancy and Training Architecture, Process Improvement, Software Quality, Security, Based
Chapter 2 WHY THE WATERFALL MODEL DOESN T WORK M oving an enterprise to agile methods is a serious undertaking because most assumptions about method, organization, best practices, and even company culture
Software Engineering: A Practitioner s Approach, 6/e Chapter 4 Agile Development copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use
RUP and XP, Part I: Finding Common Ground by Gary Pollice Evangelist, The Rational Unified Process Rational Software extreme Programming (XP) is hot! Attend any software development conference today and
A Softhouse White Paper Jens Norin Daniel Karlström September 2006 Softhouse Consulting, Stormgatan 14, SE-211 20 Malmö firstname.lastname@example.org www.softhouse.se Contents Abstract...3 Introduction...4 Software
Managing Knowledge in Development of Agile Software Mohammed Abdul Bari Department of Computer Science, College of Science & Arts University of Al-Kharj Wadi Al-Dawasir-11991, Kingdom of Saudi Arabia Dr.
What is meant by the term, Lean Software Development? Scope of this Report November 2014 This report provides a definition of Lean Software Development and explains some key characteristics. It explores
Agile and Secure Can We Be Both? Chicago OWASP June 20 th, 2007 The Agile Practitioner s Dilemma Agile Forces: Be more responsive to business concerns Increase the frequency of stable releases Decrease
Agile and Secure: Can We Be Both? OWASP AppSec Seattle Oct 2006 Dan Cornell, OWASP San Antonio Leader Principal, Denim Group Ltd. email@example.com (210) 572-4400 Copyright 2006 - The OWASP Foundation
Chapter 12. The Product Coordination Team In theory, theory and practice are the same. In practice, they are different. Attributed to many. In This Chapter This chapter describes the challenge of teams
Introduction to Agile Methods Chennai Agile User Group Kickoff Sanjiv Augustine July 08, 2006 www.ccpace.com Introduction to Agile Methods Page 1 Agenda Agile at a Glance Landscape Basics Typical Benefits
Comparative Analysis of Different Agile Methodologies Shelly M. Phil (CS), Department of Computer Science, Punjabi University, Patiala-147002, Punjab, India Abstract: Today s business, political and economic
Exploring Architectural Design Decision Management Paradigms for Global Software Development Meiru Che, Dewayne E. Perry Department of Electrical & Computer Engineering The University of Texas at Austin
Agile Requirements Methods by Dean Leffingwell Software Entrepreneur and Former Rational Executive To ensure that their software teams build the right software the right way, many companies turn to standard
Rally Software Development Corporation Whitepaper 5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up Hubert Smits Agile Coach and Certified ScrumMaster Trainer firstname.lastname@example.org
THESIS: MODERN SOFTWARE PROJECT MANAGEMENT STUDENT: JOAN ESCAMILLA FUSTER DIRECTOR: JUHA TAINA CODIRECTOR: JUAN CARLOS RUIZ GARCÍA 2009/2010 CONTENTS 1. Introduction. 3 2. Modern software process 5 2.1.
Are Management Basics Affected When Using Agile Methods? Paul E. McMahon PEM Systems Just how different is project management when using agile methods? The purpose of this article is to help readers understand
The Perusal and Review of Different Aspects of the Architecture of Information Security Vipin Kumar Research Scholar, CMJ University, Shillong, Meghalaya (India) Abstract The purpose of the security architecture