ISEAGE Network Specification and Report System

Transcription

1 ISEAGE Network Specification and Report System Project Plan Client ISU Information Assurance Center Faculty Adviser Dr. Douglas W. Jacobson Team May 05_25 David C. N. Rodgers Lijin Varghese Derek J. Light Justin Magnini ComS, CprE CprE CprE CprE DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. Submission Date October 4, 2004

2 Table of Contents 1. INTRODUCTORY MATERIAL Abstract Acknowledgement Problem Statement General Problem Statement General Solution Approach Operating Environment Intended Users and Intended Uses Intended Users Intended Uses Assumptions and Limitations Initial List of Assumptions Initial List of Limitations Expected End-Product and Deliverables PROPOSED APPROACH AND STATEMENT OF WORK Proposed Approach Functional Requirements Constraint Considerations Technology Considerations Technical Approach Considerations Testing Requirements Considerations Security Considerations Safety Considerations Intellectual Property Considerations Commercialization Considerations Possible Risks and Risk Management Project Proposed Milestones and Evaluation Criteria... 9 ii

3 Project Tracking Procedures Statement of Work ESTIMATED RESOURCES AND SCHEDULE Estimated Resource Requirements Personnel Effort Requirements Other Resource Requirements Financial Requirements Schedules CLOSURE MATERIALS Project Team Information Client Information Faculty Advisors Information Team Members Information Closing Summary References iii

4 List of Figures Figure 1: GUI Screenshot of End-Product... 5 Figure 2: Gantt Chart of Project Milestones...24 Figure 3: Gantt Chart of Project Deliverables...24 iv

5 List of Tables Table 1: Project Milestone Evaluation...10 Table 2: Personnel Effort in Hours...21 Table 3: Other Resource Items and Costs...22 Table 4: Financial Requirements...23 v

6 List of Definitions Allegro A cross-platform GUI library with many features. Classes Basic construct in object-oriented methods that categorizes elements of the problem. CVS Acronym for Concurrent Versioning System, a tool to manage code development. FLTK A cross-platform C++ GUI toolkit for UNIX, Linux, Microsoft Windows, and MacOS X. FOX A C++ based toolkit for developing GUI s easily and effectively across a range of platforms. FreeBSD A variant of the Berkeley Software Distribution (BSD) which implements the UNIX operating system and its utilities. GIS Acronym for Geographical Information Systems, a database used to spatially locate any location on the Earth. GNU Acronym for GNU s Not Unix and refers to software that is free for use. GPL Acronym for General Public License, a standard published for freely distributed software. GTK A multi-platform toolkit for creating GUIs. Internet2 A project aiming to facilitate research and education through advanced network applications using the Internet. IPv4, IPv6 Internet Protocol versions 4 and 6 used by the Internet and other networks. ISEAGE Acronym for Internet-Scale Event and Attack Generation Environment, the system of which the end product is a component. Java Swing A set of Java class libraries that support building GUIs and graphics functionality for client applications that will run on multiple platforms. Kylix A rapid application development tool that provides components for quick development of GUIs, database connectivity, and internet content. vi

7 Landspeed Record An open competition to achieve the highest bandwidth over the greatest distance on the Internet. Linux A popular version of UNIX that is open source software and freely available over the Internet. Mac OS X The most recent operating system in the Macintosh line. MFC A framework on which applications can be developed for Windows. Mozilla Framework A comprehensive multi-platform framework used, among other things, to develop GUIs. NetBSD Secure, multi-platform UNIX-like open source operating system. Notus A multi-platform GUI library. OpenBSD A free variant of the Berkeley Software Distribution (BSD) which implements the UNIX operating system and its utilities. Open Source Software that is free for use and modification. OS Operating System. QT A complete C++ application development framework which includes a class library and tools for cross-platform development and internationalization. SDL A library written in C++ for displaying and GUIs. UNIX A computer operating system designed to be used by many people at the same time. wxwidgets - A single, easy-to-use application program interface for writing GUI applications on multiple platforms. X11 A recent version of X Windows. XML Acronym for extensible Markup Language, a flexible way to define formats for data, and make both the format and the data available on the Internet. Xorg Another version of X Windows. X Windows The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines. vii

