Project Plan
Using CLIPS to Detect Network Intrusions - (CLIPNIDS)
Submitted in partial fulfillment of the requirements of the degree of
Master of Software Engineering
Sripriya Marry
CIS 895 – MSE Project
Computing and Information Sciences
Kansas State University
Committee Members
Dr. David Gustafson (Major Professor)
Dr. Rodney Howell
Dr. Mitchell Nielsen.
1
Change Log
Version #
Changed By
Release Date
Change Description
-----------------------------------------------------------------------------------------------------------------Version 1.0
Sripriya Marry
02/20/2013
2
Initial Release
Table of Contents
1. Introduction ..................................................................................................................................... 4
2. Work Breakdown Structure ............................................................................................................ 4
2.1 Inception Phase .......................................................................................................................... 4
2.1 Elaboration Phase
.................................................................................................................. 4
2.2 Production Phase ....................................................................................................................... 5
3. Cost Estimation ................................................................................................................................ 6
4. Gantt Chart ....................................................................................................................................... 8
5. Architecture Elaboration Plan .......................................................................................................... 9
5.1 Revise Vision Document 1.0 ..................................................................................................... 9
5.2 Revise Project Plan 1.0 .............................................................................................................. 9
5.3 Architectural Design 1.0............................................................................................................ 9
5.4 Developing Prototype ................................................................................................................ 9
5.5 Test Plan .................................................................................................................................... 9
5.6 Formal Technical Inspections ................................................................................................... 9
5.7 Formal Requirements Specification1.0 .................................................................................. 10
3
1. Introduction
This document provides an overview of project plan. This document will mainly list down the various
tasks which include work breakdown structure, the cost estimation using COCOMO model and activities
which are planned for various phases of the project.
2. Work Breakdown Structure
This mainly list down various tasks identified in various workflows and their assignments to different teams
and individuals. This includes three phases which are “Inception”, “Elaboration” and “Production”. The
first two are the engineering phases and the third is the production phase.
Phase
Completed by
Inception Phase
February 20 2014
Elaboration Phase
March 20 2014
Production Phase
April 20 2014
2.1. Inception Phase
The first phase of a software development cycle is Inception Phase. The primary goal of Inception phase
is to capture the requirements for the project, estimating the costs, schedule and effort. Since this project
is updating an existing product, this phase brings to light an original vision of a potential product, and
transforms it into an actual project. Its purpose is to establish a major update, and to specify the project
scope. For the evolution of an existing product, this may be a simple and short phase, based on new
technological advances like evolving signatures of new threats or attacks.
Entry criteria:

An original vision – This is the research publication paper that describes Clipnids.

A legacy system – The Clipnids package built in 2003.

Some assets - This includes software and support from the author in using and executing
Clipnids.
Exit criteria:

Vision Document 1.0 - focuses on requirement elicitation, scope, purpose, and goals of the
project.
4

Project Plan 1.0 - describes the tasks carried out in each phase and estimates the cost, effort and
schedule.

Software Quality Assurance Plan - describes the standards and conventions of the project,
required project documentation, steps to be taken to ensure project quality.

Workable Prototype – The legacy system received as an input will be successfully built using
latest libraries like libpcap, libglib2.0, g++, automake and libclips. This will demonstrate the
feasibility of the project and will also prepare the initial baseline of the code on which will be
updated to achieve the goal of the project.
All these deliverables need to be approved by committee to move into the next phase of project.
2.2. Elaboration Phase
The main idea behind the elaboration phase is to develop an architectural design for the project by doing
more thorough analysis of problem domain. In this phase, the architectural design will be documented
using the applicable UML diagrams. Each component will be documented at the interface level.
Entry criteria:

The products and artifacts described in the exit criteria of the inception phase.

Suggestions given by the supervisory committee at the end of Inception phase for vision
document and project plan.
Exit criteria:

Vision Document 2.0 - revised version of the document, as per the suggestions given by the
supervisory committee at the end of Inception phase

