Directory Structure for Storing Project Deliverables

• You must store project deliverables in the following directory structure (for a hypothetical team, TeamX):
• Please make sure to use exactly the same names, since as you know, UNIX is case-sensitive!


Directory Structure for TeamX
README
index.html
/RLCA/ ..................... Revised Life-Cycle Architecture
        /OCD/ .............. Operational Concept Description
        /SSRD/ ............. System and Software Requirements Definition
        /SSAD/ ............. System and Software Architecture Description
        /FRD/ .............. Feasibility Rationale Document
        /LCP/ .............. Life Cycle Plan
        /MDL/ .............. Models (e.g., Rational Rose Model Files)
        /PROTO/ ............ Prototypes
        /COCOMO/............ COCOMO Data (e.g., EST, RPT files)
/Plans/..................... Construction, Transition and Support Plans (plans for the software life cycle)
README
        /LCP/............... Updated Life Cycle Plan (if any)
        /QM/................ Quality Management Plan
        /CM/................ Configuration Management Plan (optional)
        /Inspection/........ Inspection Plans
        /Test/.............. Test Plans
        /Security/.......... Security Plans (optional)
        /Safety/............ Safety Plans (optional)
        /Transition/........ Transition Plan
        /Training/.......... Training Plan (optional)
        /Support/........... Support Plan
/Iteration1/
README
        /Plans/............... Iteration Plans + Risk Management Plans for that iteration
            /IterationPlan/........... Iteration Plan
            /RiskManagement/.......... Risk Management Plan(if any
        /Doc/ ........................ As-built specs
                /OCD/ ................ As built-OCD + summary of changes
                /SSRD/ ............... As built-SSRD + summary of changes
                /SSAD/ ............... As built-SSAD + summary of changes
                /FRD/ ................ As built-FRD + summary of changes
                /LCP/ ................ As built-LCP update only Risk Management section) + summary of changes
                /MDL/ ................ As built-Models (e.g., Rational Rose Model Files) + summary of changes
        /Reports/............. Iteration Report
                /Assessment/.......... Iteration Assessment Report
                /Inspection/.......... Iteration Inspection Report(s)
                /Testing/............. Iteration Test Report(s)
                /Notes/............... Iteration Release Notes
                /Size/................ Iteration Size Report
/Iteration2/
README
.
.
.
/Iteration..n/
README
.
.
.
/Source/.................... Source Code files
                            (the directory structure you use here is up to you. Simply describe it in the README file)
README
.
.
.

/Deliverables/
README
        /Source/........................ Final Software Source Code
        /Software/...................... Final Software Distribution (executables, ...)
        /ReleaseNotes/.................. Final Release Notes
        /UserManual/.................... User Manual
        /Regression/.................... Regression Test Package
        /Tools/......................... Packaged Tools and Procedures
/Control/.................. Weekly Status Reports
README
        /Week01/.................... Week 01
        .
        .
        .
        /Weeknn/.................... Week nn
 
 

• Use ONLY relative links; this will allow the Center for Software Engineering to move the projects to the archive without breaking any links. In particular, if your prototype is web-based, it should still work. If your prototype absolutely requires absolute references, document those in a README file. Some Web publishing tools tend to automatically generate absolute references instead of relative ones, unless you particularly pay attention to it. i.e. use <ahref = "LCO/OCD/OCD.html"> instead of <ahref ="http://nunki.usc.edu:8082/teamX/LCO/OCD/OCD.html">
• It is always a good idea to include a README file explaining the contents of the various directories, especially if you generate subdirectories other than the ones listed above.
• If you name the file README (without any extension) in a directory that does not have an index.htm or index.html file, some HTTP servers display the contents of the directory, and append to that the contents of the README file, which is a very easy simple way to display the directory structure, and its contents
• Keep the number of files lying around in the main team directory at a minimum
• Store HTML document(s), Microsoft Word document(s), graphics, etc...pertaining to the Operational Concept Description (OCD) under ./OCD/. You may add subdirectories (e.g., for images), but OCD.html should in the parent directory. Of course, the same applies for the remaining artifacts
• If you have more than one prototype, store them under /PROTO/ as subdirectories /PROTO1/, /PROTO2/, etc..
• Similarly, if you more than one Inspection Report, generate under  Iteration1/Reports/Inspection subdirectories as /Inspection1./, /Inspection2/
• DO NOT needlessly duplicate files. Remember, you have a limited quota.
• For the as-built specs, e.g., if the OCD has not changed, include a file saying "No change". If the changes are minimal,  only list the changes
• The directory structure to use for Source and Software Distribution is up to you (e.g., if you are using Version Control Software). Simply describe it in a README file

General Guidelines

• Rose Model File should be kept in synch with architecture described in the SSAD
• Documentation of the prototype (screen shots) should be kept in synch with the live prototype
• Hyperlinking the various documents enforces traceability and consistency checking
• E.g., hyperlink the OCD, SSRD, SSAD, LCP and FRD.
• Instead of just having a 'Refer to OCD 2.3...', try to add a link to  the target section (in this case, OCD2.3). You will need to add HTML anchors to link to a particular section in a big document. Similarly, instead of having 'Refer to System Responsibility SR-03', provide a hyperlink to it.

Team Project Homepage

• In addition, every team is required to set up a website which will give easy read-only access to the various project deliverables
• The team website should have at least the following basic information about the project, the team members, etc...
• Teams can enhance further their website if desired

The team website should provide links to each of the artifacts, in their Life Cycle Objective version, and the Life Cycle Architecture version.

Note that in this case, the WinWin negotiation link need only point to the HTML report generated by the USC-WinWin tool