Software Development Process


Published on

Published in: Education
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • Software Development Process

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