ICS 125: Project in Software System Design
Fall Quarter 1999
As described in the course syllabus.
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
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.
Keep in mind that key objectives of the implementation are to:
In addition, keep in mind that an implementation document should satisfy
the following qualities:
- 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
- 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
(e.g., safe constructs, information hiding, well defined types, reasonable
module sizes and complexity, well-defined module interfaces, avoids side
- Understandable? code should be constructed that is easy to read,
not necessarilly easy to write
- Modifiable? again this is a living document
- Desensitized to change? maintains information hiding as specified in the
- Confirmable, Verifiable and testable? you can tell when you've met the
design and requirements
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.
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.
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
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.
- 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
- 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
- Failures detected
- Faults debugged
- Final Test Result
- hopefully passed ... but if not fixed, document this
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
- a table mapping module/object to file
- make sure it is complete and consistent.
Modifications to Prior Documents
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.
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
Defines any terms used in the specifications above.
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
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;