Informatics 117: Project in Software System Design
Winter Quarter 2009
Implementation
Due Date
March 5, 2009
Overview
Implement your system according to its design and requirements.
This implementation will be handed in
in two parts. This assignment corresponds to the initial
coding phase, 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. The
unit test plans and test execution histories should functionally
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.
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
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
(e.g., safe constructs, information hiding, well defined types, reasonable
module sizes and complexity, well-defined module interfaces, avoids side
effects)
- 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
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
If 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
- 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
- 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 functional test heuristics based on the functional
description of the unit (black 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.
- 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
Demonstration Plan (Update)
How and what will you demonstrate? This is a chance to continue your planning
for the final demonstration.
Tracking and Control Mechanisms (Update)
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 (Update)
Design
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.). If your design has not changed,
then so state.
Requirements
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.). If your requirements
have not changed, then so state.
Glossary (Update)
Defines any terms used in the specifications above.
Documentation (Update)
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.
Implementation Presentations
March 5th.
Each team should prepare a 20 minute presentation. 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.
- Any significant modifications to your requirements or design that arose
as a result of your coding.