SDPDocument (2)

7/30/2019 SDPDocument (2)

1/26

Environment Remote

Sensing SystemSoftware Development Plan - Group 4

Adam Blaine, Craig Cabrey, Peter Mikitsh, Kristen Mills

Page 1 of 26


2/26

Table of Contents

Section 1: Overview

Section 1.1: Assumptions

Section 2: Goals & Scope

Section 2.1: In scope

Section 2.2: Out of scope

Section 3: High-Level Functionality

Section 3.1: Administration

Section 3.2: Monitoring

Section 3.3: Sensor Stations

Section 3.4: Sensors

Section 4: Deliverables

Section 4.1: Release 1

Section 4.2: Release 2Section 4.3: Release 3


Section 5: Project Organization

Section 5.1: Roles

Section 5.2: Structure

Section 5.2.1: ERSS Application Server

Section 5.2.2: ERSS Station Server

Section 5.2.3: ERSS Sensor Clients

Section 6: Risk Management

Section 7: Scheduling & Estimates

Page 2 of 26
https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.uiktpzz7nj7zhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.8jfgs141otnkhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.jyjx9widkb5lhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.i9n77vv0g8ddhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.kqvguv98dw5https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.op9bqs9hcu43https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.sjj17zqgcy83https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.5hied9qv9tauhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.hgkyz4izfht2https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.300w7jhwi28shttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.qux7qlw03mushttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.y0y7pssv8vaohttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.gofecgtxsoxyhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.5gxers8fozwuhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.1dejmdzfzunohttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.ffoggki6uqpyhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.93s8tzmfggg4https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.5x9yb4j2aabhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.7nwxdqa2syarhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.2kj30cx1l0ukhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.3fjgiydr59ihttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.yp8pcigclwajhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.ytzie828n1dq


3/26

Section 7.1: Scrum Methodology

Section 7.1.1: Feature Estimation

Section 7.1.2: Scheduling

Section 7.2: RUP MethodologySection 7.2.1: Size Estimation

Section 7.2.1.1: Application Server Size

Estimation

Section 7.2.1.2: Station Server Size Estimation

Section 7.2.1.3: Sensor Client Size Estimation

Section 7.2.2: SchedulingSection 8: Measurements

Section 8.1: User/customer satisfaction

Section 8.1.1: How will it be used

Section 8.1.2: Why was it chosen

Section 8.2: Number of defects found during

development

Section 8.2.1: Usage

Section 8.2.2: Rationale

Section 8.3: Number of defects found after a release



Section 8.4: Number of changes or change requests

Section 8.4.1: UsageSection 8.4.2: Rationale

Section 8.5: Documentation completeness/accuracy



Page 3 of 26
https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.9pf3l86s8h3chttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.bmetpa9e1tsqhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.i6n08tzca808https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.v8zent6ijw56https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.p59q7zblholkhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.mb9jpfa6uu46https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.5uz9l16yzd9ehttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.qx1rm4teydgyhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.e5aaze1k8pvhhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.d9v38ndfvjgohttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.hyt01nk2pzxzhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.zc1paabx5qinhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.zc1paabx5qinhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.gwm4pze4zusehttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.d0bn6y8wq77vhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.fk65o7bvv8bvhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.frb4r3m1uo23https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.8yw56760jxn0https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.kdmmkfc7c273https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.h1jwgtqfvn7ehttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.54jbyxecbfkqhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.54jbyxecbfkqhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.4kynzqdszq73https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.8lderrf9ju95https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.s5w7bkci2x4ihttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.uegr4i2dqphrhttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.8le462j687sr


4/26

Section 9: Technical Process

Section 10: Conclusion

Section 11: Glossary

Page 4 of 26
https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.7k78yzdlwsn8https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.2ch5avplg75shttps://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#heading=h.tb5k8vojjcd1


5/26

Section 1: Overview

This Software Development Plan for the Environment Remote Sensing System (ERSS) will

cover the functionality, platform, customers, schedule, and development responsibility of the

system. The primary goal of the system is to allow a non-profit environmental organization tomonitor migration and behavioral patterns of animals that are endangered or protected species.

Various sensor stations, which are part of a national network, will be placed in the proximity of

the areas being studied. Statistics from sensors will be sent to the sensor stations on regular

