The document provides an overview of various software development processes and models, including traditional waterfall and iterative models as well as agile methods like Scrum and Extreme Programming (XP). It discusses key aspects of each approach such as phases, roles, meetings, practices, and values. The document aims to introduce different process options and considerations for developing software.

1. Software Development ProcessBy: Amira Elsayed Ismail

2. AgendaIntroductionAdaptive vs. Predictive software developmentTraditional Software development processWaterfall modelIterative Incremental ModelSpiral ModelAgile Software development processExtreme Programming ModelSCRUM ModelConclusion

3. IntroductionSoftware Development process (lifecycle)Is a structure imposed on the development of a software product

4. Introduction (cont’d)

5. Adaptive vs. PredictiveAdaptive methods focus on adapting quickly to changeWhen the project requirement change the adapted team also changeAn adaptive team can not report exactly what tasks are being done next weekAn Example of adaptive methods is Agile

6. Adaptive vs. Predictive (cont’d)Predictive method focus on planning the future in detailsPredictive team can report exactly what features and tasks are planned for the entire length of the development processPredictive 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 MethodsWaterfallClean RoomDSDM (Dynamic System Development Method)Iterative IncrementalRAD (Rapid Application Development)RUP (Rational Unified Process)SpiralV-ModelFDD (Feature Driven Development)

8. Traditional software development MethodsWaterfallClean RoomDSDM (Dynamic System Development Method)Iterative IncrementalRAD (Rapid Application Development)RUP (Rational Unified Process)SpiralV-ModelFDD (Feature Driven Development)

9. Waterfall ModelIs a sequential design process, often used in software development processesOriginates in the manufacturing and construction industries; highly structured physical environmentsThe Idea behind the waterfall model is“Measure Twice, Cut once”

10. Waterfal Model (cont’d)Waterfall Model Phases :Waterfall Model (cont’d)

11. Waterfall Model (cont’d)Why Waterfall Provides a structured approach, it progress linearly, easily, understandable and explainableProvides easily markable milestones in the development processSuites the stable, unchanging requirements

12. Waterfall Model (cont’d)Why not Waterfall Many people think that waterfall model is a bad idea in practiceIt is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phaseClient 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 practiceIt is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phaseDesigners 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 practiceIt is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phaseStockholders may not be fully aware of the capabilities of the technology being implemented

15. Iterative & Incremental developmentDeveloped in response to the weaknesses of the waterfall modelStarts with initial planning and ends with deployment with the cycle interactions in betweenIterative & incremental development is essential parts of the extreme programming & generally the Agile DevelopmentThe project is delivered through cross discipline work from the requirement to the deployment

16. Iterative & Incremental development (cont’d)Initial PlanningDeployment

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 portionsStart with simple implementation of a subset of the software requirements and iteratively enhance the evolving version until the full system is implementedAt each iteration, design modifications are made and new functional capabilities are added

18. Iterative & Incremental development (cont’d)

19. Iterative & Incremental development (cont’d)

20. Iterative & Incremental development (cont’d)

21. Iterative & Incremental development (cont’d)

22. Iterative & Incremental development (cont’d)Implementation GuidelinesAny difficulty in design, coding & testing means the need of redesign and modificationModifications should fit easily isolated and easy to find modulesThe 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 BoehmThis model was not the first model to discuss iteration, but it was the first model to explain why the iteration mattersaims at risk reduction by any means in any phase. The spiral model is often referred to as a risk-driven modelIntroducing prototyping in a Software Process aims at risk reduction at the requirements levelThere is always an element of risk involved in the other phases of development

24. Spiral Model (cont’d)

25. Spiral Model (cont’d)Quadrant 1Determining objectives of that phase, alternatives and constraintsThis is a way to define a strategy for achieving the goals of this iterationQuadrant 2The strategy is analyzed form the viewpoint of risk, and solutions to minimize these risks are investigated

26. Spiral Model (cont’d)Quadrant 3A solution is put into practice to produce the artifacts necessary to reach the goals identified in quadrant 1Quadrant 4The results of the risk-reduction strategies are assessed, and if all risks are resolved, the next phase is planned and startedIf some risks are left unsolved, another iteration can be made to continue to work

