Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
- 2. Topics ā¢ Process Models ā¢ RUP ā¢ Agile Models 2
- 3. The Unified Process (UP) 3 inception elaboration
- 4. UP Phases 4
- 6. Agile development ā¢ Program specification, design and implementation are inter-leaved ā¢ The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation ā¢ Frequent delivery of new versions for evaluation ā¢ Extensive tool support (e.g. automated testing tools) used to support development. ā¢ Minimal documentation ā focus on working code 6
- 7. Plan-driven and agile development 7
- 8. Common Fears for Developers ā¢ The project will produce the wrong product. ā¢ The project will produce a product of inferior quality. ā¢ The project will be late. ā¢ Weāll have to work 80 hour/ week. ā¢ Weāll have to break commitments. 8
- 9. Plan-driven and agile development ā¢ Plan-driven development ā¢ A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. ā¢ Not necessarily waterfall model ā plan-driven, incremental development is possible ā¢ Iteration occurs within activities. ā¢ Agile development ā¢ Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process. 9
- 10. Agile methods 10
- 11. The Manifesto for Agile Software Development ā¢ āWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ā¢ Individuals and interactions over processes and tools. ā¢ Working software over comprehensive documentation. ā¢ Customer collaboration over contract negotiation. ā¢ Responding to change over following a plan. ā¢ That is, while there is value in the items on the right, we value the items on the left more.ā -- Kent Beck et al. 11
- 12. What is āAgilityā? ā¢ Effective (rapid and adaptive) response to change. ā¢ Effective communication among all stakeholders. ā¢ Drawing the customer onto the team. ā¢ Organizing a team so that it is in control of the work performed. Yielding ā¦ ā¢ Rapid, incremental delivery of software. 12
- 13. An Agile Process ā¢ Is driven by customer descriptions of what is required (scenarios). ā¢ Recognizes that plans are short-lived. ā¢ Develops software iteratively with a heavy emphasis on construction activities. ā¢ Delivers multiple āsoftware incrementsā. ā¢ Adapts as changes occur. 13
- 14. Agility and the Cost of Change 14
- 15. Agile Principles 1. Our highest priority is to satisfy the client through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the client's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 15
- 16. Human Factors ā¢ The process molds to the needs of the people and team, not the other way around. ā¢ Key traits must exist among the people on an agile team and the team itself: ā¢ Competence. ā¢ Common focus. ā¢ Collaboration. ā¢ Decision-making ability. ā¢ Fuzzy problem-solving ability. ā¢ Mutual trust and respect. ā¢ Self-organization. 16
- 17. Example: Extreme Programming (XP) 17
- 18. Extreme programming practices 18 Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development āTasksā. See Figures 3.5 and 3.6. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
- 19. Extreme programming practices 19 Pair programming Developers work in pairs, checking each otherās work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
- 20. User stories for requirements ā¢ In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements. ā¢ User requirements are expressed as user stories or scenarios. ā¢ These are written on cards and the development team break them down into implementation tasks.These tasks are the basis of schedule and cost estimates. ā¢ The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. 20
- 21. A āprescribing medicationā story 21
- 22. Examples of task cards for prescribing medication 22
- 23. Scrum ā¢ Scrum is an agile method that focuses on managing iterative development rather than specific agile practices. ā¢ There are three phases in Scrum. ā¢ The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. ā¢ This is followed by a series of sprint cycles, where each cycle develops an increment of the system. ā¢ The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project. 23
- 24. When Scrum can be applied? ā¢ Complex Projects. ā¢ Project with changing requirements. ā¢ Project with changing environment and conditions. ā¢ Project with uncertainties. ā¢ Project where all analysis (requirements, schedules, resource allocation) can not be done at the start (or at least not accurately). 24
- 25. Scrum Process ā¦ Outline ā¢ Start with Vision of what you want to achieve. ā¢ Come up with Core Requirements and priorities (Bare Minimum but good enough to get started) ā Product Backlog ā¢ Team selects the requirements that it can implement in the first iteration (Planning Meeting) ā¢ Team defines tasks for completing requirements (Sprint Backlog) ā¢ Team goes in 30-Day Development Cycle (Sprint) ā¢ Team meets daily to sync up on progress (Daily Scrum) ā¢ Team goes through the complete process (design, development, testing, documentation) to complete an increment of functionality. ā¢ At the end of 30 day sprint, Team demonstrates completed functionality to bosses and stakeholders (Sprint Review) ā¢ Team analyses its Sprint performance (Sprint Retrospective) ā¢ Requirements are prioritized, redefined. ā¢ Team goes through the process again (Sprint 2, Sprint 3, ā¦, Release) 25
- 26. A Complete View
- 27. Scrum Process ā Another Angle
- 28. The Committed People ā¢ There are 3 roles of the people who have committed themselves to the success of Scrum and are ultimately responsible for it. ā¢ Product Owner ā¢ Responsible for defining requirements of the project and their priorities. ā¢ The Team ā¢ The Cross-Functional Team that works on the Requirements defined and in the priority as given by the Product Owner. The Team is what carries out the Sprint. ā¢ Scrum Master ā¢ Member of Team that drives the Scrum. He guides the team and makes sure that Scrum is implemented.
- 29. Scrum Master ā¦ ā¢ Responsible for running the Scrum. ā¢ Plays the role of a facilitator, guider, trainer, motivator, impediment remover. ā¢ Scrum Master is NOT exactly Project Manager. ā¢ Should know more about the Scrum process than others. ā¢ Should be very clear on the philosophy behind Scrum principles. ā¢ Responsible for improving the overall working environment and conditions for the team. ā¢ Makes sure that the team is not obstructed in any way during the Sprint. ā¢ Ensures Scrum principles are followed. 29
- 30. Sprint Review ā¢ Conducted at the end of Sprint ā¢ Team demonstrates completed functionality in Sprint to Product Owner and Stakeholders ā¢ Itās the āinspection and adaptationā part ā¢ Management can identify risks and opportunities ā¢ Product Owner and others can reprioritize the Product Backlog after this āfeedbackā
- 31. Sprint Review Rules ā¢ Team should not spend more than 1 hour to prepare ā¢ Only ādoneā functionality is presented ā¢ Sprint Review involves team presenting functionality, answering questions and discussion ā¢ Everyone gives their feedback ā¢ Scrum Master schedules and conducts the meeting
- 32. Sprint Retrospective ā¢ Conducted after Sprint Review by the Team ā¢ They evaluate the just concluded Sprint ā¢ They discuss what went wrong, what went right and what needs to be changed and improved ā¢ The objective is to ensure that the next Sprint goes better than the current Sprint
- 33. Scrum Process - Meetings
- 35. Daily Scrum ā Rules ā¢ Chickens can attend ā but cannot interfere ā¢ Every Team members answers 3 questions: ā¢ What has he done since last meeting? ā¢ What he plans to do between now and next meeting? ā¢ What impedes his work progress? ā¢ There should be no digressing beyond these 3 questions
- 36. Scrum of Scrums ā¦
- 37. Scrum benefits ā¢ The product is broken down into a set of manageable and understandable chunks. ā¢ Unstable requirements do not hold up progress. ā¢ The whole team have visibility of everything and consequently team communication is improved. ā¢ Customers see on-time delivery of increments and gain feedback on how the product works. ā¢ Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. 37
- 38. Other Agile Processes ā¢ Adaptive Software Development (ASD) ā¢ Dynamic Systems Development Method (DSDM) ā¢ Crystal ā¢ Feature Driven Development ā¢ Agile Modeling (AM) 38
- 39. Model Selection 39 āā¦But we must try to understand it if we are to solve it.ā Fred Brooks, 1975
- 40. Exercise ā¢ List down key attributes/characteristics that help in selecting a process model or differentiating them. 40
- 41. References 1. Software Engineering, Sommerville, I., Chapter 2 & 3, 10th Edition (2016), Pearson. 2. Software Engineering: A Practitionerās Approach, Pressman, R.S. & Maxim B., Chapter 2 & 3, 8th Edition (2015), McGraw-Hill. 41