Project Title
Names of Authors
Draft Number
Date of this Submission
CNT 4104 Software Project in Computer Networks
Instructor: Dr. Janusz Zalewski
Department of Software Engineering
Florida Gulf Coast University
Ft.Myers, FL 33965
1. Introduction
This is the template for the reports. Each document must follow the following formatting rules:
-all reports must be submitted in MS Word format .DOC (not .DOCX), no exceptions
-for text, you must use 12 pts Times New Roman font, no exceptions
-all code must be written in Courier New font 11 pts, no exceptions
-line spacing (space between lines of text) must be 1 and ½ lines
-for code the line spacing must be 1 line
-for section headings you must use 14 pts Time New Roman font, bold, no exceptions
-do not use Microsoft formatting for section headings and section numbering
-there must be one inch margins from each edge; begin each new section from a new page
-do not include the Table of Contents (unless requested by Instructor)
-include page numbers
-include as many illustrations (photos, diagrams, screen shots, etc.) as possible; must be relevant to the project (not just some unrelated pictures downloaded from the Internet).
The Introduction section should contain general information on the project and technology used, including information on previous project(s), if the current one is the continuation. In particular, the Introduction section should address the question WHY this project topic is important (for the profession? the society?), and give the outline of the technologies used in the project. Once again, illustrations are essential across the entire report, including this Introduction.
Each illustration (pictures, diagrams, tables, etc.) throughout the Report should be numbered and titled, and referred to from the text of the Report. Illustrations taken from work published by others must include a reference to the source (this source must be listed in the References section).
Submissions of the reports must always be made to a respective Canvas Forum and, at the same time, emailed to:
My FGCU mailbox is too small to handle floods of incoming reports, some of them lengthy, so please do not email your reports to it.
2. Software Requirements Specification
Begin each new section at a new page. Having illustrations is essential
This section should include a description of project objectives, and should be equivalent to Software Requirements Specification, expressed in the format outlined below. The beginning should be clearly stating the following:
- What is the status of the original project, as completed by previous group(s) – if the current project is a continuation?
- What is to be accomplished this semester (your best estimate or perception of such)?
Most importantly, input/output and functional requirements must be included here, including the following rules:
- A Physical Diagram, including all participating physical entities, especially all hardware devices, human operators, networks, etc., should be placed here with verbal description (narrative) what the diagram includes.
- A Context Diagram, understood as a graphical representation of all interactions of software to be developed, with the environment, shown in the form of inputs and outputs (I/O) with all their characteristics. The characteristics of I/O (signals, messages, etc.) should include as many as possible of the following: (a) source, destination and direction; (b) physical form and logical format; (c) quantity, unit of measure and accuracy; (d) data type and range of validity; (e) illegal values, error messages; (f) timing and frequency; (g) operator actions, etc.
- Each individual requirement should be numbered and written as follows:
- A requirement must be placed on software to be developed (not on a user, human operator, or any device used in the project)
- A requirement must be a single, simple sentence. If the sentence is not simple, then split it into multiple requirements.
- Use the verb “shall” (or “must”, “has to”) to express a requirement.
- The use of words “will”, “should” is permitted, but only in statements, which are not mandatory to be implemented in software.
Other rules may apply. If you have any specific doubts, contact the Instructor.
3. Design Description
Begin each new section at a new page. Having illustrations is essential
This section should include the description of design, according to the format selected by the student.
Two essential elements of the design must be present:
1)Software Architecture, derived from and consistent with the Context Diagram.
2)Detailed Design, describing the software components outlined in the Software Architecture, from two perspectives:
-static perspective, that is, outlining details of software structure
-dynamic perspective, showing the software behavior.
Presenting Software Structure can be done in a number of ways, from a simple Structure Chart or Pseudocode to a more involved Class Diagram.
Presenting Software Behavior can be also done in a number of ways, from a simple Flowchart to a more complicated Sequence Diagram, or even a Statechart.
4. Implementation and Testing
Begin each new section at a new page. Having illustrations is essential
This section should include two subsections:
- first subsection describing an implementation, outlining how specific elements of Design are converted into code, with code snippets and respective narrative explaining them;
- second subsection, showing the results of experiments or other ways how the software has been tested, with test cases corresponding to each specific requirement, as numbered in in Section 2 of this report.
The exact contents of the subsection on testing should include the following:
- Test Plan, which should be written for each requirement and state the following
-input(s) to be applied to your software to test this requirement
-expected output(s) when these input(s) are applied
- Test Results, which should
-show actual output(s) when respective input(s) from Test Plan are applied; screenshots of software behavior and respective narrative describing them are necessary here
-discrepancies (if any) between expected results and actual results should be discussed here, and suggestion to fix them should be made.
5. Conclusion
Begin each new section at a new page. Illustrations in this section are not essential
This section should include statements regarding project completion, that is, project summary stating what has been actually accomplished.
It should also discuss any difficulties or problems encountered in the project and how they have been resolved.
Finally, it should discuss suggestions or plans for the future, how to expand and/or improve the project.
6. References
Begin each new section at a new page. This one as well.
Sources of information must be listed here, in order of appearance in the text.
A reference in the text of the report should be numbered (surrounded by brackets, for example [1]),and its corresponding source should be listed in the References section, in one of the following formats,depending if it's a book (or a report), a journal/magazine article, or an Internet source:
[1] Book Author(s), Book Title, Publisher, Place of Publication, Date of Publication
[2] Article Author(s), Article Title, Journal/Magazine Name, Volume Number (if identified), Issue Number, Page Numbers (for example, pp. 22-35), Year (or Month and Year, if available)
[3] Article Author(s) or Company Owning the Webpage, Article Title, Publisher (that is, company which produced this article), Place of Publication (if available), Date (if unspecified on the webpage, use the date of your access), URL.
Note. Providing only URL as a source is UNACCEPTABLE and subject to penalty!
Do not use any other standard for references, such as APA, etc.