US Software Capstone Design Project

GNAT - Graphical Network Analysis Tool

Software Development Plan

 

 

Design Team:

Matt Ericson

John Kobinski

Matt Petro

Rob Waltz

 

 

Client:

Rich Ames, US Software

 

 

 

 

v1.3

September 21, 1997

Last revision: 1/12/98

EXECUTIVE SUMMARY

 

This document describes the plan we will follow during the course of this project. This document discusses the overall scope of the project, along with our plan for risk analysis and requirements capture. Also included are details of the documentation which will be produced and our software testing methodology. Finally, we have included a copy of our project schedule in the form of a Gantt chart.

 

SOFTWARE DEVELOPMENT PLAN

US SOFTWARE PROJECT

 

Team Members:

Matt Ericson

John Kobinski

Matt Petro

Rob Waltz

 
  1. SCOPE

This is the scope of our software package, pending the next teleconference with Richard Ames of US Software.

Our software will:
    1. Accept an Ethernet packet log (e.g. from Snoop 2) as an input
    2. Disassemble packets and allow for display
    3. Interpret packet fields
    4. Compile statistics on packets and allow for graphical statistic display
    5. Perform analysis using output from statistical step
    6. Provide troubleshooting guidelines based upon output of analysis
    7. Provide all output through a GUI running in a Windows environment

 

References:

Data and Computer Communications – W. Stallings

US Net Handbook – US Software

As-Built Report – Dake, Sheridan, Mitchell, Pearson, Simcoe

RFC 791 – Internet Protocol

RFC 793 – Transmission Control Protocol

RFC 1761- Snoop 2 File Format

http://ana-www.ks.mit.edu/anaweb/ps-papers/_TR_454.ps

http://www.con.wesleyan.edu/~triemer/network/docservs.html

gopher://gopher-chem.ucdavis.edu:70/00 … he_Internet/intro.to.ip/02*

 
  1. TEAM ORGANIZATION

    2. Team Leader – Matt Petro

    Team Recorder – Rob Waltz

    Client Liaison – John Kobinski

    Network Coding Consultant – Matt Ericson

     

  2. SCHEDULE

    3. We will adhere to the Gantt chart which we have developed and included with this development plan.

    The following are milestones which will be adhered to:

    Sept 16 Schedule and Software Development plan

    Sept 30 Specifications Document

    Oct 8 Project Proposal

    Oct 21 Prototype (Looks-like)

    Dec 2 Design Document, Prototype (Works-like) and web site

     

  3. RISK AREAS

Our team has identified two potential areas of risk:
    1. Fluency in a Windows programming environment – the GUI must work in the Microsoft Windows environment, and none of the programmers on the team are familiar with any of the common Windows programming packages.
    2. Developing accurate troubleshooting algorithms – our team foresees difficulty in interpreting the statistical analysis and coming up with meaningful guidelines for a network operator to follow.

 

In order to head off potential risks, our team has taken the following steps:
    1. Assigned John Kobinski to research available programming packages for Windows, and choose the one most suitable to our project. Subsequently, to learn how to use the package and become a team resource on the subject.
    2. Matt Ericson has already begun research on Ethernet packets and common problems they encounter.

Our team plans to spend time at each meeting identifying potential risk areas through the design process. We intend to handle future identified risks in a similar manner to that above, e.g. study and knowledge sharing.

 
  1. REQUIREMENTS

a) PRIMARY REQUIREMENTS CAPTURE

The primary requirements have already been listed in Section 1 of this plan. These will be summarized into a specifications document and given to Richard Ames for review. After Mr. Ames’ input, the document will become our formal design specifications list.

b) DERIVED REQUIREMENTS CAPTURE

Research will be done for each requirement to discover the tasks that need to be successfully completed to fulfill the primary requirements. Each team member will brief the other team members as to how their component will interact with the rest of the components. Once these steps have been taken we will conduct a formal review to insure that all primary and derived requirements meet the specifications which will be detailed in the specifications document.

c) REQUIREMENTS TRACKING

Our team will implement the following procedures to track the requirements during all phases of the software design:

d) TESTING FOR REQUIREMENTS COVERAGE

Using the aforementioned poster, as each design phase comes to completion, our team will test it’s output (or proposed output) and functionality (or proposed functionality). Periodic deliverables will be made available to Richard Ames for his approval, giving him an opportunity to verify requirements compliance.

 
  1. DOCUMENTATION

The following documents will be produced and made available to our corporate sponsor during the course of our software design:
    1. Schedule
    2. Software Development Plan
    3. Specifications Document
    4. Project Proposal
    5. High-level Architectural Concept (possibly a flow chart)
    6. Prototype ( looks-like)
    7. Prototype (works-like)
    8. Detailed Test Plan
    9. As-Built Report

 

  1. DEVELOPMENT PROCESS

Our team will use the incremental model for the design process. In this way we will log the following milestones:
    1. Software development plan
    2. Sponsor verification of specification documents
    3. Finished specification documents
    4. Explicit and derived requirement review
    5. Project proposal
    6. Looks like prototype
    7. Architecture requirements capture review
    8. Functional requirements capture review
    9. Design documentation
    10. Works like prototype
    11. Web site

 

  1. SOFTWARE MANAGEMENT PLAN

    2. Revision Control System (RCS) will be used for version control of the software. Since RCS is UNIX based, we will check the software out in UNIX, and then FTP it to a PC.

     

  2. SOFTWARE TESTING

    3. We will perform white-box testing on individual classes and functions. Once detailed design is complete, each team member will be assigned to write specific classes and functions. Each team member will also be responsible for designing and performing a series of white-box test cases on those classes and functions. We will develop white box test cases using the basis path method. We will perform black-box testing during later stages. Primarily, we plan to use equivalence partitioning to verify that the software meets its primary requirements. Our testing environment will be a standalone network of four (4) PC’s connected using 10 Mb/s Ethernet. We will, however, change our testing methodology if our final specifications warrant such change.

     

  3. DEVELOPMENT TOOLS AND ENVIRONMENTS’
    1. Microsoft Windowsä operating system environment.
    2. Microsoft Visual C++ä development platform
    3. US Net, US Software’s DOS based network software.
    4. Microsoft Office 97 for scheduling and document generation.
    5. Object Modeling Technique (OMT) will be used for our high level program design.
    6. An Ethernet hub and network interface cards to be used for testing with actual network traffic.

 

  1. CLIENT INTERACTION

Our team has scheduled weekly teleconferences with our client, Richard Ames of US Software. Deliverables and prototypes will also be made available to Richard as they are developed.