intervals. Administrators will be able to view the collected information and permit users at

specific locations to view specific collected information. Users with appropriate versions will be

able to generate reports and maps of the information.

Customers of the system include the non-profit environmental group, the Department of

Environmental Conservation (DEC) and the National Park Service (NPS), an agency operatingwithin the Department of the Interior (DOI).

Section 1.1: Assumptions

Assumption Description

Connectivity This system assumes the existence of aconnection between the main applicationserver and all stations that the applicationserver is configured for. The stations arecapable of buffering data up to a certainextent, but after this threshold is reached datamay be lost.

Hardware Malfunctions The ERSS assumes that all sensor hardwarewill work as intended and is not designed tohandle or detect any type of hardware error.Furthermore, the ERSS does not have anysafety alert systems built in as a result ofhardware failure.

Power Interruption The ERSS assumes that all systems will beup and online at all times. Any potential powe

issues caused by human error or naturalcauses should be taken care of via a devicessuch as a universal power supply.

Software Environment The ERSS application and station softwarewas designed to run on POSIX compatibleoperating system. The ERSS assumes theuse of this type of operating system.

Page 5 of 26


6/26

Team Size We are assuming that the team size will belarge enough to accommodate the breadth ofthe project.

Budget We are assuming that there is a significant

enough budget to be able to support theproject in its entirety ranging from use oftechnology, to employees, to release andmaintenance of the ERSS.

Schedule We are assuming that there will be enoughtime given and scheduled such that theproject will be able to be accomplishedreasonably.

Government Constraint Given that this is a government project therewill be exceeding constraints involvingsecurity, scalability, deadlines, and budget.

Section 2: Goals & Scope

Section 2.1: In scope

The Environment Remote Sensing System (herein referred to as the ERSS) will target a

number of features and functionality points. The core functionality that is delivered by the ERSS

is to provide a mechanism by which large amounts of data can be collected from a variety of

remote locations. To achieve this, the ERSS will be designed as a hierarchical system. The core

collection component will be realized as an application on a central server. From there, each

remote location will feed the central application server with information through a standard

protocol developed for the ERSS. While the ERSS will provide a generic solution for the station

that will connect to the central application server, the client will be able to modify the

implementation to meet their specific needs. See Section 3: High-Level Functionality for more

specific details on the products functionality requirements.

Section 2.2: Out of scope

The ERSS focuses on the software implementation more than the hardware

implementation, so any hardware design will be out of the scope of the ERSS. This include

everything from communication arrays on sensor stations to the sensor implementationsthemselves. Finally, the interfacing between the hardware and software is also considered out of

scope. The ERSS uses standard protocols to communicate with all clients and devices, so the

ERSS depends on those devices properly implementing standard protocols.

Page 6 of 26
https://docs.google.com/a/g.rit.edu/document/d/s9lzwQn7Ifuy96mE4se-1sA/headless/print#bookmark=id.yw98wb6lk8tg


7/26

Section 3: High-Level Functionality

Section 3.1: Administration

The system should run from a central application server

Application server will grant access to stations to different users depending onaccess privileges

Managers can set privileges for users Through the interface, users are able to filter the incoming data from the different

stations to which they have access

New stations can be added as clients to the application server

Critical events will be reported to users depending on the locality of the event Sensor issues will be reported to the local station to which the sensor has

been added

Station connectivity issues will notify users of the central server of theissue

Each station should act as a sensor data collection server

Sensors may be polled for updates on a certain time interval (configurable) Each sensor can be added as a client to its local data collection server

Sensors should be set up for the type of data collection they support (GPS, audio,images, etc)

Section 3.2: Monitoring Monitoring of sensor stations should be done through a per-user based user interface

When a user logs into the system, only the stations he or she has access to will

be displayed

A User may view any historical data associated with the stations that they

currently have access to

The status of the monitoring stations the user has access to will be

updated on a certain time interval (configurable from only the management

interface)

A user will be able to export collected data in a variety of forms

Raw data exported will be supported

Generation of reports will also be supported (charts, time series, etc)

The management interface will have configurable options that relate to the monitoring

system

A limit can be set of the amount of historical data is retained (weeks, months,

years, etc)

A limit can be placed on how far back the user is allowed to go through historical

Page 7 of 26