8 1. Introductory Materials This section is intended to give an overview of the project. Some of the questions answered in this section include what the project is about, what problems it will address, what solutions it will implement to resolve those problems, and who the intended users are Abstract Recent terrorist activities have heightened the need for protecting critical infrastructures. Web-based systems like the highly-interconnected power grids used in transportation, water, and bureaucracy management systems are especially vulnerable since there exists no satisfactory means of evaluating their security risks. To meet this need, ISEAGE is creating a virtual Internet to enable the research, design, and testing of cyber defense mechanisms. One component of the ISEAGE system, and the end product of this project, is the Network Specification and Report system. The specification system will allow the user to create a virtual computer network through a GUI tool, while the report system will enable the user to evaluate an attack in pseudo-real time or post-simulation. With the integration of this component into ISEAGE, users will be able to create and evaluate custom networks configured on actual hardware and faced with real attacks, thus allowing for an accurate assessment of network security Acknowledgement The following people and/or groups have and will continue to provide support whether in the form of technical advice, equipment, or software: Professor Jacobson has not only offered detailed descriptions of technologies involved in the project, but will also provide financial support for necessary equipment and software within budget limits. The GIS facility in Durham has and will continue to be consulted to aid the team in getting acquainted with the GIS software necessary to meet project specifications Problem Statement The problem statement is broken into two sections: a general problem statement and a general solution approach. The general problem statement will define in general what some of the problems this project will attempt to solve. 1

9 General Problem Statement One functionality this project aims to add to the ISEAGE system will allow users to specify custom computer networks through the use of objects like routers, computers, etc. Another functionality needed is to enable the monitoring of traffic both in pseudo-real time and postsimulation. ISEAGE also requires functionality to allow users to specify the objects mentioned above spatially. For example, a user should be able to specify an individual network that actually exists in Cedar Rapids General Solution Approach Since these functionalities would be extremely difficult for a user without significant programming experience, this project will design an intuitive GUI that provides graphical symbols representing routers, computers, wires, etc. Additionally, the user will be able to monitor traffic through an XML document which will format data in a logical and comprehendible manner. To enable users to map physical networks, the team will use GIS software which will display on the GUI an easily configurable topology of computer networks Operating Environment The end product will function under the Microsoft Windows NT family (including Windows NT, 2000, XP) with no modifications to the code and the Microsoft Windows 95 family (95, 98, ME). If the proper cross-platform technology can be located and licensed, the end product will also function in X Windows (X11 or Xorg, in descending priority order) on Linux, FreeBSD, OpenBSD, NetBSD, and Mac OS X Intended Users and Intended Uses This section describes the intended end users and end uses of the project Intended Users The intended users include any individual or group desiring to simulate a network to evaluate security. These networks may range from as small as two computers (e.g., to simulate fast file transfers, such as the research being done on Internet2 to gain the land speed record) to the entire state of Iowa. Creators of small networks include small business owners and student projects. The largest network will be created by Iowa s Department of Homeland Security to simulate the entire state of Iowa Intended Uses One of the largest challenges will be deriving an interface that satisfies the network complexity needs of users. Some may want to create very simple networks, some very complex networks as well as 2

10 users who want to follow the location of components and those who only want to monitor with respect to topology. A very simple simulation can easily create one computer at a time, while a very complex simulation (especially with GIS information included) must be able to create many computers in their exact locations quickly and easily Assumptions and Limitations The end product will only support one user at a time; a second copy must be run to create a different network. Therefore, two users will not be able to modify the same network simultaneously Initial Assumptions List Following are the assumptions made by the team The end product will be used by only one user per computer network in order that the simulations are completely controlled by only that user. If a user would like to configure different computer networks on the same computer, he or she would have to start another copy of the software. Functions licensed under the GPL license may be used. In such case, the end product may also be licensed under the GPL license Initial Limitations List Listed below are client-specified limitations: The software must run on the Windows NT (NT, 2000, XP). The software must be GIS -based, i.e., it must be able to configure computer networks that exist spatially. A GUI interface must be provided for ease in configuring the virtual computer network. The software must be able to specify IPv4 networks since this is currently the protocol in use by most networks. The simulation must output results into an XML file for comprehensibility Expected End Product and Other Deliverables This project expects to develop a fully functional program in the stated operating environment. This program shall be able to specify an IPv4 network with attachment points and output an XML file; attachment points are nodes specified on the network which connect to real hardware external to ISEAGE. Anything less shall be considered a failed project. 3

