Download as PDF, PPTX
![Understanding Parkinson’s Disease: Causes, Symptoms, and Treatment [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/understandingparkinson-251208102525-80ba3223-thumbnail.jpg?width=640&height=640&fit=bounds)
softwaredevelopmentprocess
- 1. By: Amira ElsayedIsmail
- 2. Introduction Adaptivevs. Predictive software development Traditional Software development process ◦ Waterfall model ◦ Iterative Incremental Model ◦ Spiral Model Agile Software development process ◦ Extreme Programming Model ◦ SCRUM Model Conclusion
- 3. Software Developmentprocess (lifecycle) ◦ Is a structure imposed on the development of a software product Requirements specification Analyses and Design Implementation Testing Deployment Maintenance
- 4.
- 5. Adaptive methodsfocus 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. Predictive methodfocus 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. Waterfall CleanRoom DSDM (Dynamic System Development Method) Iterative Incremental RAD (Rapid Application Development) RUP (Rational Unified Process) Spiral V-Model FDD (Feature Driven Development)
- 8. Waterfall CleanRoom DSDM (Dynamic System Development Method) Iterative Incremental RAD (Rapid Application Development) RUP (Rational Unified Process) Spiral V-Model FDD (Feature Driven Development)
- 9. Is asequential 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
- 10.
- 11. Proceeds from onephase to the next in a sequential manner You only move to next phase when the current phase is completed and perfected Time spent early in the Software production cycle can lead to greater economy at later stages A bug found in the early stages is cheaper in money , effort and time Design documents is very important as source code
- 12. 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
- 13. Why notWaterfall ◦ 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
- 14. Why notWaterfall ◦ 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
- 15. Why notWaterfall ◦ 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
- 16. Developed inresponse 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.
- 18. The basicidea 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
- 19. •Create a baseversion of the system •The goal is to create a product to which the user can react •Offer a sampling of the key aspects of the problem & provide a simple solution easily to understand and implement Initialization Step •It’s the result of the analysis phase •Include item of new features to be implemented and also the areas of redesign of the existing solution Project Control List •Redesign and implement of tasks from the control list and analyses the current system •The goal of any iteration is to be (simple, straight forward, modular and supporting redesign) Iteration Step
- 20. In a lightweight iterative project the code represent the main documentation In a mission critical iterative project a formal software design document used The analysis of iteration is based on user feedback It involves analysis of the structure modularity, usability, reliability, efficiency and achievement of goals
- 21. •Identify project scope,risks, requirements (functional and non functional), at a high level with enough details to be able to estimate Inception •Deliver a working architecture that mitigates the top risks and fulfills the non functional requirements Elaboration •Fills in the architecture with production ready code produced from analysis, design, implementation and testing Construction •Delivers the system into the production operating system Transition
- 22. Waterfall Complete each stepbefore moving to the next step Business value is delivered all at once Backtracking means waste in time, effort, money Iterative Incremental Backtracking is possible
- 23. 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
- 24. The spiralmodel 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
- 26. 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
- 27. 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
- 28. Advantages ◦ Emphasison 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.
- 29. Disadvantages ◦ Onlyintended 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.
- 30. Group ofsoftware 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
- 31. SCRUM (1995) Crystal clear Extreme Programming (1996) Adaptive software development Feature driven development Dynamic system development method (1995) Open source software development
- 32. SCRUM (1995) Crystal clear Extreme Programming (1996) Adaptive software development Feature driven development Dynamic system development method (1995) Open source software development
- 33. 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
- 34. Agile Principles Customersatisfaction by rapid delivery of useful software
- 35. Agile Principles Welcomechanging requirements even late in development
- 36. Agile Principles Workingsoftware is the principal measure of progress
- 37. Agile Principles Dailycooperation between business people & developers
- 38. Agile Principles Faceto Face conversation is the best form of communication
- 39. Agile Principles Self-organizedteam that have motivated and trusted individuals
- 40. Characteristics ◦ Breaktasks 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
- 41. Characteristics ◦ Teamis 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
- 42. Characteristics ◦ Eachteam 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?)
- 43. Techniques toimprove the quality and agility of project like: ◦ Unit test ◦ Pair programming ◦ Test driven Development ◦ Domain Driven Design ◦ Code refactoring
- 44. Its oneof the agile development methods It’s the skeleton that includes a set of practices and predefined roles
- 45.
- 46. 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
- 47. 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
- 48. 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
- 49. Team ◦ Deliverthe project ◦ Made up of (5 9) people with cross functional to do the actual work (Developers, Designers, Testers)
- 50. Users ◦ Theusers 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
- 51.
- 52. 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
- 53. 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)
- 54. 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
- 55. 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.
- 57. Daily SCRUMMeeting ◦ 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
- 58. Daily SCRUMMeeting ◦ 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?
- 59. Sprint PlanningMeeting ◦ Hold at the beginning of each sprint ◦ Decide what work is to be done ◦ Prepare the sprint backlog ◦ 8 hour limits
- 60. Sprint reviewmeeting ◦ Hold at the end of the sprint ◦ Review the complete and incomplete work ◦ Present the completed work to stockholders ◦ 4 hour limits
- 61. Sprint Retrospectivemeeting ◦ 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
- 62. Intended toimprove 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
- 64. Concepts ◦ Organizespeople 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. Activities Coding Testing ListeningDesigning
- 66. Coding ◦ Softwareinstructions 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
- 67. Testing ◦ ifa 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.
- 68. Designing ◦ Thesystem 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
- 69. Listening ◦ Programmersmust 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.
- 71. Communication ◦ Thistask 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
- 72. Simplicity ◦ Encouragesstarting 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 (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
- 73. Feedback ◦ Feedbackfrom 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
- 74. Courage ◦ Courageenables 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
- 75. Respect ◦ Therespect 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
- 76. Rules ◦ Businesspeople 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