8/26

data (only when their account was created, some time period, or no restriction)

Options such as how often new data should be retrieved from the client

monitoring stations will also be configurable from the management interface

The user and management interfaces themselves may be implemented through various

means such as native (and mobile) applications and a web interface

Restrictions may be placed on how the application can be accessed (i.e. a usermay be restricted to only using the application installed on company computers)

Section 3.3: Sensor Stations

Must be able to be hooked to a networked PC

Antennas and hardware deployed by a third party

Variety of hardware supported if hardware supports standard protocols

PC can be networked through a landline connection, cellular connection, etc

Connected to a national grid.

This allows for DEC to run and monitor the status of all of the data in the grid

Software is configured to access (and authenticate through) centralauthentication server which in turn allows access to all configured sensor

stations

Section 3.4: Sensors

Sensors monitor information including body temperature, GPS location, gyroscope data,

audio, and video.

The ability to monitor additional types of information over time will be supported. Sensors collect information on configurable, regular intervals.

Sensor data is transmitted to the station on its own configurable, regular interval. Collected data is also buffered for one long data burst in the case of a weak signal Burst will occur if and when the sensor comes back into range

Sensors are first paired with sensor stations to set up communication with the sensor

station

Pairing with the station includes identifying the type(s) of information that theindividual sensor collects and which protocol it uses to relay that data

Page 8 of 26


9/26

Section 4: Deliverables


For release 1 we would like the following features to be implemented:

Set user privileges

Adding new stations

Login to the system

Restrict how a user access the system

Retrieve information from the sensors

Pair sensors with the sensor stations

We also plan to have a large portion of the documentation done with this release.



Allow the DEC Personnel to access the information collected from all of the state parks

Allow the user to view historical data of the stations they have access to

Allow for export for raw data

Limit how far back personnel can go back in historical data

Configure how often data is retrieved from the mentoring station



Filter incoming data from stations a user has access to

Notification of critical events

Get sensor updates at configurable time intervals

Configure which type of data a sensor collects

The ability to generate reports

Set how long historical data is retained



Maximize uptime of system

Online configuration of stations (including the ability to add more stations)

Automated database backup system

Add Interface for extending or accessing the ERSS through plugin architecture

Page 9 of 26


10/26

Section 5: Project Organization

Section 5.1: Roles

The development of the ERSS will make use of sub-teams to focus on the completion ofindividual components within the system. The following table describes the different roles that

will be utilize and their accompanying description.

Role Description

Project Manager Responsible for the overall progress, quality,and completion of the ERSS. All team leadsreport to the project manager for progress onindividual components.

Team Lead Responsible for the teams respectiveprogress, quality, and completion of acomponent of the ERSS. The team lead isresponsible for managing his own team andsetting the goals within the scope of the team.

Project Architect Responsible for the technical aspect of architecting the ERSS. Overall system is splitinto a number of components and from thereteams are created based on the identifiedcomponents.

Customer Liaison Represents the customer and can interactwith the project manager to give feedbackbased on the projects performance as wellas add or remove features from the overallproject. Also responsible for ensuring allappropriate measures are taken to mitigatedelays of project occurring due tobureaucracy.

Test Lead Responsible for developing and executingintegration tests. Test Lead mustcommunicate with each teams tester to keeptrack of overall test progress. Continuousintegration is performed and feedback is giveto each team to mitigate integration problemstowards the end of the project.

Team Developer Acts as an implementer for the teamsassigned component. Works with the teamlead and tester to ensure requirements arebeing met and that the test suite is developed

Page 10 of 26


11/26

to accurately test the developed component.

Team Designer Works with the component assigned to theteam to develop a software design that meetsthe goals of the component while working

within the constraints imposed by the overallproject. Works with the project architect toensure that the proposed design fits andworks well within the overall system.

Team Tester Responsible for developing and executing atest suite that covers the teams assignedcomponent. Tester is also responsible forreporting breakage to the Team Lead so thatcommunication remains fluid between thewhole team and the project manager.

Team Integrator Responsible for integrating anysub-components within the teamscomponent as a result of the componentssoftware design. Works with the tester andteam developers to ensure the component issuccessfully integrated continuously andpasses all developed tests.