11 2. Proposed Approach and Statement of Work The approach that will be implemented by the team and the step-by-step process of the design of the software end-product are described in this section. Some of the major project aspects include the various requirements defined by the team for this project s successful completion and the detailed explanation of the different project execution phases Proposed Approach The proposed approach section describes some of the constraints the team will work with in order to ensure the successful completion of the project. Included are the functions that the software will or will not provide, the security measures taken to safeguard the project while it is being developed, and the safety impacts of the end product. In addition, criteria have been defined in order to evaluate the success of the project at the end of the two-semester period Functional Requirements The following defines exactly what the proposed software should and should not do: The software shall allow the configuration of virtual computer networks, whether large or small (see Figure 1 on next page) The network specification may include different types of computers (IBM, Macintosh), routing devices (switches, bridges), etc (see Figure 1 on next page) The software shall allow network specification through the use of a GUI which provides graphical symbols (see Figure 1 on next page) representing computers, routers, wires, etc., all of which will be available in a toolbar (see Figure 1 on next page) The software shall allow the user to specify a network using GIS software, i.e., to specify a network that is representative of a spatially-existent network (see Figure 1 on next page) The software shall allow network specification in XML format The software shall be able to read simulation data from the ISEAGE system The software shall allow the user to view the ISEAGE simulation in pseudo-real time or in post-simulation playback. 4

12 The software shall allow the user to track packet routes The software shall allow the user to view areas of high traffic in the configured network. Figure 1 GUI Screenshot of End-Product Figure 1 shows how the end-product GUI interface is expected to look like. The toolbar titled Place Object lists some of the graphical symbols the team plans on providing to represent network components such as routers and wires. The list of created networks and their individual components are listed in the window below titled, Object Viewer. The GIS capability of the software is illustrated by showing the visual representation of a network based physically in the state of Iowa consisting of five routers Technology Considerations Several technology alternatives exist and their evaluation criteria will be defined in this section. 5

13 The client has specified that the software should be at minimum compatible with the Windows OS. The team, however, would prefer that the software be cross-platform compatible. In order to achieve this, a crossplatform language like C++ or Java must be chosen. Given, however, that the team as a whole is more comfortable with C++, and that the risks involved in choosing a language that most members are not very strong in are relatively significant, the team has chosen C++. Part of the project specification is to develop a GUI for the software. In order to accomplish this, the team must use a graphics package that is at least Windows-compatible, if not cross-platform compatible. The graphics package must also allow programming in C++. Finally, the costs incurred and any licensing requirements imposed by the use of a graphics package must also be considered since the end-product is going to be commercialized. Another specification is that the software must be GIS-based. This implies the use of GIS software application(s). Iowa State s site-licensed GIS software, as well as its counterparts in the commercial and open source world must be considered. Also to be considered is whether the GIS software allows cross-platform functionality, whether it supports C++, what licensing requirements are imposed as a result of the choice, and what if any costs are incurred if the software is purchased. Finally, the time required to get familiarized with the GIS software must also be taken into account. Text editors, compilers, and debuggers are some of the tools that greatly ease the software development process. Several integrated development environments (IDE s) exist that provide these tools. However, the Visual Studio IDE will be used as it provides a significant number of software development tools in addition to the ones mentioned above Constraint Considerations This section outlines the design constraints of the software The software must be Windows-compatible The software may be cross-platform compatible The software shall provide GUI for network specification The software shall be GIS -based The software shall produce output in XML The software must not allow more than one user to simulate a network. 6

14 The software shall allow the user to specify different networks on the same computer by allowing the opening of different copies of the software The software must be able to specify IPv4 networks The software may be customizable for IPv6 networks Technical Approach Object-oriented programming is well-suited for this task. The objective of this program is to create a large network based on many discrete and connectible elements. While two members in the group excel at Java, there is always the risk that one or both will not be with the project until the end. All four members have adequate experience with C++, so C++ will be the standard. If calls external to the program can and need to be made, these may be created in the author's preferred language. The parameter standards for this strategy do not exist yet since this is unnecessary but may be a superior approach in some instances. One of the objectives of this project is to create a cross-platform application. In order to facilitate this, a cross-platform graphics library must be used. In addition to the option of forsaking cross-platform compatibility, twelve cross-platform libraries shall be investigated: FLTK, FOX, SDL, Allegro, Kylix, Notus, MFC, the Mozilla framework, Qt, GTK, Java's Swing libraries (with a C++ backend), and wxwidgets. Only Qt must be commercially licensed; all others are available under an open source license. If none of the open source packages are satisfactory (that is, comparable in ease to Visual Studio) to create a GUI in, the application will be developed solely for Microsoft Windows with focus on XP Testing Requirements This section describes what testing requirements the test has developed in order to guarantee the successful completion of the project. Two months shall be left for testing which begins on March 7. At this point, there will be a feature freeze, meaning code may only be changed to fix bugs, not to add new functionality. Additionally, each of the classes needs to behave correctly independent of other classes. Unit testing will be used on each function s class, beginning with the superclasses. Whenever possible, large sets of automated testing will be done. The most pressing concern is that the user interface be functional. This involves making the interface simple while powerful, two sometimes 7

