Software Development Methodologies
0 likes101 views
The document discusses various software development methodologies including Agile, Scrum, XP, Kanban, Lean, Crystal, DSDM, FDD, V-Model, Incremental Model, Evolutionary Prototyping, Cowboy Coding, and Personal Software Process. It describes how each methodology works, the roles involved, advantages and disadvantages. For example, it states that Agile is responsive to market changes, Scrum uses sprints, planning meetings and burndown charts, and Cowboy Coding lacks structure but allows for experimentation.
Software Development Methodologies
- 2. We are WeylandCorp. Frances Coronel, Brandon Richards, Justin Havens, Jordan Quick, Charles Cephas Hello!
- 3. Agile Development Way better than Waterfalling. 1
- 4. Description ◉ How does it work? ◉ Why is it the most popular? ◉ What are the roles involved? ◉ What is the planning process? ◉ What are the meetings about?
- 5. “ What is Agile? Agile is a process of product development that is responsive to market changes and changing needs of the business in a timely and iterative fashion.
- 6. “ Why is it such a buzzword? In the beginning, there was Waterfall. Waterfall was slow, clunky, and not able to cope with change since it focused on long, detailed specifications, strict, planning, and sticking to the plan.
- 8. Disadvantages Insufficient training Teams may not be focused if the PM isn’t providing key leadership. There are no actual rules, just prescribed methodologies. Testing integrated throughout lifecycle Meaning developers have to do extra work to complete a sprint. However, CI helps with this. Potentially low requirements There is a lack of architecture since Agile doesn’t support extensive documentation. Trying too hard in a sprint If a sprint has too much work being assigned to the developers, there will be technical debt.
- 11. ASD ● focused ● feature based ● iterative ● timeboxed ● risk driven ● change tolerant
- 12. ASD Speculate LearnCollaborate ● project is initiated ● adaptive cycle planning is conducted ● adapting to the uncertain surrounding mix of changes caused by various factors ● short iterations with design, build and testing
- 13. Crystal ● lightest methodology that will still lead to successful projects ● supports fixed price constraints ● teams can use techniques from other methodologies ● requires documentation but is not strict about what that entails
- 14. DSDM (Dynamic Systems Development Method) ● Focus on the business need ● Deliver on time ● Collaborate ● Never compromise quality ● Build incrementally from firm foundations ● Develop iteratively ● Communicate continuously and clearly ● Demonstrate control
- 15. FDD (Feature Driven Development) ● blends a number of industry-recognized best practices into a cohesive whole ● practices are all driven from a client- valued functionality feature perspective ● its main purpose is to deliver tangible, working software repeatedly in a timely manner
- 16. Kanban ● less strict than Scrum ● visualize the workflow by splitting work into pieces and putting it in cards ● limits work in progress by assigning time limits ● measure the lead time (average time to complete one item)
- 17. Lean ● relentlessly eliminate anything that doesn’t add value and only work on what we absolutely need to be doing ● eliminating useless meetings, tasks, and documentation ● emphasis on fast delivery ● eliminate waste, build quality, defer commitment, respect people, optimize whole, deliver fast
- 18. CEO What Peter Thiel was for Facebook co-CTO co-CTO CFO
- 20. XP (Extreme Programming) ● Elements ○ The Planning Game ○ Acceptance Tests ○ Small Releases ○ Continuous Integration ○ Pair Programming ● frequent "releases" in short development cycles ● improves productivity and introduces checkpoints where new customer requirements can be introduced
- 21. Scrum Roles ArtifactsCeremonies ● Product Owner ● Scrum Master ● Team ● Sprint planning ● Sprint review ● Sprint retrospective ● Daily scrum meeting ● Product backlog ● Sprint backlog ● Burndown charts
- 24. Product Owner/Product Manager ● defines product features ● decides release date and content ● responsible for ROI ● prioritizes features based on market value ● accepts/rejects work results ● adjusts features/priorities every iteration, as needed
- 25. Scrum Master ● represents management to project ● responsible for enacting scrum values and practices ● removes impediments ● ensures team is fully functional/productive ● enables close cooperation across all roles/functions ● shields team from external interferences
- 26. Team ● typically 5-9 people ● cross functional ○ programmers, testers, UX designers ● members work full-time ● teams are self-organizing ● membership only changes between sprints
- 27. Sprint Planning Meeting ● team selects items from product backlog they can actually try to complete ● sprint backlog is created ○ tasks identified and each one is given a time estimate for 1 to 16 hours ● high level design is considered
- 28. Daily Scrum Meeting ● daily, 15 minutes, stand up ● not for problem solving ● helps avoid other unnecessary meetings afterwards ● 3 key questions ○ what did you do yesterday? ○ what will you do today? ○ is anything in your way?
- 29. Sprint Reviews/Retrospectives ● team presents what’s accomplished during sprint ● demo of new features/underlying architecture ● informal ● whole team participates ● typically takes 15-30 minutes ● done after every sprint
- 31. “ Conclusion? Agile is all about delivering maximum value in the minimum amount of time.
- 33. Evolutionary Prototyping ◉ Lifecycle model where the system is developed in increments ◉ Concept is developed as the project is brought along ◉ Demonstrate the software to the client then continue to develop based on the feedback received
- 35. Advantages Ability to address risk early on in project lifecycle. Early feedback on whether the final product will be accepted. Visible progress throughout the project. Evolutionary Prototyping Disadvantages Unrealistic schedules and budget expectations. Inefficient use of prototyping, poor design, unrealistic system performance expectations.
- 36. V-Model
- 37. V-Model ◉ V-Model is a SDLC that can be considered an extension of the waterfall method ◉ It is based on association of a testing phase for each corresponding development stage ◉ This model is highly disciplined and the next phase can only begin after completion of the previous phase.
- 38. V-Model
- 39. Advantages Highly Disciplined and phases completed one at a time. Works well with smaller projects. Simple and easy to use. Easy to manage due to rigidity of the model. All phases have a review process and deliverables. V-Model Disadvantages High risk as well as uncertainty. Not a good model for complex and object oriented projects. Poor model for long and ongoing projects. Not suitable for projects where requirements have a higher risk of changing. Once in testing stage hard to go back. No working product till late in the lifecycle
- 41. Incremental Model ◉ A method of software development where the product is designed, implemented, and tested a bit at a time until it is completed. ◉ It involves development and maintenance and is defined as finished when all requirements are satisfied. ◉ This model combines elements of the waterfall model with the iterative philosophy of prototyping.
- 42. Tasks Involved
- 43. Advantages ◉ After each iteration regression testing should be conducted, which in turn causes elements that are malfunctioning to be identified simply because few changes are made with any single iteration. ◉ It is also generally easier to test and debug with this method of software development because smaller changes are made during each iteration as well. ◉ Customers can also respond to features and review the product for any changes that may be needed. ◉ Lower initial delivery costs.
- 44. Disadvantages ◉ The resulting costs may exceed the price range of the corporation. ◉ Each phase of an iteration is rigid and do not overlap one another. ◉ As additional functionality is added to the software product, issues may arise that are related to system architecture that were not evident in the earlier product prototypes.
- 45. Cowboy Coding
- 46. Cowboy Coding ◉ A method of software development where programmers have autonomy over the development process. ◉ The autonomy includes the control of the project’s schedule, languages, algorithms, tools, frameworks and coding style.
- 47. Cowboy Coding A cowboy coder can be the lone developer of a group or part of a group of developers working with minimal process or discipline. It usually occurs when there is very little participation by business users or by management that controls non- development aspects of the project. Cowboy Coding Is commonly seen as a derogatory term by supporters of other software development methodologies.
- 48. Advantages Environment Developers maintain a free form working environment that can encourage experimentation, learning, and free distribution of the results. Design Resolutions Allows for developers to cross architectural and/or tiered boundaries to resolve design limitations and defects. Free Thinking Coding would be completed during the developer’s free time, which allows for a hobby project to come to fruition which otherwise may not.
- 49. Disadvantages Lack of Release Structure Lack of estimation or implementation planning can cause a project to be delayed. Uncertain Design Requirements Custom software applications can experience issues with the client’s requirements. Cowboy Coding can increase this problem by not scaling the requirements to a reasonable timeline, which can result in a rushed and bug filled product. Inexperienced Developers Common at the hobbyist or student level where developers may not be as familiar with the technologies. This can result in learning time to be underestimated, which can cause delays in development.
- 51. PSP improves an individual
- 52. Personal Software Process ◉ “ A flexible historical data-driven process tailored to teaching individuals about their own unique programming styles and even help software engineers further develop their skills in writing quality software with few defects.” ◉ Provides engineers with a disciplined personal framework for doing software work ◉ The PSP process consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work.
- 53. Purpose of the PSP PSP helps software engineers to: ● Improve their estimating and planning skills. ● Make commitments they can keep. ● Manage the quality of their projects. ● Reduce the number of defects in their work.
- 54. Advantages Of PSP ◉ The data and analyses will offer an appreciation of strengths and weaknesses ◉ Gain a Sense of Personal accomplishment ◉ Have total control over schedule and the commitments you make ◉ The Quality portion will help produce better products ◉ Builds team’s confidence in you
- 55. Disadvantages of PSP ◉ Not every engineer views productivity the same way ◉ Strictly is aimed for the development of software and not the time spent negotiating with clients ◉ PSP doesn't force the user to timestamp disruptions
- 57. Team Software Process ◉ “Provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code.” ◉ Guides Engineering Teams that are developing software- intensive products
- 58. TSP Improves Individuals and Teams
- 59. Advantages of TSP ◉ Productivity improvements of 25% or more ◉ Reductions in cost and schedule variance to less than +/- 10% ◉ Testing costs and schedule reductions of up to 80% ◉ Helps Organizations make a mature and disciplined engineering proactive that makes reliable software
- 60. Disadvantages of TSP ◉ Training is Long and may hold back in-depth coverage of content ◉ Teams may not retain as much information as they need for full participation ◉ Some training that is needed may not be provided
- 61. Waterfall Model
- 62. Description ◉ The waterfall model was the first process model to be introduced in software development. ◉ Begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software. ◉ Each phase must be completed before the next phase can begin and there is no overlapping in the phases.
- 63. Phases in the Waterfall Model
- 64. Description of Phases Implementation Product is first developed in small programs which are later integrated. Each unit is developed and tested for functionality. Requirements All possible requirements of the system to be developed are gathered and documented. System Design Helps specify hardware and system requirements along with defining the overall system architecture. Integration & Testing All of the units developed are integrated and after integration the entire system is tested. Maintenance Intended to enhance the product. Later versions and patches are released as issues arise in the client environment.
- 65. Advantages ◉ Easy to manage as each phase has specific deliverables and a review process. ◉ Phases are completed one at a time. ◉ Works well for smaller projects where requirements are well understood. Waterfall Model Disadvantages ◉ Not ideal for long and ongoing projects as you can’t go back to a previous phase ◉ Difficult for customer to state all requirements. ◉ A working version of the product will not be available until late in the process.
- 66. Spiral Model
- 67. Description ◉ The spiral model is a software process model that brings together the iterative aspect of prototyping and the controlled and systematic aspects of the waterfall model together. ◉ Provides the potential for rapid development of more complete versions of the software.
- 68. How it works ◉ Using the spiral model, software is developed in a series of incremental releases. ◉ During early iterations, the release might be a prototype and during later iterations the product evolves into its complete form. ◉ There are four phases associated with the spiral model. A software project repeatedly passes through these phases in iterations called spirals.
- 69. Identification Phase Starts with gathering the business requirements in the baseline spiral. In the later spirals as the product matures, identification of system requirements, subsystem requirements, and unit requirements are all done in this phase. Spiral Model Phases Design Phase Starts with the conceptual design, logical design of modules, physical product design and final design in the later spirals.
- 70. Build Phase In the baseline spiral, it consists of a proof of concept to gather customer feedback. In the later spirals with more clarity on requirements and design, a working model of the software is produced with a version number. Each build is sent to the customer for feedback. Spiral Model Phases Continued Evaluation and Risk Analysis Includes estimating, identifying, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of the first iteration, the customer evaluates the software and provides feedback.
- 71. Advantages ◉ Allows elements of the product to be added in as they become available. ◉ Assures there is no conflict with previous requirements and design. ◉ Users are allowed to see the system early. Spiral Model Disadvantages ◉ It takes strict management to complete products. ◉ The spiral can run in an indefinite loop. ◉ Intermediate stages requires a lot of documentation.
- 72. “ Is software engineering an oxymoron?
- 73. YES. Software engineering isn't really engineering. If it was, then we would have clear and definite methodologies for doing everything. When a civil engineer has to design a bridge, he has a loading in mind, a safety margin, specific materials, and several design alternatives. He can evaluate those alternatives in a quantifiable way to determine which is optimal. Software engineering, on the other hand, has significant factors that are an art. Yes, obviously generating the code to get the right result is a function of basic programming, and that is certainly an engineering skill, but creating the architecture that will be optimal requires a certain level of insight and taste that is beyond anything that can be found in a formula. In other engineering disciplines, this is more clear. Was Ming Pei an engineer? How is an architect different from a mechanical engineer?
- 75. References ● http://www.construx.com/uploadedFiles/Construx/Construx_Pages/Resources(1)/Evolutionary%20Prototyping% 20Lifecycle.pdf ● http://www.tutorialspoint.com/sdlc/sdlc_v_model.html ● http://cdn.oreillystatic.com/en/assets/1/event/3/Agil e%20Development%20Presentation.pdf ● http://www.slideshare.net/ydarias/agile-and-scrum- 35714242 ● http://www.mountaingoatsoftware.com/uploads/pr esentations/English-Redistributable-Intro-Scrum.ppt ● https://www.sei.cmu.edu/tsp/ ● http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5283 ● https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf ● http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/ ● http://www.moweble.com/the-pros-and-cons-of-cowboy-coding.html
- 76. Any questions, comments, or concerns ? Thanks!