Contractor A general outside resource that may be usefulfor the development of certain parts of theERSS. Contractors are not responsible forthe completion of components and teamleads that utilize said resources are

responsible for monitoring the status ofcontractors work.

Section 5.2: Structure

The structure of the projects resources is based off of how the project is designed from a

technical aspect. Because of the use of a largely client - server design, the overall project

development structure will be split into three major teams.

Each team will be composed of at least the following:

Team Lead

Team Designer

Team Developer(s)

Team Tester

Team Integrator

Contractor if necessary

Page 11 of 26


12/26

Section 5.2.1: ERSS Application Server

Within this team, there will be three more teams created:

ERSS Web Interface and Management Team

Backend and Database Team

Data Collection and Station Connectivity Team

Section 5.2.2: ERSS Station Server

Within this team, there will be four more teams created:

Station Interface and Management Team

Data Buffering and Backup Team

ERSS Connectivity Team

Sensor Connectivity and Collection Team

Section 5.2.3: ERSS Sensor Clients

Within this team, there will be three teams created:

Hardware Interfacing Team

Power Management Team

Station Connectivity Team

Additionally, the Hardware Interfacing Team will be making use of contractors that are familiar

with the hardware that is being used for the collars to be placed on the tracked animals. These

contractors will help improve the quality and speed up the development process and learning

curve of understanding the hardware components being used.

Page 12 of 26


13/26

Section 6: Risk Management

ID Description Type P L(weeks)

E FirstIndicator

MitigationApproach

1 Imprecise timeestimation

Schedule 0.7 4 2.8 Goals arenot beingmet insmallerdeadlines.

Spend slightlymore time withscheduleplanning andtime estimationsuch that it willbe as close aspossible.

2 Project scopeexpansion/featur

e creep

Budget 0.3 3 0.9 Declaredscope is

veryspecific andrigid

Make scopeslightly broader

in order to allowfor expectedchange.

3 Lack ofcommunicationin team.

Operational 0.6 2 1.2 There isredundancyin workacrossteammembers

Have regularteam meetings,with transparentgoalsaccessible at alltimes.

4 The

requirementselicitationprocess is slowwhen workingwith thegovernment.

Slow

Environment

0.2 4 0.8 There is

little to nofeedback orthefeedbacklags behindtheproposal.

Actively involve

the customer inthedevelopment ofthe proposal.

5 Reliance uponsilver bullets

Technical 0.3 3 0.9 More time isspentresearchingtechnologie

s thancontributingto theproject.

Identify alltechnologiesthat should beinvestigated

beforehand andset a timeframefor the results oftheinvestigation.

6 Product isLarger than

Schedule 0.4 4 2.8 Initialdeadlines

Involve expertsoutside of the

Page 13 of 26


14/26

Estimated set by thescheduleare missed.

project to helpreevaluate thescope and sizeof the projectand reevaluate

the schedule asa result.

7 Too muchformality(bureaucraticadherence tosoftware policiesand standards)results inunnecessary,time-consuming

overhead.

Process 0.3 5 1.5 When itfeels likethe projectis starting totendstowardsthrashingrather thanproductive

work.

Identify allproper channelsforcommunicationbefore the startof the project.Have adesignatedteam member

responsible forensuring allbureaucraticdeadlines aremet.

8 Productdepends ongovernmentregulations,which changeunexpectedly.

ExternalEnvironment

0.15 6 0.9 New billgoingthroughwhichaffectsprojectscope.

Identify allcurrentregulations andregulations thatare currentlypending thelegislationprocess.

9 Process isapplied too lateand the projectstalls.

Process 0.2 2 0.4 There arehigh levelsof thrashingwhile noprocess isinitiallyestablished

Start the projectwith welldefined process

10 Difficult projectmodules

integration

Technical 0.3 1 0.3 Design of the project

did notconsiderintegrationof modules,or nothought wasput intointegration.

Have a designthat thoroughly

plans for easeof integrationand is focusedon modularity.

Page 14 of 26


15/26

There arelots ofmodulesinvolvedthat are

complex.

Page 15 of 26


16/26

Section 7: Scheduling & Estimates

Section 7.1: Scrum Methodology

Section 7.1.1: Feature Estimation

The following table details how Scrum Feature Estimation is implemented. The user description

table identifies all actors in the system. Following the user description table is the estimation