15 contradictory goals. In order to determine whether either of these goals was accomplished, outside testers will be found. Feedback sheets regarding ease of use both with and without the user documentation will be provided and interpreted, with the program being modified based on this feedback Security Considerations This section describes security concerns during the development of the product and during the operation of the end product by the customer. Although the client has not expressed any specific concerns regarding outsiders gaining knowledge of the project, the team has decided to use a password-protected tool called CVS as a repository for the software that will be created. While the end product is intended to test and thus improve network security, the possibility exists that the user might misuse the software by attacking actual networks based on weaknesses discovered through the software. Unfortunately, this misuse is beyond the team s control since preventing it would mean not fulfilling project specifications. Additionally, the end user must be prevented from accessing the underlying ISEAGE architecture via use of the software. The team will follow client specifications on how best to prevent this Safety Considerations Since the end product is software, there exist no threats to safety during the manufacture, use, maintenance, or disposal phases Intellectual Property Considerations While the team will make every effort to develop its own software, some proprietary or open source software might be necessary to aid the team in fulfilling the project specifications on time. In such case, all licensing requirements will be carefully reviewed and satisfied Commercialization Considerations The ISEAGE system, of which the software is a component, is a commercial product and all licensing requirements specified for ISEAGE will apply to the software. 8

16 Risks and Risk Management There are risks that the team faces that could impair the success of the project. This section addresses these possible risks and the efforts taken to minimize their impact Risk: Loss of team member. Assessment: All team members will keep the team updated of their progress on the project each week. Team members will also keep track of their progress in their log books. If a team member is unable to continue, the work of that member will be equally divided amongst the remaining team members Risk: Loss of data or source files. Assessment: All of the projects files and data will be kept in a CVS repository. This repository tracks all changes to data and allows the team to revert to a previous edition of the data in case of loss Risk: Unfamiliarity with GUI toolkits, GIS, and cross platform development. Assessment: The group will research the different GUI toolkits and GIS applications that are available as well as the area of cross-platform development. Each group member will share the results of their research in order to educate the rest of the group. Sufficient time will be built in to the schedule to allow for the learning of different technologies to be used Risk: Failure of proposed approach Assessment: The client will review all documentation in order to provide feedback on planning and features. All software progress will also be presented to the client for feedback Milestones and Evaluations This section describes the traits of each milestone, specifically description, evaluator, evaluation criteria, and overall importance. Description is a brief overview of the form each milestone takes. Evaluator is one of Client/Faculty Adviser (Dr. Doug Jacobsen fulfills both roles, so both are always listed together), Industrial Review Panel, and Team Members (listed on the title page). Evaluation criteria lists the goals of that milestone, taking the form of questions which, when answered in the affirmative, indicate the milestone has reached its goals. Degrees of affirmation are possible (see the following paragraph). Overall Importance describes the percentage of the project that should be considered to be comprised by that milestone. Several milestones are listed as bound/unbound. In these cases, unbound is a draft of the bound version, but the milestone is not 9

17 completed until the bound version. Revisions will take place between the two. The standard divisions of evaluation shall be used: Greatly exceeded, Exceeded, Met, Almost Met, Partially Met, Did Not Meet, and Did Not Attempt. Each of these corresponds to a percentage value, given in Table 1 below. Table 1 Project Milestone Evaluation Evaluation Project Grade Greatly Exceeded 100% Exceeded 100% Met 100% Almost Met 90% Partially Met 75% Did Not Meet 50% Did Not Attempt 0% The final percentage will be the sum of all milestones' percentage value of the degree of success reached multiplied by that milestone's overall importance, with overall success being achieved if this value is 85% or higher. Unbound/Bound Project Plan Description: Indicates the approach taken to create the project within the confines of the problem statement, operating environment, intended uses, and assumptions/limitations; specifically, how the project will be approached within these confines. Evaluator: Client/Faculty Advisor, Team Members. Evaluation Criteria: Are the project's goals well-defined? Are assumptions, limitations, and risks accounted for? Are the project plan's goals realistic and attainable? Is the approach appropriate? Overall Importance: 15% Unbound/Bound Design Report Description: The prototype design of the entire program. Included will be graphics, classes, functions, used external libraries, and other used resources. 10

