- Both Sections: Wednesday, February 6 (11:59pm)
Homework can submitted via email or printout by deadline.
It is safety-critical that a car's anti-lock braking system work, so a method based on formal transformations (with proofs of equivalence between each stage), would be the most appropriate here. Partial credit was given for "Incremental" or "Spiral" if accompanied by a reasonable rationale. Smaller partial credit for Waterfall.
A virtual reality system would be cutting edge, and its usability would depend heavily on the quality of its user interface. One would be hard-pressed to be able to specify all the requirements in advance of design/implementation, so following a "Waterfall" or "Formal" process model would be difficult. Feedback from the users would be essential. An Evolutionary Model seems ideal here, but full credit was given to "Incremental" or "Spiral" if justified in the prose.
Since this new system will be replacing an established system, eliciting requirements in advance of design/implementation is quite feasible. The resulting system will also be quite large. Both of these conditions lead one to conclude that a Waterfall-type process model would be the most appropriate here. "Incremental" or "Spiral" received substantial partial credit.
Many suggested a reuse-oriented approach, noting that the new system could be built out of the components of the existing system. Substantial partial credit was awarded for this answer (assuming that it was motivated). While this approach could work, it relies on two assumptions: 1) that the source code to the existing is available (cannot reuse without direct access to the individual components), and 2) that there are components in the existing system worth reusing. It should be noted that the components being reused need not come from the system being replaced. Rather, the model assumes a large library of components (much like the inventory of a hardware store) that can be taken "off-the-shelf" and used to built a large system.
An interactive timetable system with a complex user interface but which must be stable and reliable. The stability/reliability implies something like "Waterfall" or at least "Incremental", but the presence of a user interface (which requires user feedback to be developed) is problematic. The best approach would probably be to employ a throw-away prototype to find requirements and then use a Waterfall or Incremental model. Partial credit was given for "Evolutionary Development". One problem with evolutionary development is that the final system might not be as robust as it needs to be. One point in its favor is that the user interface will need to evolve during development, as its requirements are refined.
When a system is produced using the evolutionary development model, features tend to be added without regard to an overriding design. With each modification, the software becomes increasingly disorganized. System maintenance (fixing bugs; or adding new features after the system has been released) is hampered by these problems, as it is harder to identify the source of bugs in poorly designed systems.
Also, keeping the documentation up-to-date over successive "evolutions" is uncommon. Poor documentation also makes maintenance more difficult.
One problem with the Waterfall model is that its rigid structure makes it difficult to adjust to change once development has begun. If it becomes imperative to release the system earlier than originally envisioned, for example, it would be hard for a Waterfall project to adapt. Because the higher priority features are introduced in earlier increments of the system, a project managed under Incremental Development could be released sooner with some of the less-important features omitted.
Systems produced under the Evolutionary Development model can react quickly to external changes as well, but suffer from reduced software quality; the lack of large-scale system design in advance of development being the chief culprit. Incremental development ameliorates this problem (one that does not plague Waterfall projects) by requiring that the system design be outlined before development begins.
While both system and acceptance testing are performed against the complete software system, system testing is performed by the contractor, while acceptance testing is performed by the customer. The former verifies that there are no problems resolving from the integration of the system components and that the implementation satisfies the requirements. Test data is often generated in order to properly exercise system features. Acceptance testing is the final test, there the system is run against real data supplied (and perhaps applied) by the customer.