table, which is a list of features with assigned story points.

User Description

User Any role detailed in the system below.

DECPersonnel

The people at the DEC (Department of Environmental Conservation)Headquarters in Washington.

National ParkPersonnel

The people at the national parks who install the system and monitor it locally

National ParkManagers

The people at the national parks who have admin privileges.

id Story Points User Action Goal Priorities

00 4 As a DECPersonnel,

I want to accessthe informationcollected from allNational Parkstations

So that I can generatenation-wide statistics.

Medium

01 2 As aNationalParkManager,

I want to be ableto set userprivileges,

So that I can manage mypersonnels access ofsystem features.

High

02 4 As a User, I want filter

incoming datafrom station that Ihave access to,

So that I can generate

reports.

Low


I want add newstations,

So that I can collectinformation from morenational parks asnecessary.

High

Page 16 of 26


17/26

04 3 As a User, I wantnotifications ofcritical events,

So that I can respond tothem.

Low

05 5 As a User, I want to get

sensor updatesat configurabletime intervals,

So that I have choice in

the granularity in thegenerated reports.

Low


I want toconfigure whichtype of data asensor collects,

So that I can adapt to newneeds over time.

Low

07 2 As a User, I want to be ableto login to thestations that Ihave access to,

So that I can use it. High

08 5 As a User, I want to viewhistorical data ofstations I haveaccess to,

So that I can generatereports of historical data.

Medium

09 2 As a User, I want to exportraw data,

So that I can play with it. Medium

10 6 As a User, I want to generatereports,

So that I can do my job. Low


I want to set forhow longhistorical data isretained,

So that I can managespace constraints of datacollected.

Low


I want to placelimits on how farmy personnel cango back inhistorical data,

So that I hide the secrets. Medium

13 4 As a

NationalParkManager,

I want to

configure howoften data isretrieved from themonitoringstation,

So that I can control

power consumption withinthe system.

Medium

14 6 As aNationalPark

I want restricthow a user canaccess the

So that my personnel onlyaccess the system onauthorized machines.

High

Page 17 of 26


18/26

Manager, system,

15 5 As a User, I want retrieve theinformation fromsensors,

So that I can monitor it. High


I want be able topair a sensor witha sensor station,

So that I can retrieve datafrom it.

High


User Story ID Start Date(weeks)

End date (weeks) Duration (weeks)

00 7 12 5

01 1 4 3

02 13 18 5

03 1 2 1

04 15 19 4

05 16 23 7

06 17 21 4

07 2 5 3

08 7 14 7

09 8 11 3

10 19 28 9

11 20 24 4

12 9 14 5

13 10 15 5

14 3 10 7

15 4 11 7

16 5 12 7

Page 18 of 26


19/26

Section 7.2: RUP Methodology

The RUP Methodology requires certain tools (Rational) to be used and documentation to be

available for the methodology to work as intended. Additionally, RUP calls for the use of the

COCOMO model to estimate the size and effort of the system in terms of person-months.

Section 7.2.1: Size Estimation

Section 7.2.1.1: Application Server Size Estimation

Module Name SLOC Person-Months No. of People Productivity

ManagementInterface

15,000 10.6159 6 1412.97

Connectivity

Subsystem

12,000 9.72683 5 1233.70

DatabaseSubsystem

8,000 8.29743 4 964.15

AuthenticationSubsystem

5,000 6.90126 3 724.51

Total 40,000 35.54142 18 4335

Section 7.2.1.2: Station Server Size Estimation


Station Interface 3,000 5.64890 2 531.08

ConnectivitySubsystem

5,000 6.90126 3 724.51

Local DatabaseSubsystem

3,500 5.98607 2 584.69

Authentication

Subsystem

2,000 4.81872 1 415.05

SensorCollectionSubsystem

10,000 9.05591 4 1104.25

Total 23,500 32.41086 12 2828.5

Page 19 of 26


20/26

Section 7.2.1.3: Sensor Client Size Estimation


SensorHardware BridgeSubsystem

3,000 5.64890 2 531.08

StationConnectivitySubsystem

4,000 6.32324 2 632.59

PowerManagementSubsystem

2,000 4.81872 1 415.05

Total 9,000 16.79086 5 1578.72


Module Name Start Date Duration(Man-Months)

Management Interface April 2013 10.6159