18 Evaluator: Client/Faculty Adviser, Team Members. Evaluation Criteria: Can implementation be finished only within what is specified in the design document? Are graphics, classes, and libraries present and defined? Overall Importance: 15% Final Implementation Description: This is the actual program and GUI to stipulate networks on ISEAGE, created based on the design report. Evaluator: Client/Faculty Adviser, Team Members. Evaluation Criteria: Is the GUI intuitive? Can a user sit down and start using it right away? Does it export an interpretable XML document? Is there room for expansion in the XML document? Optional, but preferable: Can it view simulated traffic, either in pseudo-real time or post-simulation? Overall Importance: 20% Unbound/Bound Final Report Description: This is the final report, stating the conclusions of the group. Evaluator: Client/Faculty Adviser Evaluation Criteria: Has every component of the project been summarized completely and accurately? Is anything left out? Overall Importance: 5% End-User Documentation Description: The documentation a user is provided in order to be better able to use the program. Applies only as far as use, does not include inner workings. Evaluator: Client/Faculty Adviser. Evaluation Criteria: Can a user reliably use the documentation to determine how to use the system? Can a user perform simple technical repairs by referencing the documentation? Overall Importance: 10% Maintenance and Support Documentation Description: The documentation a maintainer needs to continue work on the program, which includes internal workings and explanation of logic behind design approaches. Evaluator: Client/Faculty Adviser. Evaluation Criteria: Can an individual use the documentation to understand, and then expand the system? Overall Importance: 10% 11

19 Faculty Advisor Demonstration Description: A demonstration of the final implementation to the faculty adviser. The adviser will be reminded of the goals of the project, then shown how the project meets these goals. Evaluator: Client/Faculty Adviser. Evaluation Criteria: Have the goals of the project as laid out in the project plan, been reached? Overall Importance: 10% Industrial Review Panel Demonstration Description: A demonstration of the final implementation to the Industrial Review Panel (IRP). The IRP will be given a description of the goals of the project, and then shown how the project reaches these goals. This is distinct from the faculty adviser demonstration since each occurs on a different date. Evaluator: Industrial Review Panel. Evaluation Criteria: Are the aims of the project clear? Does the project reach its goals? Overall Importance: 10% Weekly s Description: s sent each week describing the project status, accomplished goals for the previous week, and goals for the following week. Evaluator: Client/Faculty Adviser. Evaluation Criteria: Over the course of the s, can a reader gain a realistic assertion of the status of the project? Overall Importance: 5% Project Tracking Procedures A project tracking tool will be used to track the progress of the project. Group members will keep the team leader informed of what tasks are completed or open. The team leader will keep track of all such tasks and will discuss the schedule and status of the project at the weekly meetings. Each week the team will evaluate the project in comparison to the milestones that are established. If the team is behind schedule, a plan will be adopted so that the team will complete the next milestone on time. Each of these evaluations and resulting plans will be recorded in each team member s logbook. The team will also keep a record of the budget including labor hours. 12

20 2.2. Statement of Work Included in the statement of work is a detailed task-by-task and subtaskby-subtask definition of all phases that the project has been divided into. Listed under each task and subtask is its objective, how the team will approach it, and what the result of that task or subtask is expected to be. Task 1 Problem Definition Task Objective: To completely define all areas of the project and the problem the project will solve. Task Approach: The team will discuss the project with the client, and decide what the assumptions and limitations will be. In addition, the team will discuss thoroughly the project s scope, who will use the project, and how they will use it. This will enable the team to decide upon a clear definition of what the project is expected to accomplish and how the endproduct will be developed. Task Expected Results: A detailed account of what the end product will be expected to provide. Subtask 1a Problem Definition Completion Task Objective: To completely describe the problem. Task Approach: The team will initially list all functional requirements. The team will then discuss the assumptions and limitations of the project. After this, the team will be able to evaluate what the entire project is expected to do in addition to extra functionality that the team would like to include. Task Expected Results: A statement of what the end product is expected to do. Subtask 1b End-Users and End-Uses Identification Task Objective: To identify the primary users of this project. Task Approach: The team will ask, How does the end-user(s) affect the project requirement? In doing so, the team will consider who will use the completed system, and create a list of these end-users. Next, the team will look at each end user and discuss what the user will use the system for. This will help the team document the end uses. Task Expected Results: The team will have a list of the end-product s likely end-users and end uses. 13

