Outline:  The concepts of Software Engineering.  Stress is placed upon formal models for the design and development of high quality software.  Topics include:  project planning, requirements analysis, system design, program design, program implementation, program testing, system testing, system delivery, and maintenance.  A group project with full documentation is required.

Index
    Reports
    Project Schedule
    Proposal/Justification
    Gantt Charts
    Specification Document
    Design Document
    Test Design Document
    User Manual
    System Reference Guide

Reports:

•  Must follow the style of Sommerville, 5th edition
•  Must be electronically processed
•  Printed double-spaced
•  Laser printed
•  Correct spelling and word usage
•  Good style (e.g., Strunk and White's Elements of Style)
•  Paginated consistently
•  Header or footer with information on report, date last modified

 
 

Project Schedule

Document	Due	Points
Proposal	Feb. 27, 1998	20
Specification	Mar. 27, 1998	60
Design	Apr. 19, 1998	50
Testing Design	Apr. 19, 1998	50
User Manual	May 1, 1998	50
Syustem Reference	May 11, 1998	50
Presentation	May 11, 13, 15, 1998	50
Gantt Charts	2/27, 3/13, 4/3, 4/24	20

In three to five pages, address the following:

Context of the project:

•      Who needs it and intended user group
•      Value of the project over the status quo
•      Where will it be used
•      Hardware/software required

•      Clear concise description of problem
•      Specific objectives
•      Inputs of system:
•           Where does data originate, when, what form?
•      Outputs of system:
•           What information is needed, by whom, what form?
•      Outline of what is to be included
•           Backups, controls, help features
•      Constraints
•           Performance, language

The Gantt Chart serves to report the current status of a project.  Different books give different rules for these charts and the instructions contained here have been adapted from senior project Gantt charts which were informative and attractive.  While you may choose to use a variation on this style, your chart should be as informative.

Attached are two charts for a single project.  One is for the start of the project and the other reports the progress about half-way through the project.  These were designed using Microsoft Word in Landscape mode and using tab settings for alignment.  The basic chart took me several hours to do but once it was in place, the second was an easy modification of (a copy of) the file.

The proposed work schedule consists of several sections.  Any required document must have at least one section whose endpoint corresponds to the delivery date. Large sections may have logical subsections, even if there is not an explicit product (for example, High-Level Design produces certain of the diagrams for the full Design document).  However, there must be a way to determine when the section is done.

The portion of the chart at the right shows each of these sections with the planned start and end dates.  As the project advances, planning becomes progress.  Any work beyond the current date is designated ‘S’ for Satisfactory.  Work started before schedule is noted with a ‘B’ while work after scheduled time is recorded as ‘A’.  The Gantt chart at the end of the project gives important feedback to help improve estimates on future projects.

For Project Status, finished work is ‘A’ or Satisfactory, even if finished late.  Work not yet scheduled to be started is ‘S’ for Scheduled.  Work that is seriously behind is either ‘C’ for Caution or ‘F’ for Critical, depending on how far behind it is and how much it impacts the rest of the project.  The Percent Complete estimate is an important part of this decision.  On the second chart, a more prudent developer might consider the System Design as also Critical and Implementation as requiring a Caution.  There is no fixed definition but experience has shown that software developers usually overestimate the amount accomplished and underestimate the amount of time needed to finish.

Sample Chart 1:

   S   Scheduled
   A   Satisfactory
   C   Caution
   F   Critical

Planning/Progress Symbols

   B   Work Before Scheduled Time
   S   Scheduled Activity Time
   A   Work After Scheduled Time

Sample Chart 2:

Project Status Symbols

   S   Scheduled
   A   Satisfactory
   C   Caution
   F   Critical

Planning/Progress Symbols

   B   Work Before Scheduled Time
   S   Scheduled Activity Time
   A   Work After Scheduled Time
 

For this and all subsequent reports, the following format is required:

• Cover Sheet (see proposal for format)
• Abstract (2-3 paragraphs telling what the report is for)
• Table of Contents
• The main body of the report will have a chapter division with each chapter divided into sections and sub-sections
• Index

•  Introduction:  need, context, overview functions, and rationale for the system; how it fits into the overall business or strategic objectives.
•  Glossary: technical terms; do not assume experience or expertise of reader.
•  System models: relationship between system components and the system and its environment. Object models, data flow diagram, semantic data models as needed.
•  Functional requirements definition: services provided to the user; natural language; cross-referenced.
• User interface specification: details how the user will interface with the system. What is the "look and feel" of the system.
•  Non-functional requirements definition: constraints (related to functional requirements) and standards.
•  System evolution: fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs, etc.
•  Requirements specification: detailed specification of system requirements, mostly functional.
•  Index/Indices

•  Hardware: including interfaces, specialized and off-the-shelf.
•  Database requirements: logical organization of the data and interrelationships.

Introduction:

• Provide an abstract description of the system.
• Describe the design method.

At each level of design, provide an Architectural Design, that is, identify the subparts making up the overall structure and their relationships (graph) and document each:

1. Abstract Specification: for each subpart, provide an abstract specification of the services it provides and the constraints under which it must operate;
2. Interface Design: for each subpart, define and document its interface with other subparts;

After designing a level, provide a Component Design on each subpart, that is, partition the services provided by a subpart across components in that subpart. This provides an Architectural Design of the subpart and is a new section of the document.

Where needed, provide

1. Data Structure Design: design in detail and specify the data structures to be used in the implementation; and
2. Algorithm Design: design in detail and specify the algorithms used to provide the services at the intermediate levels. Object diagrams describing scenarios are appropriate.

For this course, we will use the pre-condition/post-condition formalism to describe behaviors.

Real-Time Design: If relevant, give the design that will ensure that the real-time timing constraints will be met.

User Interface Design: Give the design principles to be used. Examples may be given.

Help System Design: describe the structure of the help system and how it is to be accessed (menu, context-sensitive, etc.).
 
 

Testing:

• List tested items organized by phases.
• Requirements traceability: cross-reference to specification document through design document.
• Testing schedule with resource allocation
• Test recording procedures (provides an audit)
• Hardware and software requirements: tools required and hardware utilization.
• Constraints:  staff, resources

Introduction:

Describe functionalities and reason for the system.

Introductory manual 

1.  how to use system
2.  information on help system

1. alphabetical listing of services
2. error messages and error recovery

If there is more than one user class, you may have to write a several-section manual with each giving the above for its audience. It should be very easy for a user to get very specific information to answer a question.

Includes complete copies of

•  Specification Document
•  Design Document
•  Test Design Document
•  User Manual

•  known problems
•  hardware and software dependencies
•  evolution