Project Plan 2.0 - revised version of the document, as per the suggestions given by the supervisory
committee at the end of Inception phase.

Architectural Design – it will be Clipnids software architecture description stating constraints and
limitations.

Test Plan – it documents all the testing activities that should be performed on Clipnids.

Formal Requirement Specification - it helps in uncovering risks and making sure all requirements
is captured.

Formal Technical Inspection Letters – these documents are given by two technical inspectors who
will perform an architectural review based on the checklist given and provides the feedback

Architecture Prototype - it will address at least the top key use cases identified in the inception
phase. This will be an evolutionary prototype, of production quality code which becomes the
5
architectural baseline, but it will not exclude the development of one or more exploratory, throwaway prototypes to mitigate specific risks: refinements of the requirements, feasibility.
All these deliverables need to be approved by committee to move into the next phase of project.
2.3. Production Phase
This phase comprises the construction and transition phases. The main goal of the production phase
will be to implement and test the project. By the end of this phase all the required documentation and the
entire code will be constructed. During this phase all the code of the project will be tested using the test
plan documented in the Elaboration phase. The test will be carried out to ensure that all the requirements
mentioned in the vision document 2.0 are met. Then the test results are analyzed and documented. A User
manual which contains the directions of using the website would be created.
Entry criteria:

The products and artifacts described in the exit criteria of the inception phase and elaboration
phase.

Suggestions given by the supervisory committee at the end of elaboration phase for items that
were signed off.
Exit criteria:

User Manual

Component Design 1.0

Source Code

Assessment Evaluation

Project Evaluation

References

Formal Technical Inspection Letters