27. Spiral Model (cont’d)AdvantagesEmphasis 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)DisadvantagesOnly 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 signedSpiral model is risk driven. Therefore it requires knowledgeable staff.Suitable for only large scale software development.

29. Agile software developmentGroup of software development methodologies based on iterative and incremental development Requirements and solutions evolve through collaboration between self organizing, cross functional teamsIntroduced in 2001It’s a light weight as a reaction against the heavy weight methods

30. Agile software development MethodsSCRUM (1995)Crystal clearExtreme Programming (1996)Adaptive software developmentFeature driven developmentDynamic system development method (1995)Open source software development

31. Agile software development MethodsSCRUM (1995)Crystal clearExtreme Programming (1996)Adaptive software developmentFeature driven developmentDynamic system development method (1995)Open source software development

32. Agile software development Methods (cont’d)Agile ManifestoWe are uncovering better ways of developing software by doing it and helping other to doAgile ValuesIndividuals & interactions over process & toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

33. Agile software development Methods (cont’d)Agile PrinciplesCustomer satisfaction by rapid delivery of useful software

34. Agile software development Methods (cont’d)Agile PrinciplesWelcome changing requirements even late in development

35. Agile software development Methods (cont’d)Agile PrinciplesWorking software is the principal measure of progress

36. Agile software development Methods (cont’d)Agile PrinciplesDaily cooperation between business people & developers

37. Agile software development Methods (cont’d)Agile PrinciplesFace to Face conversation is the best form of communication

38. Agile software development Methods (cont’d)Agile PrinciplesSelf-organized team that have motivated and trusted individuals

39. Agile software development Methods (cont’d)CharacteristicsBreak tasks into small increments with minimal planningIteration are short time frames from (1  4) weeksEach iteration involves a team working through a full software development cycleBy the end of the iteration a demo will be represented to stack holdersOne 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)CharacteristicsTeam is usually cross functional and self organizingTeam member take the responsibility of the taskFace-to-face conversation for team in the same location and video for different locations that produce less written documentsAll team working in an open office called (bullpen)Small team size from (5  9) person

41. Agile software development Methods (cont’d)CharacteristicsEach team have a customer representative to answer mid iteration problemsBy the end of the iteration stockholders view demo and re evaluate the priorities of featuresFormal 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 testPair programmingTest driven DevelopmentDomain Driven DesignCode refactoring

43. SCRUM ModelIts one of the agile development methodsIt’s the skeleton that includes a set of practices and predefined roles

44. SCRUM Model (cont’d)

45. SCRUM Model (cont’d)Pig roleThe ones committed to the project in the scrum processChicken roleNot a part of the scrum process but must be taken into account

46. SCRUM Model (cont’d)Product OwnerRepresent the voice of the customerEnsure that the scrum teams works with the write things from a business perspectiveWrite user stories, prioritize them and add them to product backlog

47. SCRUM Model (cont’d)SCRUM MasterHelp the team to deliver the sprint goalIs not the leader of the team but he is self organizerEnsure that the SCRUM process is used as intendedHe is the enforcer of rules

48. SCRUM Model (cont’d)TeamDeliver the projectMade up of (5  9) people with cross functional to do the actual work (Developers, Designers, Testers)

49. SCRUM Model (cont’d)UsersThe users of the product, and his participation is very important for feedback to review and plan sprintStockholdersThe people who enable the project and the are important in sprint reviewManagersPeople who will set up the environment for the product

50. SCRUM Model (cont’d)RequirementsUserProductOwnerProductbacklogMeetingSprintbacklogTeam

51. SCRUM Model (cont’d)Sprint(2  4) week period and it is decided by teamIn the sprint the team create an increment of usable softwareDuring the sprint no one can change the sprint backlog

52. SCRUM Model (cont’d)Product BacklogHigh level document of the entire project that include a broad description of all required features and wish list itemsPrioritized by business value of each featureEditable by anyoneContains rough estimates of both business value (product owner )and development effort (team members)

