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.