21 Subtask 1c Constraint Identification Task Objective: To define all existing limitations. Task Approach: The team will ask, What conditions will the system need to work under? The team will discuss this with the faculty advisor and brainstorm all possible constraints that could be an issue. The team will then review the list of constraints and examine each one adding clarification when necessary and determine the impact of that constraint. Task Expected Results: A list of all known assumptions and limitations. Task 2 Technology Considerations and Selection Task Objective: To decide on the technology the project will be developed in. Task Approach: The group will discuss the problem definition, and decide upon what a technology needs to offer to be a viable solution. The team will create a list of several different technologies and consider how each one could be beneficial to the development of the system. Extensive research on each technology will be done. Finally, the team will decide on one or more of the technologies to be used in implementation of the system. Task Expected Results: Which platforms in addition to the clientspecified Windows OS to support, which graphics library to use, and which GIS software to use. Subtask 2a Identification of Possible Technologies Task Objective: To develop a list of possible programming languages to be used. Task Approach: Each team member will research and list all possible technologies that work with the selected programming language and necessary toolkits. The team will then review and discuss the list after which the team leader will divide up the more promising technologies among the members for further research. Task Expected Results: A list of potential technologies to be used in project development. Subtask 2b Identification of Selection Criteria Task Objective: To determine what is important in a programming language. 14

22 Task Approach: The team will examine the problem statement and requirements. The group will then discuss what features a programming language will need to have in order to meet project requirements and to see which toolkits are compatible with that language. Licensing and cost issues will be evaluated. Individual group member s familiarity and experience will also be considered. Task Expected Results: To decide the necessary features a programming language must provide. Subtask 2c Technology Selection Task Objective: To conclude the technology selection process. Task Approach: The selection criteria will be applied to the list of potential technologies and the team s combined research will be discussed. The team will discuss factors such as ease of use and additional features in a certain technology. Task Expected Results: The team will have decided on all necessary technologies needed to successfully implement the project in. Task 3 End-Product Design Task Objective: To create a formalized design document extensively detailing how the system will be implemented. Task Approach: The team will start by collaborating on defining the functional requirements and the problem statement to identify all design requirements. The team will then divide the system into class objects. Use-cases will be developed for the various user interactions with the system. A domain model will then be constructed and the use-cases will be formalized into a design document. Task Expected Results: The team shall have a detailed document of the project s planned design. Subtask 3a Identification of Design Requirements Task Objective: To decide upon design requirements to be used for the implementation of the project. Task Approach: The team will consider the problem statement and functional requirements. The group will then discuss what the design needs to accomplish. Should it be easy to add new features? Which design patterns will the team use if any? After collaborating on this, the team will put compile a list of design requirements. Task Expected Results: A list of design requirements. 15

23 Subtask 3b Design Process Task Objective: To identify the design of the system that will be used for implementation. Task Approach: Starting with the design requirements, the group will first construct use-cases for the internal system s interactions and decide upon the fundamental classes the system needs. After further specification of the attributes of each class, the group will consider their interactions with each other and construct a domain model. Task Expected Results: A detailed account of the system s construction. Subtask 3c Documentation of Design Task Objective: To create documentation of the system s design. Task Approach: To document the system s design the team will use UML specification to construct fully addressed use-cases for the system interactions. The team will also illustrate the domain model. Interaction diagrams will also be drawn to help show the systems inner workings, and how the classes react with one another. Task Expected Results: A document that will provide a convenient reference for the product design. Task 4 End-Product Implementation Task Objective: To complete the coding of the project. Task Approach: The team will begin implementation of the project using the previously decided programming language and any other technologies. It is the team s goal for the project to be always fully compileable with no run-time errors. For this reason, each team member will construct a module independent of the system and have it tested by another team member before uploading to the CVS. Task Expected Results: A working implementation of the project ready for extensive testing. Task 5 End-Product Testing Task Objective: To ensure that the program runs as expected and meets all requirements. Task Approach: The team will dedicate two months for testing. This includes unit testing, module testing, and global testing. The team will 16

24 also have the client test the program to make sure the project runs according to specification. Task Expected Results: An assertion of the accuracy and validity of the project. Subtask 5a Test Planning Task Objective: To develop a plan on how the program will be tested and what program features will be tested. Task Approach: The team will discuss unit testing, module testing, and global testing. The group will then go over what specifically needs to be tested in each case. Task Expected Results: A test plan to ensure nothing is missed when the test cases are written. Subtask 5b Test Development / Execution Task Objective: To write the test code that will be used on the program. Task Approach: First the team will first write unit tests and the author will run isolated tests on each class. The author will then have another team member test the same class prior to uploading into CVS. Then the group will divide up the task of connecting the individual classes together in order to run module tests. Finally, each member will run global tests on the complete program individually. Task Expected Results: Every class, every module, every line of code thoroughly tested. Subtask 5c Test Evaluation Task Objective: To evaluate the testing results. Task Approach: The following questions will be answered, Does the program meet all the requirements? and, Does it have any run-time errors? The team will consider this and decide if any changes need to be made. Task Expected Results: The team will have validation that the project meets all requirements and works the way it is supposed to. Subtask 5d Documentation of Testing Task Objective: To document the testing process. 17