Presentation 3
All these deliverables need to be approved by committee.
3. Cost Estimation
COCOMO
The COCOMO cost estimation method, abbreviated as The Constructive Cost Model is developed by Barry
W. Boehm and is used to estimate effort, cost and schedule for the project. The effort and time can be
estimated by the following equations:
Effort = C1 * EAF * (Size)P1
6
Time = C2 * (Effort)P2
where:
Effort = number of person-months
Time = duration time in months for the project
C1= constant scaling coefficient of effort
C2= constant scaling for schedule
P1= exponent that characterizes the economics of scale inherent in the process used to produce
the end product
P2= exponent that characterizes the inherent inertia and parallelism in managing a software
development effort.
EAF= effort adjustment factor that characterizes the domain personnel, environment, and tools
used to produce the artifacts of the process.
Size= size of the end product, measured by the number of delivered source instructions i.e.
number of thousand source lines of code
There are three different development modes which include Organic, Semidetached and Embedded
modes. This project can be categorized under Organic mode as it is fairly simple, developed by a single
programmer and very flexible. As the project is in Organic Mode
C1= 3.2
C2= 2.5
P1= 1.05
P2= 0.38
Therefore we calculate Effort and Schedule by following equations
Effort = 3.2 * EAF * (Size)1.05
Time = 2.5 * (Effort)0.38
EAF Calculation
EAF, abbreviated as Effort Adjustment Factor is the product of the 15 adjustment factors that normalizes
the Effort. Each adjustment factor is classified as Very Low, Low, Nominal, High, Very High or Extra
High and the value of each adjustment factor lies within specific range. So by knowing the calculation,
value can be determined by also considering the range which means the value falls within the range. The
table below shows the list of all the adjustment factors and their respective ranges.
Parameter Name
Effort Adjustment Factor
RELY
Required Reliability
0.75-1.40
DATA
Database Size
0.94-1.16
CPLX
Product Complexity
0.70-1.65
7
Value Range
TIME
Execution Time Constraint
1.00-1.66
STOR
Main Storage Constraint
1.00-1.56
VIRT
Virtual Machine Volatility
0.87-1.30
TURN
Computer Turnaround Time
0.87-1.15
ACAP
Analyst Capability
0.71-1.46
AEXP
Applications Experience
0.82-1.29
PCAP
Programmer Capability
0.70-1.42
VEXP
Virtual Machine Experience
0.90-1.21
LEXP
Language Experience
0.95-1.14
MODP
Use of Modern Practices
0.82-1.24
TOOL
Use of Software Tools
0.83-1.24
SCED
Required Development schedule
1.10-1.23
Values of the Effort adjustment factors for this project are given below
Parameter
Value
Level
RELY
1.00
Nominal
DATA
1.08
High
CPLX
1.15
High
TIME
1.11
High
STOR
1.06
High
VIRT
0.87
Low
TURN
1.00
Nominal
ACAP
0.86
High
AEXP
1.00
Nominal
PCAP
0.86
High
VEXP
1.10
Low
LEXP
0.95
High
MODP
1.00
Nominal
TOOL
1.00
Nominal
SCED
1.00
Nominal
So to calculate the EAF we have to multiply all the values by which we get the Effort Adjustment Factor
as 0.982.
8
Size Estimation
I estimate the size to be 1.5 as I am using the Visual Studio it reduces the amount of code to the
maximum.
Therefore by substituting the EAF and Size values in the below equations we get
Effort = 3.2 * 0.982 * (1.5)1.05 = 4.81 staff months
Time = 2.5 * (4.81)0.38 = 4.54 months
4. Gantt Chart
1/23/14 1/30/14 2/6/14 2/13/14 2/20/14 2/27/14 3/6/14 3/13/14 3/20/14 3/27/14 4/3/14 4/10/14 4/17/14
Inception Phase
Vision Document 1.0
Project Plan 1.0
SQA Plan
Prototype
Presentation 1
Elaboration Phase
Vision Document 2.0
Project Plan 2.0
Formal Specification
Architectural Design
Test Plan
Inspection checklist
Inspection
Prototype
Presentation 2
Production Phase
Component Design
Develop code
Testing
Documentation
User Manual
Project Evaluation
Presentation 3
Start Date
Duration
5. Architecture Elaboration Plan
By the Architecture Elaboration plan the following tasks and documents should be completed.
5.1. Revise Vision Document 1.0
The Vision Document 1.0 will be revised in order to make sure that all the requirements are stated which
are required for the project. The requirements should be in the order of their priority. If supervisory
committee suggests any changes at the end of the Phase I presentation, the changes will be reflected in the
9
revised vision document. After making the necessary changes, revised vision document, named Vision
Document 2.0 will be submitted to the supervisory committee at the end of the Phase II.
5.2. Revise Project Plan 1.0
The Project plan 1.0 document will be revised and if necessary, the changes will be made to the estimated
Effort, size and cost. Also, the Gantt chart will be updated with the changes in the schedule. If supervisory
committee suggests any changes at the end of the Phase I presentation, the changes will be reflected in the
revised Project Plan document. After making the necessary changes, revised Project Plan document,
Project Plan 2.0 document will be submitted to the supervisory committee at the end of the Phase II.
5.3. Architectural Design 1.0
The complete project design will be documented with the applicable UML diagrams. Each component in
the architecture will be documented at the interface level. Then the document would be submitted to the
supervisory committee at the end of Phase II by naming it as Architectural Design 1.0.
5.4. Developing Prototype
The Prototype of the project will be built by considering the requirements mentioned in the Vision
document 2.0. Then the prototype which finalizes the architectural baseline would be submitted to the
supervisory committee at the end of the Phase II.
5.5. Test Plan
A Test Plan will be developed to ensure that all requirements mentioned in the Vision document 2.0 are
satisfied in the project. The Plan will include the evaluation criteria for all the critical use cases. Then the
document will be submitted to the supervisory committee at the end of Phase II for approval.
5.6. Formal Technical Inspections
The architectural design will be inspected by the two MSE students, Denise Case and Sri Priya. The
checklist will be provided by the developer and then the technical inspectors go through the project based
on the checklist and provide the feedback.
5.7. Formal Requirement Specification 1.0
The Object Constraint Language will be used to define and verify the formal specification of the product.
10