ICS 125: Project in Software System Design

Fall Quarter 1999

Implementation

Due Date

As described in the course syllabus.

Overview

After finalizing your design, your team shall implement the software according to the design and requirements for your application. This implementation should be done incrementally (and will be handed in over two phases). This assignment corresponds to the initial coding phase and unit testing and debugging. The next assignment corresponds to software integration, integration and system testing, debugging, and enhancements. In conjunction with coding each unit, your team must develop unit test plans covering each of the implemented units.

For this assignment, you must turn in both a descriptive document and code listings as described below. The source code should be documented with sufficient, informative comments. This deliverable also includes the unit test plans and test execution histories, which should functionally and structurally test each unit in the implementation. You should organize the unit test plans and test history documentation in much the same way as the units themselves are organized in the implementation. You need not print out the results of all testing activity, but should show enough results of executing your unit test plans to convince us that your units are ready for integration.

Specify the correspondence between your software design and the implementation. Show this correspondence any way you feel is appropriate (e.g., make notations throughout your document or in your minutes), but by all means include some discussion in the overview section. Implementing the software will undoubtedly reveal inadequacies in previous documents. Please note these problems and what was done to solve them.

Don't forget to include your meeting minutes and performance appraisals with your document; refer to the syllabus for the complete check-list of what has to be turned in. As before, make sure that you post your design document and your meeting minutes to your team web page.

Deliverable Objectives/Quality

Keep in mind that key objectives of the implementation are to:

Translate the design into code that will satisfy requirements
Identify inadequacies in the design and requirements
Document further decisions and rationale
Provide a reference tool readable by developers, testers, and maintainers
Develop a review plan that will yield confidence in the code
Provide a basis for unit testing to determine that implementation meets design

In addition, keep in mind that an implementation document should satisfy the following qualities:

Complete? everything that is in the requirements and design is implemented
Consistent? no mismatched interfaces and consistent with the design
Stylistic? exhibits good programming style

Understandable? code should be constructed that is easy to read,

Modifiable? again this is a living document
Desensitized to change? maintains information hiding as specified in the design
Confirmable, Verifiable and testable? you can tell when you've met the design and requirements

Document Contents

Introduction

Expand your introduction to discuss your specific approaches to the implementation of the system and the organization of this document. This description is essentially just an updated version of the introduction you included in your previous deliverable. This description should guide the reader.

Understanding

As needed, expand the understanding section of your previous document. Make sure to add descriptions of what additional steps or actions you took to understand each technology or software during this phase. If you make changes to this section, add text describing why the change was necessary, and why it more accurately reflects your new understanding. This section need not be different if your understanding hasn't changed.

Project Plan

This will be an iterative expansion of your previous submission. Expand your project plan to represent how you have accomplished the work so far. Reassess the project risks. Expand your task network or work breakdown structure to include the effort expended to complete this task. Based on the work you have done, revise your estimates on how much your team can accomplish and deliver. Update your time estimates for the remaining work.

If you make changes, add text describing why the change was necessary or why it will improve the ability of your team to accomplish the work you have proposed.

Implementation

Overview of Software Implementation

Implementation organization
How your systems works
System size (e.g., source lines, packages) (See the note below under the presentation instructions for how to show this.)
Major limitations on the current implementation

Source Code Listings

List of Modules/Objects within your system
Complete listings for your software system.

Listings should be free of syntax errors and should have compiled
Organize these listings by system architecture in the same order as your design document
Each module/object must be documented in standard ways, defining its purpose, how it works, and interface (this should be straight out of the design)

Unit Test Plan/Test History

Includes a unit test plans capable of demonstrating that each unit meets the design and requirements traceable to that unit. The unit test plans should be based on both functional test heuristics based on the functional description of the unit (black box) and structural test criterion to at least cover all branches (white box).

Shows selected results of your testing activity, enough to raise our confidence in your software and to show that it is ready for integration and final testing. In particular, you should show a representative selection of test results for each unit test plan. The test results should show the test case executed, whether any failures were detected, what faults were debugged, and (hopefully) that it eventually passed.

NOTE: if desired, the test cases can be grouped with the code entity to which they apply, else a cross reference listing of some sort should be provided. In addition, the test results can be grouped with the test plans/cases to which they apply, else a cross reference listing of some sort should be provided.

Unit Test Plan / Test Execution History ... for each test case

Test Case Identification
Purpose of Test Case
Item(s) being tested
Input specification
Output specification

Expected Results or Test Oracle Mechanism

Test environmental needs or special test procedures

Test Results

pass/fail

Failures detected
Faults debugged
Final Test Result

hopefully passed ... but if not fixed, document this

Demonstration Plan

How and what will you demonstrate? This is a chance to continue your planning for the final demonstration.

Tracking and Control Mechanisms

Configuration Management: how are your modules/objects maintained?

file structure, sub-directories, Makefiles, etc.
persistent data

Design Cross Reference: what files contain what modules/objects from your design?

a table mapping module/object to file
make sure it is complete and consistent.

Modifications to Prior Documents

Design

This will be similar to your previous design document, but if any modules/objects or interactions are changed, added or deleted, make this explicit. Highlight why the design was changed/added/deleted and by whom (customer, developer, etc.). Again make sure your design meet the objectives of completeness, abstraction, modifiability, and consistency. If your design has not changed, then this section should be identical to what you submitted earlier.

Requirements

This will be similar to your previous requirements document, but if any requirements are changed, added or deleted, make this explicit. Highlight why the requirement was changed/added/deleted and by whom (customer, developer, etc.). Again make sure your requirements meet the objectives of completeness, understandability, utility, unambiguity, and consistency. If your requirements have not changed, then this section should be identical to what you submitted earlier.

Glossary

Defines any terms used in the specifications above.

Documentation

This section is reserved for any additional documentation you may have developed during this phase of the project. Specifically, if during the course of developing the your understanding of the various technologies involved in the project, you discovered items that were not documented, but which were important, then you should include that here.

Additionally you should list here the major background sources of information that you used during this phase or any that you plan to use during the remainder of the project. This would include references to similar systems and/or procedures.

Implementation Presentations

See the syllabus for dates.

Each team should prepare a 10 minute presentation (NOTE: this is shorter than all the previous presentations), after which we will allow up to 5 minutes of questions. Your presentation should include the following:

Very brief context to your project;
Current state of your project plan. Be sure to include a table showing how many hours were originally planned for each phase and how many hours you actually spent on each phase. For phases where there is a large difference (>25%) provide an explanation.
Highlights of your implementation including

an overview of your architecture
one or more module/object implementations and associated unit test plans;
requirements and design cross reference for the highlighted code;

A description of how many lines of code you've written, how many files they are in, and how those files are organized. A good way of showing this is as a tree reflecting the file/directory structure, with each leaf node annotated with the number of lines of code in that node, and each non-leaf node annotated with the aggregate number of source lines in all subsidiary directories and files.
Modifications to your requirements and design that arose as a result of your coding process;