25 Task Approach: The team will look at the testing process and document what was tested, what performed as expected, and what still needs to be worked on. Task Expected Results: Documentation providing the results of the team s testing on the project. Task 6 End-Product Documentation Task Objective: To put into writing documentation for both users of the end product as well as future teams maintaining or supporting the end product. Task Approach: The team will put into writing end-user documentation to cover the use-cases and to explain the system in a way that is understandable even to new users. The team will also create more detailed documentation for technical users who will be maintaining or supporting the system. This document will explain how the system can be upgraded. Task Expected Results: Documentation for new and technical users. Subtask 6a Development of End-User Documentation Task Objective: To provide documentation that will help end-users understand how to use the system. Task Approach: The team will create easy to follow instructions for all possible uses an end-user might have with the system. A frequently asked questions (FAQ) section will also be added to cover miscellaneous questions not covered in the main content. Tutorials, examples, and screenshots will be included to help the end-user s understanding. Task Expected Results: Documentation that will allow any end-user to understand and work effectively with the system. Subtask 6b Development of Maintenance and Support Documentation Task Objective: To provide documentation that will help future teams in the maintenance and support of the end-product. Task Approach: By detailing the specifics of each class and how they may be extended, the team will create documentation that will explain how the program may be updated or maintained in the future. Since the project is being programmed using an object-oriented design, this process will include how the classes are related to each other, and what can be done to add new features. 18

26 Task Expected Results: Documentation to help future maintenance and support of the project. Task 7 Project Reporting Task Objective: To keep all project members, clients, and interests updated on project status. Task Approach: The team will develop a project plan detailing the problem statement and how the group will work on the end product. The team will also develop a poster to summarize the project. Also, design reports and a final project report will be developed. In addition to this, the group will be sending weekly s to keep everybody informed, and up to date. Task Expected Results: Anyone who wishes can find out what the group has done, is currently working on, and has planned for the future. Subtask 7a Project Plan Development Task Objective: To develop a project plan to detail the problem statement and how the team will accomplish its goals. Task Approach: The team will consult with the faculty advisor and decide upon what the assumptions and the limitations of the project are. The team will also map out a schedule of tasks and milestones. All this, and an estimation of the expected work hours will be included in the project plan. Task Expected Results: A document stating what problem the group plans to solve, and how they will solve it. Subtask 7b Project Poster Development Task Objective: To create a poster summarizing the project and generating interest in the end-product. Task Approach: The team will develop a 40 by 32 poster using Microsoft PowerPoint. It will contain a project summary, assumptions, limitations, schedule, and estimated hours. The team will design the poster in a way that is both informative and visually appealing. Task Expected Results: A completed poster ready for display. Subtask 7c Project Final Report Development Task Objective: To construct a document detailing the project s development cycle. 19

27 Task Approach: The team will collaborate and using previous documentation, construct a final report. This report will include everything in the project plan, the design, testing process, what went well, what didn t, and effectively summarize the project s development cycle. Task Expected Results: This final report document will be used to help quantify the group s success with the project. Subtask 7d Weekly Reporting Task Objective: To keep all team members, faculty advisor, and Senior Design professors informed on the group s progress. Task Approach: Once a week, the group s communication coordinator will send out a progress report indicating what the group has accomplished during the week. This can include minutes from meetings, decisions the group has made, or deliverables that have been completed. Task Expected Results: Weekly reports sent via to all the recipients listed above. 20

28 3. Estimated Resources and Schedules This section includes an estimate of the resources required for the project. Resources defined include the number of hours team members will spend on different project areas, any equipment that will be necessary for the project, and the total dollar amount that the team will need for successful project completion Estimated Resource Requirements This section details estimated resource requirements for completing the Network Specification and Report System for ISEAGE. The estimated efforts of each team member and production costs are addressed Personnel Effort Table 2 shows the estimated number of hours that each team member will contribute to the different project areas. The hours have been distributed based on the individual team positions and technical backgrounds. David Rodgers, for example, as the team leader and the member most knowledgeable about different software packages useful in developing the project, is estimated to spend the most hours on researching and selecting the applications the team will work with. Additionally, Lijin Varghese, the communications coordinator, is estimated to spend the most hours on project documentation. Derek Light and Justin Magnini are quite similar in their level of technical expertise and thus it is estimated that they will be involved significantly in the end-product implementation and testing phases. Table 2 Personnel Effort in Hours Problem Definition Technology Consideration and Selection End-Product Design End-Product Implementation End-Product Testing End-Product Documentation End-Product Demonstration Project Reporting Total David Rodgers Lijin Varghese Derek Light Justin Magnini Total

