During the course of completing the project, each team will be required to go through several stages of planning and preparation. The completion of each stage will be evidenced by the submission of a report document, signed off by a team member, and the possible presentation of the report's material by the signing team member.
Since the approach chosen for this term involves building a system in C++ , some of the terminology in one finds in the text or other software engineering literature may be inappropriate. Classical software engineering books are mainly oriented around the view that a system is built with a functional (procedural) language, for which functional decomposition is the appropriate means of top-down design and the module is the basic, encapsulated functional unit. In an object oriented language such as C++ , functional decomposition into modules is only one aspect of design. Classes, class inheritance, entity relationships, class clusters, class inclusion of objects from other classes, polymorphic code, class interface, class services, object creation, object activity, and communication are also important.
In a functional language, data is data and function is embodied in procedures. Data and procedures bundled together with a specified interface for usage constitute a module. (In conventional C, a module is usually provided by a pair of files, a .h file that the user includes, which declares publicly available elements, and a .c file that implements these elements (possibly using private, hidden, static elements). The elements provided to the user are simple data types (data without process) and procedures (process applicable to simple data types).
In C++ , data and function may be bundled together in yet another form, as a class. Depending on your point of view, a class is data enriched by associated processes, or it is a group of cooperating processes enriched by shared data. Indeed, classes may be designed to take on the role of any conventional program element, from a data element or function through an entire subsystem. Data, furthermore, as used in this description, is not simple. The data of one class can consist of objects of other classes: bundles of data and process in their own right, and so on, extensively. Classes, moreover, may exist in hierarchies, groups of related classes that progress from the simple to the more enriched in a progression of related features. Code may be designed using only the properties of the base classes of these hierarchies yet be executed polymorphically on any object from any of the derived classes. Finally, clusters of classes (together with conventional procedures that use them) can still be bundled, in C fashion, into conventional modules.
Thus, the challenge throughout the planning process is to arrange form and function into units that have a coherent organization structure, a clearly defined set of responsibilities, and a well-designed, clean interface, and (in the case of a hierarchy), contains code written for objects from classes as near to the root of the hierarchy as possible. Such units, from here on, will be referred to as entities.
The report documents to be submitted by each team
are
the Design Plan, the Testing Plan,
the Scheduling Plan, the Maintenance and Cost Accounting Report.
The Design document will be submitted at least twice,
once before implementation begins and once, updated to reflect the
final version of the system, upon project submission.
An initial planning exercise in software development
commonly results in
the Requirements Document.
In the interests of time, requirements will have to be kept somewhat
informal.
All common understandings as to what requirements are important will
be added to a Requirements Page on the course web material.