The purposes of the project are:

•  to try in practice Software Engineering methods and tools learned in class and in laboratory;
•  to design a software tool for maintaining a pseudocode developed for software design;
•  to learn how to work in a team, how to plan software design process, how to communicate within the team, how to arrange inspections  of    the  design.

Deliverables.

The following objects should be presented at the end of the Final Project:

• Requirement Specification Document that describes the problem to be solved, inputs, outputs, and other descriptions necessary to start design; a prototypes of the input and output files should be designed for this purpose;
• Design Description Document that includes detailed description of the data (input, output and internal files and global variables), the system decomposition in modules, the module specifications (function of the module and interface description), the data flow diagram, the work schedule and how responsibilities are distributed between team members. Listings of the program source text (C is the preferred language, unless all team members agree to use another language, such as C++ or Java) should be appended to the Design Document upon completition of the project. (See Appendix for more detail);
• User Manual describing input, output, function, and commands from the user's point of view. This document should contain also a detailed description of a representative example, including input data, commands that have to be executed to process this data, and expected output. This example will be used for the project final presentation;
• Testing Plan and test cases description;
• Evaluation of effort of each team member.

It is supposed that ALL pertinent project documentation will be maintained in the team's public directory and the documentation will be held in the form of HTML files available for browsing by reviewers from other teams and for the course instructor.

Terms.

Final project starts at March 2, 2000 and absolute deadline is May 12, 2000. The delivered system will be assessed by executing it on tests. The final grade for the project will be composed from the grades obtained for presentations at walkthrough sessions, for reviewing activities, and for quality of the project documentation and code. It is expected that the team will contain 5-6 people, and each team member will make a presentation at least once, at least once will be a reviewer for another team presentation, will be responsible for at least one document mentioned above, and will contribute at least one module and/or test case set for the project.
The max total individual grade for the project is 100 points which is obtained from the following grades:

• design of the project parts and presentation at the team's inspection session - 30 points,
• reviewing of another team presentation - 20 points
• personal contribution for the project in the form of a designed and tested module and/or designed and executed test case set - 30  points
• delivery of a working system as a result of a team work - 20 points (if the team work does not result in a system that can be demonstrated on  atleast one representative example, you'll miss these points).

Short description of the problem.

The pseudocode may be an essential part of a software system design. For a large system the size of the pseudocode text may be quite significant and although computer can not help too much in the design of the pseudocode itself, it can be helpful for maintaining pseudocode files and performing different kinds of auxiliary processing, making it easier for humans to maintain and access the design.

It is expected that the system will be able to support at least the following functions:

• maintain a data base of pseudocode files related to some software design project, provide an automatic bookkeeping for such attributes of the pseudocode as date, file name, version #, history of modifications, etc.;
• pretty-print the pseudocode files using appropriate layout (indentation, spaces, blank lines, page headers and page numbers, date, etc.), provide a unique identification for the pseudocode lines;
• provide some basic statistics about the pseudocode maintained in the data base: total number of lines, total number of pseudocodes, McCabe complexity of the pseudocode, current depth of refinement, estimated number of LOC derived from the pseudocode, check compliance with the Straud number, etc.;
• check the pseudocode for completeness, report number of unrefined pseudocodes, mark unrefined pseudocodes in the listing;
• provide reasonable error and warning messages about inconsistencies detected in the pseudocodes stored in the data base, e.g. double definition of a pseudocode, missing keywords, etc.
• generate from the data base a set of HTML files which can be browsed by users and contain the pretty-printed pseudocode (different fonts may be used to improve the readability) with hyperlinks that makes it easier to read, an index, and a cross-reference tables.

Input.

The main pseudocode data base contains plain text files with the pseudocode texts created using common text editors and a number of auxiliary files generated by the system to maintain the data base. There should be some syntactic requirements regarding the form of pseudocode input to the system: some conventions regarding reserved keywords (IF-THEN-ELSE-FI, WHILE-DO-OD, etc.), delimiters (';' for the sequence), and comments (e.g. to maintain the version #, the date, etc.).
The system should provide a reasonable error diagnostics for input pseudocode files.
There should be some simple user interface to perform commands, such as to generate pretty-printed version of a pseudocode file, generate HTML files, etc.

Output.

The program should generate a set of files in HTML format that could be browsed by any WWW browser, such as NETSCAPE or Internet Explorer (laboratory 8 will be devoted to HTML language.)
The generated HTML file when browsed should provide different views on the data base, using indentation, fonts and blank lines to stress the structure of the descriptions. Clicking on the corresponding object should bring on the screen the definition of the object.
These views should include at least the following:

• list of all pseudocodes (in alphabetical order) currently available in the data base;
• access to the pseudocode definitions;
• statistics about current state of the data base: total number of files, total number of lines, total number of pseudocodes, McCabe complexity of the pseudocode, current depth of refinement, estimated number of LOC derived from the pseudocode, etc.

Recommended distribution of responsibilities between team members:

It is expected that the team will contain 5-6 members. In order to distribute the load within team it is recommended to assign team members specific tasks in the Project Documents design, presentations at the inspection sessions, and in the design, coding and testing of separate modules.

• Design of Requirements Specification Document (1-2 people)
• Design of program architecture, main data structures and system decomposition into modules, Design Description document (1-2 people)
• User manual (1 person)
• Testing Plan and test cases description (1-2 people)

Appendix.

All documents should contain:

• Document name, version number, date, and authors names,
• Table of Contents,
• Index.

Topics to include:

• Detailed description of input and output (including grammars to describe syntax of input data) and functionality of the system
• Examples of input and corresponding output
• Description of commands
• Complete list of errors to be detected by the system and messages to be reported

Topics to include:

•  Data Flow Diagram
• Files structure description (at the implementation level, i.e. corresponding C declarations)
• Global Variables (at the implementation level), it is recommended to isolate definitions and access functions to the global variables (tables, lists etc.) in separate modules (e.g. in C header files)
• Modules: function and interface description (at the implementation level)
• Top-level pseudocode (and/or Flow Chart)
• Module Call Diagram
• User interface: how to call the whole system, parameters, messages
• Work Schedule, responsibilities of team members, milestones
• the programming should be performed preferably in the C programming language

This document mainly follows descriptions of input, output and commands presented in previous documents, describes how to use the system, what are the requirements to the environment, etc., from the user's point of view. Contains detailed description of the main example and other examples (if necessary) to help user to start with the system.

Testing Plan and Test Cases

Contains detailed description of test groups, presenting the purpose of each test set (e.g. to test correct inputs, to test syntactically incorrect inputs, to test different commands and command parameters, to test different types of output files, etc.), and list of testing factors to be tested by this test set. Includes test cases to test erroneous data and commands. Includes description of testing schedule.

Program Listings

Program texts should be arranged according to the good readability rules (comments, layout, mnemonics). Program Listings are attached as a supplement to the Design Document.