29 Note that the end-product demonstration is equally distributed among the members since this will be a team effort for both the preparation and the actual presentation Other Resources A list of items other than financial resources that will be required to conduct the project is shown in Table 3. Printing expenses include poster costs, binding costs, and printing costs for things such as reports, documentation, etc. An amount for miscellaneous parts has also been added in order to compensate for any unexpected costs that come up during a project term. Table 3 Other Resource Items and Costs Item Cost Printing Expenses Including Poster $75.00 Miscellaneous Parts $45.00 Note that since the end product is software, and since the team is attempting to use as much open source software as possible to develop the end product, no costs have been listed for applications. Although the client already has in his possession most equipment that the team may need, it is very likely that no such equipment will be needed. Hence, no compensation has been included for such equipment Financial Requirements This section discusses the expected costs of the project. Table 4 below represents the approximate estimates for the project with and without labor costs of the team members. The items have been separated into two sections: parts and materials expenses, and labor costs. Poster costs, printing costs, binding costs and an item for miscellaneous expenses are included in the first section. Labor costs include the amount each team member would have earned based on their hours and an $11/hour wage. The wage was selected to be a little less than twice the minimum wage for the sake of convenience. As the table shows, the amount earned is proportional to the total individual hours spent on the project. 22

30 Table 4 - Financial Requirements Item Without Labor With Labor Parts and Materials a. Project Poster $50.00 $50.00 b. Other Printing $5.00 $5.00 c. Binding $20.00 $20.00 d. Miscellaneous $45.00 $45.00 Subtotal $ $ Labor (at $11.00/hr) David Rodgers $ Lijin Varghese $ Derek Light $ Justin Magnini $ Subtotal $ Total $ $ Expenses with and without labor are also listed. The items under Parts and Materials, are assumed to cost as much by themselves as much as the total wages paid for accomplishing the tasks associated with those materials Schedules This section illustrates the schedule that the team has created in order to achieve successful project completion. Figure 1 below is a Gantt chart illustrating the team s proposed schedule listing when all defined project phases is estimated to be completed. Figure 2 is another Gantt chart illustrating the team s project deliverables. This chart provides a schedule of when major documents, reports, demonstrations, and the end product will be completed and submitted. 23

31 Figure 1 Project Milestones Figure 2 Project Deliverables 24

32 4. Closure Materials This concluding section includes contact information for all significant parties involved in the project. Also included are a closing summary intended to give the reader a final perspective on the whole project and a list of references the team will be using during the course of the project. 4.1 Project Team Information This section includes contact information for the client, the faculty adviser, and the team members. Team positions and major(s) of study are also listed Client Information ISU Information Assurance Center Dr. Douglas W. Jacobson 2419 Coover Hall Ames, IA dougj@iastate.edu Faculty Advisor Dr. Douglas W. Jacobson 2419 Coover Hall Ames, IA dougj@iastate.edu Team Members David C. N. Rodgers (Team Leader) Computer Engineering, Computer Science 210 Campus Ave., #6 Ames, IA (cell) poeir@cs.iastate.edu Lijin Varghese (Communications Coordinator) Computer Engineering 410 Welch Ave., #8 Ames, IA (cell) enzyme6@iastate.edu 25

33 Derek J. Light Computer Engineering 3115 Frederiksen Court Ames, IA (phone) (cell) Justin Magnini Computer Engineering 217 S 5th, #6 Ames, IA (phone) (cell) jmagnini@iastate.edu 4.2. Closing Summary In the wake of recent terrorist attacks, government agencies are urgently seeking to protect critical internet-based infrastructure from the threat of cyber attacks. To prepare for the potential onslaught, the ISEAGE Network Specification and Report System will enable individuals to configure a virtual network on actual hardware. This hardware will then face actual attacks which will be logged along with other traffic in order to evaluate which operating environments provide optimal security. The software will enable ISEAGE to potentially prevent large-scale infrastructure attacks. 4.3 References Although no references have been utilized as of yet, it is quite likely that the team will need to refer to documentation especially in the case of the GIS software and quite likely for the GUI development application as well. 26