53. SCRUM Model (cont’d)Burn downThe burn down chart is publically showing remaining work in the sprint backlogUpdated every dayGive a simple view of the sprint progress

54. SCRUM Model (cont’d)Sprint BacklogFeatures are broken down into tasksBest practice that tasks are normally estimated between 4h and 16hThe whole team understand exactly the business logic of each taskAny one them can pick task from task list, tasks in the task list are never assigned

55. SCRUM Model (cont’d)

56. SCRUM Model (cont’d)Daily SCRUM MeetingProject status meetingStarts precisely on time. And there is a punishment for lateAll are welcomed but only pig may speakThe meeting is between (15 - 20) minutesAll attendees should stand to make it shortHappen in the same time, same location every day

57. SCRUM Model (cont’d)Daily SCRUM MeetingEvery one should answer three questionsWhat 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 MeetingHold at the beginning of each sprintDecide what work is to be donePrepare the sprint backlog8 hour limits

59. SCRUM Model (cont’d)Sprint review meetingHold at the end of the sprintReview the complete and incomplete work Present the completed work to stockholders4 hour limits

60. SCRUM Model (cont’d)Sprint Retrospective meetingAll team members reflects on the past sprintEvery member should answer What went well during the sprint?What could be improved in the next sprint

61. Extereme ProgrammingIntended to improve software quality and responsiveness to changing customer requirementsIntended to improve productivity and introduce checkpoints where new customer requirements can be adoptedProgramming in pairs or doing extensive code reviewUnit testing of all code (End of day testing)Avoiding programming of features until they are actually neededSimplicity and clarity in codeExpecting changes in the customer's requirementsFrequent communication with the customer and among programmers

62. ExteremeProgramming (cont’d)

63. ExteremeProgramming (cont’d)ConceptsOrganizes people to produce higher quality software more productivelyAttempts to reduce the cost of change by having multiple short development cycles, rather than one long oneIntroduces a number of basic values, principles and practices on top of the agile programming framework

64. ExteremeProgramming (cont’d)

65. ExteremeProgramming (cont’d)CodingSoftware instructions a computer can interpret. Without code, there is no working productCoding can also be used to figure out the most suitable solutionCoding can also help to communicate thoughts about programming problemsCode must be always clear and concise and cannot be interpreted in more than one wayOther programmers can give feedback on this code by also coding their thoughts

66. ExteremeProgramming (cont’d)Testingif a little testing can eliminate a few flaws, a lot of testing can eliminate many more flawsUnit tests determine whether a given feature works as intended. writes as many automated tests as they can think of that might "break" the codeif 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)DesigningThe system becomes too complex and the dependencies within the system cease to be clearAvoid this by creating a design structure that organizes the logic in the systemGood design will avoid lots of dependencies within a system

68. ExteremeProgramming (cont’d)ListeningProgrammers must listen to what the customers need the system to doThey must understand business logic needs well enough to give the customer feedback about the technical aspects of how the problem might be solved

69. ExteremeProgramming (cont’d)

70. ExteremeProgramming (cont’d)Communication This task is accomplished through documentationThe goal is to give all developers a shared view of the system which matches the view held by the users of the systemextreme 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 solutionthe focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next monthThis is sometimes summed up as the "you aren't gonna need it" (YAGNI) approachCoding and designing for uncertain future requirements implies the risk of spending resources on something that might not be neededA 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 testsFeedback from the customer: The functional tests (acceptance tests) are written by the customer and the testersFeedback 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 necessaryThis means reviewing the existing system and modifying it so that future changes can be implemented more easilycourage to remove source code that is obsolete, no matter how much effort was used to create that source code

74. ExteremeProgramming (cont’d)RespectThe respect value includes respect for others as well as self-respectProgrammers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peersMembers 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)RulesBusiness people and developers do joint workOur highest priority is customer satisfactionDeliver working software frequentlyWorking softwareGlobal awarenessThe team must act as an effective social network