Modern Systems Analysis and Design Chapter 1 Part 3

Table 1-2: The Agile Manifesto (1 of 3) • The Manifesto for Agile Software Development – Seventeen anarchists agree – We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ▪ Individuals and interactions over processes and tools ▪ Working software over comprehensive documentation ▪ Customer collaboration over contract negotiation ▪ Responding to change over following a plan Table 1-2: The Agile Manifesto (2 of 3) – That is, while we value the items on the right, we value the items on the left more. We follow the following principles: ▪ The highest priority is to satisfy the customer through early and continuous delivery of valuable software. ▪ Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. ▪ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. ▪ Businesspeople and developers work together daily throughout the project. ▪ Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. ▪ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. ▪ Working software is the primary measure of progress. Table 1-2: The Agile Manifesto (3 of 3) ▪ Continuous attention to technical excellence and good design enhances agility. ▪ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. ▪ Simplicity – the art of maximizing the amount of work not done – is essential. ▪ The best architectures, requirements, and designs emerge from selforganizing teams. ▪ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Table 1-3: Five Critical Factors that Distinguish Agile and Traditional Approaches to System Development Factor Agile Methods Traditional Methods Size Well matched to small products and teams Reliance on tacit knowledge limits scalability Methods evolved to handle large products and teams Hard to tailor down to small products Criticality Untested on safety-critical products Potential difficulties with simple design and lack of documentation Methods evolved to handle highly critical products Hard to tailor down to products that are not critical. Dynamism Simple design and continuous refactoring are excellent for highly dynamic environments but a source of potentially expensive rework for highly stable environments Detailed plans and Big Design Up Front, excellent for highly stable environment but a source of expensive rework for highly dynamic environments Personnel Requires continuous presence of a critical mass of scarce experts Risky to use non-agile people Needs a critical mass of scarce experts during project definition but can work with fewer later in the project, unless the environment is highly dynamic Culture Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom (thriving on chaos) Thrives in a culture where people feel comfortable and empowered by having their roles defined by clear practices and procedures (thriving on order) eXtreme Programming (1 of 2) • Short, incremental development cycles • Focus on automated tests written by programmers • Emphasis on two-person programming teams • Customers to monitor the development process • Relevant parts of eXtreme Programming that relate to design specifications are 1. 2. How planning, analysis, design, and construction are all fused into a single phase of activity Its unique way of capturing and presenting system requirement and design specifications eXtreme Programming (2 of 2) • Coding and testing are related parts of the same process • Advantages include – Increased communications among developers – Higher levels of productivity – Higher quality code – Reinforcement of other practices in eXtreme Programming Scrum (1 of 3) • Originated in 1995 by Sutherland and Schwaber • Most popular methodology for agile (87% of companies report using it) • Scrum framework includes – Scrum teams with associated roles, events, artifacts, and rules – Each team consists of three roles ▪ Product owner ▪ Development team ▪ Scrum master Scrum (2 of 3) • Scrum designed for speed and multiple functional product releases • Primary unit is the Sprint (runs two weeks to a month) – Starts with an eight-hour planning meeting ▪ What needs to be delivered by the end of the sprint ▪ How will the team accomplish that work – Daily Standup: A 15-minute meeting held to evaluate progress made within the past 24 hours and what needs to be done Scrum (3 of 3) – At the end of the sprint, two additional meetings ▪ The Sprint Review: (4 hours) focusing on the product, what has been accomplished, and what needs to be done ▪ The Sprint Retrospective: (3 hours) focusing on team performance and how it can improve – Three primary artifacts in the Scrum process 1. Product Backlog: Listing of potential requirements 2. Sprint Backlog: Listing of only items to be addressed in a particular sprint 3. Increment: Represents the sum of all the Product Backlog items completed during a sprint. Agile in Practice • Agile development offers managers and programmers more choice in their efforts to produce good systems that come in on time and under budget • Implementing the agile approach can be challenging – Requires top management support – Knowledge about agile throughout the organization – Overcoming resistance to change • 42% of companies use a combination of agile and waterfall approaches Summary • In this chapter you learned how to: – Define information systems analysis and design – Describe the information systems development life cycle (SDLC) – Describe Agile Methodologies, eXtreme Programming, and Scrum