Fluent Essays

525W2 Assignment 1 - Agile versus Waterfall Assignment 1: Agile versus Waterfall Worth 110 points The following resources may be helpful when completing this assignment: “WATERFALL vs. AGILE METHODOLOGY” (You may also view the article at http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/.) “Understanding the pros and cons of the Waterfall Model of software development” (You may also view the article at http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/6118423.) “Transitioning from waterfall to iterative development” (You may also view the article at http://www.ibm.com/developerworks/rational/library/4243.html.) Agile approach to project management has become more and more popular in recent years. Agile framework is different from traditional waterfall model. It has considerable impact on how projects are planned and executed. Imagine that you have been assigned as a project manager to manage your company’s e-Commerce Website where customers can browse the company’s products, place orders, and interact with the company’s customer service representatives. Your project must be completed in three (3) months and you have about twelve (12) people in the team. There are three (3) offshore developers in Ireland and two (2) QA testers in Dallas, TX. The rest of the project team and the product owner are in San Diego, CA. Write a five to six (5-6) page paper in which you: Compare and contrast agile and Waterfall models of managing a project in the context of building an e-Commerce Website. Include diagrams or tables through the use of graphical tools in Microsoft Word or Visio, or an open source alternative such as Dia to show the differences and similarities. Note: The graphically depicted solution is not included in the required page length. Evaluate the pros and cons in agile and Waterfall project management in terms of planning and the execution of projects and collaboration among project team members. Determine whether you would use an “Agile” or “Waterfall” model to manage the project for your company. Support your rationale. Identify and analyze the major pitfalls and misconceptions inherited in your chosen approach. Propose key actions that you, as a project manager, could take in order to mitigate the risks associated with the previously identified misconceptions. Use at least three (3) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources. You may use the resources above or others of your choosing. Your assignment must follow these formatting requirements: Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions. Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length. Include charts or diagrams created in Visio or one of their equivalents such as Dia and OpenOffice. The completed diagrams / charts must be imported into the Word document before the paper is submitted. The specific course learning outcomes associated with this assignment are: Compare and contrast agile project management methods with traditional project management. Use technology and information resources to research issues in advanced agile project management topics. Write clearly and concisely about advanced agile project management topics using proper writing mechanics and technical style conventions. Click here to view the grading rubric. w2_assignment_1___agile_versus_waterfall_.docx transitioning_from_waterfall_to_iterative_development.pdf understanding_the_pros_and_cons_of_the_waterfall_model_of_software_development___techrepublic.pdf waterfall_vs._agile_methodology___agile_introduction_for_dummies.pdf Unformatted Attachment Preview 525W2 Assignment 1 - Agile versus Waterfall Assignment 1: Agile versus Waterfall Worth 110 points The following resources may be helpful when completing this assignment: • “WATERFALL vs. AGILE METHODOLOGY” (You may also view the article at http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/.) • “Understanding the pros and cons of the Waterfall Model of software development” (You may also view the article at http://www.techrepublic.com/article/understanding-the-pros-and-consof-the-waterfall-model-of-software-development/6118423.) • “Transitioning from waterfall to iterative development” (You may also view the article at http://www.ibm.com/developerworks/rational/library/4243.html.) Agile approach to project management has become more and more popular in recent years. Agile framework is different from traditional waterfall model. It has considerable impact on how projects are planned and executed. Imagine that you have been assigned as a project manager to manage your company’s e-Commerce Website where customers can browse the company’s products, place orders, and interact with the company’s customer service representatives. Your project must be completed in three (3) months and you have about twelve (12) people in the team. There are three (3) offshore developers in Ireland and two (2) QA testers in Dallas, TX. The rest of the project team and the product owner are in San Diego, CA. Write a five to six (5-6) page paper in which you: 1. Compare and contrast agile and Waterfall models of managing a project in the context of building an e-Commerce Website. Include diagrams or tables through the use of graphical tools in Microsoft Word or Visio, or an open source alternative such as Dia to show the differences and similarities. Note: The graphically depicted solution is not included in the required page length. 2. Evaluate the pros and cons in agile and Waterfall project management in terms of planning and the execution of projects and collaboration among project team members. 3. Determine whether you would use an “Agile” or “Waterfall” model to manage the project for your company. Support your rationale. 4. Identify and analyze the major pitfalls and misconceptions inherited in your chosen approach. Propose key actions that you, as a project manager, could take in order to mitigate the risks associated with the previously identified misconceptions. 5. Use at least three (3) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources. You may use the resources above or others of your choosing. Your assignment must follow these formatting requirements: • Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions. • Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length. • Include charts or diagrams created in Visio or one of their equivalents such as Dia and OpenOffice. The completed diagrams / charts must be imported into the Word document before the paper is submitted. The specific course learning outcomes associated with this assignment are: • Compare and contrast agile project management methods with traditional project management. • Use technology and information resources to research issues in advanced agile project management topics. • Write clearly and concisely about advanced agile project management topics using proper writing mechanics and technical style conventions. Click here to view the grading rubric. 1/13/2020 Transitioning from waterfall to iterative development IBM Developer Topics Community More open source at IBM IBM and Red Hat — the next chapter of open innovation. Learn More > This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed. Contents Learn › Rational Introduction Transitioning from waterfall to iterat development Advantages of an iterative approach Four steps for a transition Many ways to apply these steps Notes Per Kroll Published on April 16, 2004 Downloadable resources Comments https://www.ibm.com/developerworks/rational/library/4243.html 1/10 1/13/2020 Transitioning from waterfall to iterative development Most software teams still use a waterfall process for development projects. Taking an extreme w you complete a number of phases in a strictly ordered sequence: requirements analysis, design and then testing. You also defer testing until the end of the project lifecycle, when problems ten resolve; these problems can also pose serious threats to release deadlines and leave key team periods of time. In practice, most teams use a modified waterfall approach, breaking the project down into two o called phases or stages. This helps to simplify integration, get testers testing earlier, and provid status. This approach also breaks up the code into manageable pieces and minimizes the integr and drivers, required for testing. In addition, this approach allows you to prototype areas you de feedback from each stage to modify your design. However, that runs counter to the thinking beh Contents Many design teams would view modifying the design after Stage 1 as a failure of their initial des And although a modified waterfall approach does not preclude the use of feedback, it does not Introduction encourage it. And finally, the desire to minimize risk does not typically drive a waterfall project. Advantages of an iterative approach improvements that an iterative approach to the software development process offers over the Four steps for a transition Many ways to apply these steps Advantages of an iterative approach Notes In contrast, an iterative approach -- like the one embodied in IBM Rational Unified Process® or Downloadablesteps, resources incremental or iterations. Each iteration includes some, or most, of the development disc analysis, design, implementation, and so on), as you can see in Figure 1. Each iteration also has Comments objectives and produces a partial working implementation of the final system. And each succes work of previous iterations to evolve and refine the system until the final product is complete. Early iterations emphasize requirements as well as analysis and design; later iterations emphas testing. Figure 1: Iterative development with RUP. Each iteration includes analysis, design, implementation and testing activities. Also, eac the work of previous iterations to produce an executable that is o final product. The iterative approach has proven itself superior to the waterfall approach for a number of reas https://www.ibm.com/developerworks/rational/library/4243.html 2/10 1/13/2020 • Transitioning from waterfall to iterative development It accommodates changing requirements. Changes in requirements and feature creep -are technology- or customer-driven -- have always been primary sources of project trouble, dissatisfied customers, and frustrated developers. To address these problems, teams who u on producing and demonstrating executable software in the first few weeks, which forces a helps to pare them down to essentials. • Integration is not one big bang at the end of a project. Leaving integration to the end alm consuming rework -- sometimes up to 40 percent of the total project effort. To avoid this, ea integrating building blocks; this happens progressively and continuously, minimizing later re • Early iterations expose risks. An iterative approach helps the team mitigate risks in early ite for all process components. As each iteration engages many aspects of the project -- tools, Contents members skills, and so on -- teams can quickly discover whether perceived risks are real an not suspect, at a time when these problems are relatively easy and less costly to address. Introduction • Management can make tactical changes to the product. Iterative development quickly pro Advantages of an iterative approach architecture (albeit of limited functionality) that can be readily translated into a lite or mo Fourrelease steps fortoa counter transitiona competitors move. • It facilitates reuse. It is easier to identify common parts as you partially design or impleme Many ways to apply these steps recognize them during planning. Design reviews in early iterations allow architects to spot p Notes reuse, and then develop and mature common code for these opportunities in subsequent ite • You can find and correct defects over several iterations. This results in a robust architectu Downloadable resources application. You can detect flaws even in early iterations rather than during a massive testin Comments can discover performance bottlenecks when you can still address them without destroying y panic on the eve of delivery. • It facilitates better use of project personnel. Many organizations match their waterfall app organization: Analysts send the completed requirements to designers, who send a complete send components to integrators, who send a system for test to testers. These multiple hand misunderstandings; they also make people feel less responsible for the final product. An ite wider scope of activities for team members, allowing them to play many roles. Project mana staff and eliminate risky handoffs. • Team members learn along the way. Those working on iterative projects have many opport development lifecycle to learn from their mistakes and improve their skills from one iteratio each iteration, project managers can discover training opportunities for team members. In c waterfall projects are typically confined to narrow specialties and have only one shot at des • You can refine the development process along the way. End-of-iteration assessments not project from a product or scheduling perspective; they also help managers analyze how to i and the process in the next iteration. https://www.ibm.com/developerworks/rational/library/4243.html 3/10 1/13/2020 Transitioning from waterfall to iterative development Some project managers resist adopting an iterative approach, seeing it as a form of endless, un RUP the entire project is tightly controlled. The number, duration, and objectives of iterations ar tasks and responsibilities of participants are well defined. In addition, objective measures of pr the team does rework some things from one iteration to the next, this work, too, is carefully con Four steps for a transition Most waterfall projects divide the development work into phases or stages; we can also view th iterative design. But then, to move to an iterative approach, we would apply different process p Contents four steps: Introduction 1. Build functional prototypes early. Advantages of an iterativedesign, approach 2. Divide the detailed implementation and test phases into iterations. 3. Baseline antransition executable architecture early on. Four steps for a 4. Adopt an iterative and risk-driven management process. Many ways to apply these steps Lets Notesexamine each of these steps more closely. Downloadable resources Step 1: Build functional prototypes early Comments As a first step toward iterative development, consider one or more functional prototypes during phases. The objectives of these prototypes are to mitigate key technical risks and clarify stakeh the system should do. Start by identifying the top three technical risks and the top three functional areas in need of cla might relate to new technology, pending technology decisions that will greatly affect the overal requirements that you know will be hard to meet. Functional risks might relate to areas in which fuzzy requirements for critical functionality, or to several requirements that are core to the syste For each of the key technical risks, outline what prototyping you need to do to mitigate the risks examples: Technical risk: The project requires porting an existing application to run on top of IBM WebSph are already complaining about the applications performance, and you are concerned that portin even more. https://www.ibm.com/developerworks/rational/library/4243.html 4/10 1/13/2020 Transitioning from waterfall to iterative development Prototype: Build an architectural prototype to try out different approaches for porting your app WebSphere architect to help you. Evaluate the results and write architectural and design guidel dos and donts. This will increase the likelihood that your ported applications performance will rework late in the project. Technical risk: You are building a new application for scheduling and estimating software proje differentiator for this application versus off-the-shelf products will be how well it supports itera also one of the fuzziest areas in your requirement specification. Prototype: Build a functional prototype based on your assumptions about how to support iterat Contents demonstrating the prototype to various stakeholders, you will encourage them to pay more atte which of your assumptions they agree or disagree with. The prototype will help you clarify the p Introduction provide you with useful information about the user experience and look and feel for your applic reusable code. Advantages of an iterative approach Four steps for a transition Step 2:toDivide the detailed design, implementation and test phas Many ways apply these steps Notes project teams find it hard to divide a project into meaningful iterations before they know w Many But when youresources are ready to enter the detailed design phase, you typically have a good understan Downloadable are, and what the architecture will look like. Its time to try out iterative development! Comments You can use two main approaches to determine what should be done in what iteration. Lets dis approach. Approach 1: Develop one or more subsystems at a time. Lets assume that you have nine subsystem numbers of components. You can divide the detailed design, implementation and test phase into thre implementing three of the nine subsystems. This will work reasonably well if there are limited depend subsystems. For example, if your nine subsystems each provided a well-defined set of capabilities to the highest priority subsystems in the first iteration, the second most important subsystems in the se approach has a great advantage: If you run out of time, you can still deliver a partial system with the m and running. However, this approach does not work well if you have a layered architecture, with subsystems in the capabilities of subsystems in the lower layers. If you had to build one subsystem at a time, such an ar build the bottom layer subsystems first, and then go higher and higher up. But to build the right capab typically need to do a fair amount of detailed design and implementation work on the upper layers, be need in the lower layers. This creates a catch-22; the second approach explains how to resolve it. Approach 2: Develop the most critical scenarios first. If you use Approach 1, you develop one subsy you focus instead on key scenarios, or key ways of using the system, and then add more of the less es https://www.ibm.com/developerworks/rational/library/4243.html 5/10 1/13/2020 Transitioning from waterfall to iterative development different from Approach 1? Lets look at an example. Suppose you are building a new application that will provide users the ability to manage defects. It is of WebSphere Application Server, with DB2 as the underlying database. In the first iteration, you deve as entering a simple defect, with no underlying state engine. In the second iteration, you add complex example, you might enable the defect to handle a workflow. In the third iteration, you complete the d providing full support for atypical user entries, such as capability to save a partial defect entry and the With this approach, you work on all the subsystems in all iterations, but you still focus in the first itera and save what is least important or least difficult for the last iteration. Approach 1 is more appropriate if you are working on a system with a well-defined architecture existing application or developing a new application with a simple architecture, for example. Mo Contents applications should use Approach 2, but they should plan the iterations in such a way that they iterations to make up for possible schedule delays. Introduction Advantages of an iterative approach Step 3: Baseline an executable architecture early on. Four steps for a transition You view this step a much more formal and organized way of doing Step 1: Build function Manycan ways to apply theseas steps what is an executable architecture? Notes An executableresources architecture is a partial implementation of the system, built to demonstrate that Downloadable support the key functionality. Even more important, it demonstrates that the design will meet re Comments capacity, reliability, scalability, and other -ilities. Establishing an executable archi throughput, the systems functional capability on a solid foundation during later phases, without fear of brea architecture is an evolutionary prototype, intended to retain proven features and those with a hi system requirements when the architecture is mature. In other words, these features will be pa contrast to the functional prototype you would typically build in step 1, the evolutionary prototy architectural issues. Producing an evolutionary prototype means that you design, implement, and test a skeleton str system. The functionality at the application level will not be complete, but as most interfaces be implemented, you can (and should) compile and test the architecture to some extent. Conduct tests. This prototype also reflects your critical design decisions, including choices about techno their interfaces; it is built after you have assessed buy versus build options and after you have d architectural mechanisms and patterns. But how do you come up with the architecture for this evolutionary prototype? The key is to foc 30 percent of use cases (complete services the system offers to the end users). Here are some https://www.ibm.com/developerworks/rational/library/4243.html 6/10 1/13/2020 Transitioning from waterfall to iterative development cases are most important. • The functionality is the core of the application, or it exercises key interfaces. The system determine the architecture. Typically an architect identifies the most important use cases by redundancy management strategies, resource contention risks, performance risks, data sec example, in a point-of-sale (POS) system, Check Out and Pay would be a key use case becau a credit card validation system -- and it is critical from a performance and load perspective. • Choose use cases describing functionality that must be delivered. Delivering an applicatio would be fruitless. For example, an order-entry system would be unacceptable if it did not a Typically, domain and subject-matter experts understand the key functionality required from behaviors, peak data transaction, critical control transactions, etc.), and they help define cri Contents • Choose use cases describing functionality for an area of the architecture not covered by a Introduction ensure that your team will address all major technical risks, they must understand each are certain of area of the architecture does not appear to be high risk, it may conceal technical diffi Advantages an iterative approach only by designing, implementing, and testing some of the functionality within that area. ... Purchase answer to see full attachment