2. Agenda Introduction Adaptive vs. Predictive software development Traditional Software development process Waterfall model Iterative Incremental Model Spiral Model Agile Software development process Extreme Programming Model SCRUM Model Conclusion
5. Adaptive vs. Predictive Adaptive methods focus on adapting quickly to change When the project requirement change the adapted team also change An adaptive team can not report exactly what tasks are being done next week An Example of adaptive methods is Agile
6. Adaptive vs. Predictive (cont’d) Predictive method focus on planning the future in details Predictive team can report exactly what features and tasks are planned for the entire length of the development process Predictive team have difficulty changing direction, the plan is typically optimized for the original destination and changing direction can require completed work to be started over
7. Traditional software development Methods Waterfall Clean Room DSDM (Dynamic System Development Method) Iterative Incremental RAD (Rapid Application Development) RUP (Rational Unified Process) Spiral V-Model FDD (Feature Driven Development)
8. Traditional software development Methods Waterfall Clean Room DSDM (Dynamic System Development Method) Iterative Incremental RAD (Rapid Application Development) RUP (Rational Unified Process) Spiral V-Model FDD (Feature Driven Development)
9. Waterfall Model Is a sequential design process, often used in software development processes Originates in the manufacturing and construction industries; highly structured physical environments The Idea behind the waterfall model is “Measure Twice, Cut once”
10.
11. Waterfall Model (cont’d) Why Waterfall Provides a structured approach, it progress linearly, easily, understandable and explainable Provides easily markable milestones in the development process Suites the stable, unchanging requirements
12. Waterfall Model (cont’d) Why not Waterfall Many people think that waterfall model is a bad idea in practice It is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phase Client may not know exactly what requirements he need and he will need to change his requirements at any time
13. Waterfall Model (cont’d) Why not Waterfall Many people think that waterfall model is a bad idea in practice It is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phase Designers may not be aware of future Implementation
14. Waterfall Model (cont’d) Why not Waterfall Many people think that waterfall model is a bad idea in practice It is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phase Stockholders may not be fully aware of the capabilities of the technology being implemented
15. Iterative & Incremental development Developed in response to the weaknesses of the waterfall model Starts with initial planning and ends with deployment with the cycle interactions in between Iterative & incremental development is essential parts of the extreme programming & generally the Agile Development The project is delivered through cross discipline work from the requirement to the deployment
17. Iterative & Incremental development (cont’d) The basic idea is to develop a system through repeated cycles (Iterative) and in smaller portions at a time (Incremental) Allowing developers to take advantage of what was learned during the development of earlier portions Start with simple implementation of a subset of the software requirements and iteratively enhance the evolving version until the full system is implemented At each iteration, design modifications are made and new functional capabilities are added
22. Iterative & Incremental development (cont’d) Implementation Guidelines Any difficulty in design, coding & testing means the need of redesign and modification Modifications should fit easily isolated and easy to find modules The existing implementation should be analyzed frequently to determine how well it measures up to project goals
23. Spiral Model (cont’d) The spiral model was defined by Barry Boehm This model was not the first model to discuss iteration, but it was the first model to explain why the iteration matters aims at risk reduction by any means in any phase. The spiral model is often referred to as a risk-driven model Introducing prototyping in a Software Process aims at risk reduction at the requirements level There is always an element of risk involved in the other phases of development
25. Spiral Model (cont’d) Quadrant 1 Determining objectives of that phase, alternatives and constraints This is a way to define a strategy for achieving the goals of this iteration Quadrant 2 The strategy is analyzed form the viewpoint of risk, and solutions to minimize these risks are investigated
26. Spiral Model (cont’d) Quadrant 3 A solution is put into practice to produce the artifacts necessary to reach the goals identified in quadrant 1 Quadrant 4 The results of the risk-reduction strategies are assessed, and if all risks are resolved, the next phase is planned and started If some risks are left unsolved, another iteration can be made to continue to work
27. Spiral Model (cont’d) Advantages Emphasis on alternatives and constraints supports the reuse of existing solutions. Targets testing by treating it as a risk, which has to be addressed. Maintenance is just another phase of the spiral model. It is treated in the same way as development. Estimates (budget and schedule) get more realistic as work progresses, because important issues are discovered earlier.
28. Spiral Model (cont’d) Disadvantages Only intended for internal projects (inside a company), because risk is assessed as the project is developed. In case of external software development, all risk analysis must be performed by both client and developers before the contract is signed Spiral model is risk driven. Therefore it requires knowledgeable staff. Suitable for only large scale software development.
29. Agile software development Group of software development methodologies based on iterative and incremental development Requirements and solutions evolve through collaboration between self organizing, cross functional teams Introduced in 2001 It’s a light weight as a reaction against the heavy weight methods
30. Agile software development Methods SCRUM (1995) Crystal clear Extreme Programming (1996) Adaptive software development Feature driven development Dynamic system development method (1995) Open source software development
31. Agile software development Methods SCRUM (1995) Crystal clear Extreme Programming (1996) Adaptive software development Feature driven development Dynamic system development method (1995) Open source software development
32. Agile software development Methods (cont’d) Agile Manifesto We are uncovering better ways of developing software by doing it and helping other to do Agile Values Individuals & interactions over process & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
33. Agile software development Methods (cont’d) Agile Principles Customer satisfaction by rapid delivery of useful software
34. Agile software development Methods (cont’d) Agile Principles Welcome changing requirements even late in development
35. Agile software development Methods (cont’d) Agile Principles Working software is the principal measure of progress
36. Agile software development Methods (cont’d) Agile Principles Daily cooperation between business people & developers
37. Agile software development Methods (cont’d) Agile Principles Face to Face conversation is the best form of communication
38. Agile software development Methods (cont’d) Agile Principles Self-organized team that have motivated and trusted individuals
39. Agile software development Methods (cont’d) Characteristics Break tasks into small increments with minimal planning Iteration are short time frames from (1 4) weeks Each iteration involves a team working through a full software development cycle By the end of the iteration a demo will be represented to stack holders One iteration may not add enough feature to market release but the goal is to have a release with minimal bugs
40. Agile software development Methods (cont’d) Characteristics Team is usually cross functional and self organizing Team member take the responsibility of the task Face-to-face conversation for team in the same location and video for different locations that produce less written documents All team working in an open office called (bullpen) Small team size from (5 9) person
41. Agile software development Methods (cont’d) Characteristics Each team have a customer representative to answer mid iteration problems By the end of the iteration stockholders view demo and re evaluate the priorities of features Formal daily face to face communications to answer three questions (what they did the previous day? What they intend to do today? What their road blocks?)
42. Agile software development Methods (cont’d) Techniques to improve the quality and agility of project like: Unit test Pair programming Test driven Development Domain Driven Design Code refactoring
43. SCRUM Model Its one of the agile development methods It’s the skeleton that includes a set of practices and predefined roles
45. SCRUM Model (cont’d) Pig role The ones committed to the project in the scrum process Chicken role Not a part of the scrum process but must be taken into account
46. SCRUM Model (cont’d) Product Owner Represent the voice of the customer Ensure that the scrum teams works with the write things from a business perspective Write user stories, prioritize them and add them to product backlog
47. SCRUM Model (cont’d) SCRUM Master Help the team to deliver the sprint goal Is not the leader of the team but he is self organizer Ensure that the SCRUM process is used as intended He is the enforcer of rules
48. SCRUM Model (cont’d) Team Deliver the project Made up of (5 9) people with cross functional to do the actual work (Developers, Designers, Testers)
49. SCRUM Model (cont’d) Users The users of the product, and his participation is very important for feedback to review and plan sprint Stockholders The people who enable the project and the are important in sprint review Managers People who will set up the environment for the product
50. SCRUM Model (cont’d) Requirements User Product Owner Product backlog Meeting Sprint backlog Team
51. SCRUM Model (cont’d) Sprint (2 4) week period and it is decided by team In the sprint the team create an increment of usable software During the sprint no one can change the sprint backlog
52. SCRUM Model (cont’d) Product Backlog High level document of the entire project that include a broad description of all required features and wish list items Prioritized by business value of each feature Editable by anyone Contains rough estimates of both business value (product owner )and development effort (team members)
53. SCRUM Model (cont’d) Burn down The burn down chart is publically showing remaining work in the sprint backlog Updated every day Give a simple view of the sprint progress
54. SCRUM Model (cont’d) Sprint Backlog Features are broken down into tasks Best practice that tasks are normally estimated between 4h and 16h The whole team understand exactly the business logic of each task Any one them can pick task from task list, tasks in the task list are never assigned
56. SCRUM Model (cont’d) Daily SCRUM Meeting Project status meeting Starts precisely on time. And there is a punishment for late All are welcomed but only pig may speak The meeting is between (15 - 20) minutes All attendees should stand to make it short Happen in the same time, same location every day
57. SCRUM Model (cont’d) Daily SCRUM Meeting Every one should answer three questions What have you done since yesterday? What are you planning to do today? Do you have any problem preventing you from accomplish your goal?
58. SCRUM Model (cont’d) Sprint Planning Meeting Hold at the beginning of each sprint Decide what work is to be done Prepare the sprint backlog 8 hour limits
59. SCRUM Model (cont’d) Sprint review meeting Hold at the end of the sprint Review the complete and incomplete work Present the completed work to stockholders 4 hour limits
60. SCRUM Model (cont’d) Sprint Retrospective meeting All team members reflects on the past sprint Every member should answer What went well during the sprint? What could be improved in the next sprint
61. Extereme Programming Intended to improve software quality and responsiveness to changing customer requirements Intended to improve productivity and introduce checkpoints where new customer requirements can be adopted Programming in pairs or doing extensive code review Unit testing of all code (End of day testing) Avoiding programming of features until they are actually needed Simplicity and clarity in code Expecting changes in the customer's requirements Frequent communication with the customer and among programmers
63. ExteremeProgramming (cont’d) Concepts Organizes people to produce higher quality software more productively Attempts to reduce the cost of change by having multiple short development cycles, rather than one long one Introduces a number of basic values, principles and practices on top of the agile programming framework
65. ExteremeProgramming (cont’d) Coding Software instructions a computer can interpret. Without code, there is no working product Coding can also be used to figure out the most suitable solution Coding can also help to communicate thoughts about programming problems Code must be always clear and concise and cannot be interpreted in more than one way Other programmers can give feedback on this code by also coding their thoughts
66. ExteremeProgramming (cont’d) Testing if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws Unit tests determine whether a given feature works as intended. writes as many automated tests as they can think of that might "break" the code if all tests run successfully, then the coding is complete. Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements.
67. ExteremeProgramming (cont’d) Designing The system becomes too complex and the dependencies within the system cease to be clear Avoid this by creating a design structure that organizes the logic in the system Good design will avoid lots of dependencies within a system
68. ExteremeProgramming (cont’d) Listening Programmers must listen to what the customers need the system to do They must understand business logic needs well enough to give the customer feedback about the technical aspects of how the problem might be solved
70. ExteremeProgramming (cont’d) Communication This task is accomplished through documentation The goal is to give all developers a shared view of the system which matches the view held by the users of the system extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback
71. ExteremeProgramming (cont’d) Simplicity Encourages starting with the simplest solution the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month This is sometimes summed up as the "you aren't gonna need it" (YAGNI) approach Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed A simple design with very simple code could be easily understood by most programmers in the team
72. ExteremeProgramming (cont’d) Feedback Feedback from the system: by writing unit tests or running periodic integration tests Feedback from the customer: The functional tests (acceptance tests) are written by the customer and the testers Feedback from the team: When customers come up with new requirements the team directly gives an estimation of the time that it will take to implement
73. ExteremeProgramming (cont’d) Courage Courage enables developers to feel comfortable with refactoring their code when necessary This means reviewing the existing system and modifying it so that future changes can be implemented more easily courage to remove source code that is obsolete, no matter how much effort was used to create that source code
74. ExteremeProgramming (cont’d) Respect The respect value includes respect for others as well as self-respect Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring
75. ExteremeProgramming (cont’d) Rules Business people and developers do joint work Our highest priority is customer satisfaction Deliver working software frequently Working software Global awareness The team must act as an effective social network
Editor's Notes
Pig and Chicken Story to open restaurant named Ham and Egg , The pig say I’m not accepted , I’m committed but you are just involved