Connectivity Subsystem May 2014 9.72683

DatabaseSubsystem

August 2013 8.29743

Authentication Subsystem January 2014 6.90126

Station Interface May 2013 5.64890

Connectivity Subsystem September 2013 6.90126

Local DatabaseSubsystem

April 2013 5.98607

Authentication Subsystem February 2014 4.81872

Sensor Collection Subsystem October 2014 9.05591

Sensor Hardware BridgeSubsystem

September 2014 5.64890

Station ConnectivitySubsystem

June 2014 6.32324

Page 20 of 26


21/26

Power ManagementSubsystem

February 2014 4.81872

Total N/A 54.7

Page 21 of 26


22/26

Section 8: Measurements

We took the following metrics:

Section 8.1: User/customer satisfaction

Section 8.1.1: How will it be used

It will be used to know whether we met the requirements that the customer presented us with.

Section 8.1.2: Why was it chosen

We chose user and customer satisfaction as a metric because it is important to design the

product in a way that pleases the customer and in a way that is usable for the user. This is one

of the most important metrics.

Section 8.2: Number of defects found during development


We will use this to measure how attentive we were to defects in the development stage and

catching them early on rather than later on.


We chose number of defects found during development because that is a good measure of

quality and whether developers are testing their code before committing.

Section 8.3: Number of defects found after a release


We will use this to measure how attentive we were to defects in the development stage and

helping us in the future so we dont have as many post release defects.


We chose number of defects found after a release because its important to keep track of this

information.

Section 8.4: Number of changes or change requests

Section 8.4.1: UsageIt will be used to see how well we stick to requirements or deviate from them.


We chose this this because its useful information

Section 8.5: Documentation completeness/accuracy

Page 22 of 26


23/26


To measure how well our documentation is written.


It is important to have good documentation. So measuring the completeness and accuracy ofour documentation is good so that your documentation is good.

Page 23 of 26


24/26

Section 9: Technical Process

We have chosen the Scrum agile process methodology because it will allow for more customer

communication throughout the development of the project. Because of the projects large size, it

would be possible to deliver the wrong product due to lack of communication. Scrum will mitigate

this risk, leading to the highest quality deliverable being produced.

We have also chosen Scrum for its ability to promote self-organization and innovation on the

project. Teams can select the work they want to complete, offering greater flexibility and

improving relations between managers and developers. Additionally, as many teams will be

working on the project, Scrum frees each team to develop a communication strategy that works

most effectively to accomplish work.

Lastly, Scrum will allow the development team to deliver only the features of highest business

value first. By preventing any unnecessary features or gold-plating of requirements, we willachieve greater efficiency in the completion of work. This will lead to delivering a fully functional

deliverable earlier than with other process methodologies.

Page 24 of 26


25/26

Section 10: Conclusion

The ERSS is a large software system that will be planned, designed, documented, implemented,

and delivered using the processes and resources outlined in this document. The Software

Development Plan for the ERSS helps to document the major decisions made and theassociated reasoning for future reference.

After looking at the provided requirements, major decisions were made to go about incorporating

the requested requirements. The ERSS as designed will support all requirements as presented.

Additionally, it will support features that make the maintenance and usability of the ERSS better.

For example, an automated backup system will be implemented and will be configurable to

assist with preserving all collected data.

Using the requirements as a basis for the system architecture, a client - server model was

decided upon. The main ERSS application resides on a central server at the preference of the

customer. The application server must have access to all the different stations that have beendeployed via some communication means.

As indicated in Section 9, the development of this system will utilize the Scrum agile

development process. The factors that went into making the decision to use Scrum involve

analysis of development time and cost. Scrum allows the customer to be highly involved with the

project and is able to see tangible results, leading to a more satisfied customer and a higher

quality process.

Finally, the software system will be accompanied by comprehensive documentation that outlines

how to use the system, how the system is structured, and documentation on how to extend the

system. The included documentation ranges from technical documents to customer orienteddocumentation such as a requirements document.

Page 25 of 26


26/26

Section 11: Glossary

Term Definition

DEC Department of Environmental Conservation

NPS National Park Service

ERSS Environment Remote Sensing System

RUP Rational Unified Process

DOI Department of the Interior

Page 26 of 26

SDPDocument (2)

Documents