As discussed in class, your web page becomes your final report. At the end of the semester, you complete and add to it (for example, conclusions, future enhancements, etc.) Reviewing the web page requirements:
All text files are HTML format (not pdf, docx, etc.)
All files (including image/figure files) are in one directory
The directory name is cs499s18pxx where xx is your project number 1-20
The home html file is named index.html
index.html contains links to the final report sections described below
The links to your content must be relative (not absolute links starting with http://www......): just the file name (for example introduction.html) in the same directory as index.html
The links to external content (i.e. references) are absolute
NO pdf, docx, odt, or other text files are allowed. All text must be in HTML files
There are two methods to fulfill these requirements:
Web page on a team member's Multilab HTML directory: team_member_home/HTML/cs499s18pxx directory
If you use GitHub pages, use the name:
cs499s18pxx (xx = project number)
for your GitHub user name for this project.
Google Sites CANNOT be used.
For information on your Multilab account, go to this link.
See the examples:
This is the Spring 2017 project 19 final report converted to the web final report format.
CS 485 Summer 2017 final report
This is the Summer 2017 CS 485 final report in the web format. This was a continuation of a CS 499 Spring 2017 project. Note that it does not have all the subsections (for example Product Planning, Schedule and Milestones) that are required for CS 499 projects.
See the examples above. As long as the page contains the required information below, you can construct the page as you wish, and be as creative as you want.
See examples.
Provide an image/figure to represent you product.
Remember that these must be relative, not absolute links.
See examples. For each team member, the team member's email address, and a link to the etam member's weekly updates are provided.
See examples.
Disclaimer
Disclaimer:
This project has been designed and implemented as a part of the requirements for CS-499 Senior Design Project for Spring 2018 semester. While the authors make every effort to deliver a high quality product, we do not guarantee that our products are free from defects. Our software is provided "as is," and you use the software at your own risk. We make no warranties as to performance, merchantability, fitness for a particular purpose, or any other warranties whether expressed or implied.
No oral or written communication from or information provided by the authors or the University of Kentucky shall create a warranty.
Under no circumstances shall the authors or the University of Kentucky be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software, even if the authors or the University of Kentucky have been advised of the possibility of such damages.
Starting February 11, each team member provides individual weekly activity by Sunday for the semester, excluding the Sunday before Spring Break. You can submit weekly activity earlier than Sunday. The instructor reviews weekly activity Monday morning. The Sunday after Spring Break can be used for the previous 2 week activity). The instructor reviews each team member's weekly activity. For the GCCR requirement, provide at least a paragraph.
The link to each member's weekly activity is on the home (index.html) page. This link is to a file in the team member's Multilab directory. The file is in HTML format.
The sections of the final report:
Introduction
Requirements
Design
Screens
User Scenarios
Testing
Design considerations
Future enhancements
Conclusions
Installation
References
The subsections of the introduction:
Introduction to the project
Introduction to team members (optional)
1.1 Introduction to the project
A brief introduction so that the reader can determine interest in the subject of the project. Write it so that a peer (member of this class) can understand the project. The Introduction should be understandable by someone technically competent with the area of the project but not familiar with this project. The introduction includes:
· a description of the feature to be supplied to the customer/user, or the problem you are solving
· The motivation for providing this (why is this needed)
· The customer/users (the customer and users may be distinct)
1.2 Introduction to Team Members
Some teams have provided a brief introduction to each team member. See the examples:
This is not required, and is optional for all of the projects. If you supply introductions, make it something that you will not be embarrassed if your customer (or a potential employer) reads it.
The subsections of the requirements:
Requirements in priority order
Effort and size estimation
Schedule and milestones
Platforms, tools, languages
2.1 Requirements in priority order
The requirements (also called specifications) what you expect to deliver to the customer. Note that the requirements may change as the project is developed. See examples from past projects here: cs499projects
Requirements are agreed to by the customer, and put in order of priority, agreed to by the customer. Make it clear what are "essential" requirements (to be completed by the end of the semester)and those that are "stretch" goals that you would like to complete given sufficient time.
One requirement that applies to all projects:
Robust documentation to support reuse and maintenance of all software by later projects This should be recognized as a requirement of all projects. Don't bother to add it. But remember that I assume it as a requirement for all projects. Successful projects will continue to be used and enhanced. When I have the code reviews with your projects after spring break, I will expect understandable source code that can be supported in the future.
2.2 Effort and size estimation
Estimated lines of code (or story points, function points) per module before you started implementing the application
At end of the semester, add to this section: Actual lines of code (or story points, function points)
At end of the semester, add to this section: Discuss what factors may have thrown your estimates off, if accurate, what methods you used to achieve accuracy.
See the Software Process and Project metrics slides. Note: Your accuracy will not affect your grade.
2.3 Schedule and milestones
Some of these will be assigned by the instructor (midterm, final reviews for example), others will be unique to your project. Use a calendar tool:
Example:
Project 5 (page back to 2017 spring semester)
An example using a software engineering planning tool:
Project 19 (not required for this semester, but what is used in the industry)
2.4 Platforms, tools, languages
The platform(s) that you product will run on, languages used, tools used either by the product or by the team during development, include motivations for using specific platforms, tools, languages. Put the release levels you will be using for development. When using acronyms, spell out with the first use, and provide a link to a definition if needed.
This is written so that the technical reader (interested reader outside of your project who is familiar with the area addressed by the project) understands your design. Diagrams, flow charts, and graphical methods should be used to implement a design (and are recommended). There is a wide variety of CS 499 projects. For a design "one size does not fit all". Adapt these instructions to fit your project. I will grade by the rule: Does it explain the design of your project to a technical reader, who may have to enhance and maintain your product in the future?
The subsections of the design:
Overview
Environment
Module description and data flow
3.1 Overview
Start with the requirements and modified as necessary to provide implementation information. For a design document you can assume the reader has a technical background. For your projects assume a background of a class member.
3.2 Environment
List any requirements (operating system, database products, execution environment (iOS, Android, Windows, Mac, etc.).
3.3 Module Descriptions and Data Flow
Include a diagram showing the modules and data flow between them. Give a high level description of the function of each module. There are a number of tools/techniques used for a clear design. The most widespread ones are covered in the class design slides:
http://www.cs.uky.edu/~paulp/CS499/design.html
A pseudocode format is often used so that code can be written directly from it. A simple example:
Open grades file
While grades for student in file {
If valid grade (0-100)
Add grade to student total
else {
Report error to user screen
Create error report for history
}
}
Describe the data going into and out of the modules, using structures as necessary.
You are free to organize this section to meet the needs of your project. The important point is to get across the design to the team members and interested readers. For your projects, the customer does not have to approve the design document. However, anything in it that affects the customer (platform, user screens, etc.) must be approved.
Provide screen shots of the the screens needed for an understanding of your product., along with descriptions of their functions. For protects without screens, consider if there is alternative information that can help the reader's understanding of your product.
Include user scenarios and screen shots as appropriate for your project. Include the typical steps a user would do for major functions.
Examples:
CS 485 "Steps" format
Softball Statistician Page 10 flowchart format
Tests and results including what is applicable of the following.
Test cases, test results for unit testing (lowest level)
Test cases, test results for integration testing
Test cases, test results for system testing (highest level)
Because of the variety of projects, "one size does not fit all". Adapt your test cases to your project.
Information to relate to the reader for issues relating to design considerations or the implementation:
Issues, problems during implementation
Changes to design necessary during implementation
Restrictions, limitations
Future enhancements for the product
Issues raised by users during product testing that require fixes/updates/enhancements
Project features, documentation added to aid maintenance.
What did you learn, what would you do differently, what is the customer/user impression of the product.
NOTE: For a semester-long project, I expect more than a few sentences summarized by:
"The project was successful."
Discuss:
Changes to the initial customer requirements, and reasons for the changes (lack of time, change in project functions, changes to overcome technical or logistical problems, etc.)
How changes to the requirements affected design, schedule, etc.
Difficulties faced during the semester
Lessons learned on this project
What you would do differently if you were starting over
Examples:
Provide sufficient information so that any technically competent person can install and use your product.
List all sources that you used (links where possible).