The document describes the Waterfall model of software development. It lists the five steps as requirements, design, implementation, testing, and maintenance. It then discusses pros and cons of the Waterfall model, noting that it provides structure but can restrict flexibility. For an assignment to develop an online booking system, the leader would choose an Agile methodology. Agile allows for interaction with clients, flexibility to change requirements, and quick production of working components.
The document describes the Waterfall model of software development. It lists the five steps as requirements, design, implementation, testing, and maintenance. It then discusses pros and cons of the Waterfall model, noting that it provides structure but can restrict flexibility. For an assignment to develop an online booking system, the leader would choose an Agile methodology. Agile allows for interaction with clients, flexibility to change requirements, and quick production of working components.
The document describes the Waterfall model of software development. It lists the five steps as requirements, design, implementation, testing, and maintenance. It then discusses pros and cons of the Waterfall model, noting that it provides structure but can restrict flexibility. For an assignment to develop an online booking system, the leader would choose an Agile methodology. Agile allows for interaction with clients, flexibility to change requirements, and quick production of working components.
The document describes the Waterfall model of software development. It lists the five steps as requirements, design, implementation, testing, and maintenance. It then discusses pros and cons of the Waterfall model, noting that it provides structure but can restrict flexibility. For an assignment to develop an online booking system, the leader would choose an Agile methodology. Agile allows for interaction with clients, flexibility to change requirements, and quick production of working components.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1of 2
Homework Assignment 1
The steps in the Waterfall model are thus:
Requirements Requirements are as specified and documented (requirement specification). Includes functional requirements (determines behavior), and non- functional requirements (reliability, usability, maintainability, etc.) Design The how of the development process. The blueprint of the software is created and documented (for others to see, such as stakeholders). The low-level aspect of the software is also specified, such as algorithms and data structures. Implementation Coding. This step is when software is made. Testing Testing the software before release. A number of testing methods such as unit testing, system testing, black-box testing, etc. can be used. Maintenance Fixing issues or improving performance after release.
Pros and cons of the Waterfall model: Pros: Outlines and abstracts crucial aspects of the software development process Brought about a structured way of development software, whereas in the past software was developed somewhat haphazardly. Requirement specifications, design specifications, the code, and test documentation are deliverable, meaning stakeholders can have access to information about the software. Customers and developers agree on requirements and design early in development Cons: The steps of the Waterfall model, if followed sequentially, restricts developers when they could follow another process. Requirements may change later when implementing or designing the software. In this case, the idealized Waterfall model would be ineffective. The limitations of the design may not be known until later. Stakeholders may not be aware of the nuances of the technology being used, thus their expectation (requirement) may not be realistic.
Suppose you are the leader of a team of 10 people to develop an online booking system. Briefly explain how you will develop the software based on one of the models introduced in the class or any models you can find on the Web.
If I were a leader of such team, I would choose to use the Agile methodology for the following reasons: 1. I don't expect the online booking system to be a large-scale project, so Agile will be better suited than, say, the Waterfall method. 2. I could divide my team up to work on specific, working components. For every block of allotted time, I could have more than one component being worked on, and ensure that they interact with each other appropriately through the requirement spec. 3. Agile allows high level of interaction with the client. Flexibility in making changes throughout the project. 4. The ability to quickly produce something that works.
I would do something like this: First, I would try to get as much specific detail from the client as much as possible. The requirements are specified, and it's important here to note which requirements are subject to change by the client later.
The requirements can then be used to determine how the software is going to be broken down, and which tools are appropriate for each component and the system of such components. From here, a part of the team can get to designing and coding certain components that is determined to be necessary. For example, given the requirements, a part of the team can go ahead and design and code a component dealing with the database and caching. Other components can be designed and implemented in such a manner. Individual components can be tested to see if it produces desired results, and if it behaves properly with the rest of the software.
Time can be allocated in blocks, and at the end of such blocks, the team is expected to have completed their tasks. From here, the progress of the project can be assessed, the client can be clued in on what had been done, re-prioritizing tasks if necessary, and the next sprint begins. The team may be split up again, and maybe some need more time than one block of time. For example, the database component of the software is not complete, but there needs to be a working component for other parts of the app to function. In this case, the database component becomes a priority, and perhaps it is rushed to make some working component (skip the caching for now! Just make something that works!). Any such event is documented. Hopefully in the end, it doesn't all fall apart.