Welcome
Project Description
Software Development Plan
Gantt Schedule
Specifications Document
Project Proposal
Design Document
Client Email
Teleconference Minutes
Status Reports
Team Meeting Minutes
Client Meeting Minutes
Team Pictures

Software Development Plan

 

 

 

TEAM LIVERMORE

Software Development Plan

EGR 486 – CSE: Senior Capstone Design

Nathan F. Crary

Aasif Z. Syed

Amy J. Whitaker

Date of last revision: Sept. 23 1997

Revision number: 1.1.nfc

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Scope of the plan

The purpose of the software development plan is to document the software process and related activities. This plan formalizes the methods for managing the project, tracking requirements, testing requirements, and status reporting. It also gives a description of the design ideology employed by the group in order to tackle the problem at hand.

 

  1. Organization, responsibilities, and authorities

    2. At each team meeting, any future reports or memos will be reviewed. We will make sure that someone in the team is specifically responsible for this deadline. Each task will be broken up among the team members or will be assigned to one individual.

    The team leader is responsible for placing major deadlines in the team timeline. All deadlines will have at least one team member as the senior member responsible for meeting the milestone deadline.

    Elected positions are:

    Amy J. Whitaker - Team Leader

    Aasif Z. Syed - Team Recorder

    Nathan F. Crary - Team Liaison

     

  2. Schedule

See Gantt Schedule

 

4. Risk areas

Before each meeting a list is made of any concerns we feel are necessary to discuss. In this forum, we can analyze any risks and try to prepare further by formulating plans to handle the situation should the need arise. Current risk areas:

  • Contact responding in a Timely fashion to questions
  • Getting the Standard Template Library from LLNL and installing it
  • X-windows learning curve
  1. Requirements

5.1 Capture of primary requirements

We will create a document that will contain ALL requirements. Each requirement will have the following categories to help us organize and keep track of them.
    • UNIQUE IDENTIFIER
    • SHORT DESCRIPTION OR TITLE
    • LONG DESCRIPTION
    • AREA TRACED FROM

We are also planning to visit the client to better understand these requirements.

Any new requirements by the client will be discussed with him at the weekly meeting. Client added requirements are considered primary requirements.

Any new requirements by the team will be conveyed, through the liaison to the client, in advanced of the weekly meeting to give the client time to consider the new requirement. At the weekly meeting we will discuss the proposed addition and seek the client’s approval to enter it into the Requirements Document. Team added requirements are considered derived requirements.

 

 

 

5.2 Derived requirements

A derived requirement is traced from the primary requirements and/or research conducted by the team. Derived requirements will be linked to primary requirements in the AREA TRACED FROM section.

5.3 Tracking requirements to architecture

While developing the object model, the team will continuously refer to the requirement capture document. This will assure that all requirements will be met in the object model.

5.4 Tracking requirements to design

Requirement tracking to the design will be done by making charts and evaluating the software with requirements. References to primary requirement will frequently be made in order to map them to the design.

5.5 Tracking requirements to implementation code

Requirements will be tracked in the implementation code by using test inputs that represent each requirement.

5.6 Test for requirement coverage

By reviewing the requirements and applying the test inputs, all requirements will be successfully covered.

6. Delivery of architecture and design documentation

The specification and design documentation consists of the object model, final requirement document, the design document, and the test plan.

 

7. Software development process

The software development process decided by the team will follow the Spiral Model. Individual stages are

    1. Customer communication
    2. Planning
    3. Risk analysis
    4. Engineering
    5. Construction & release
    6. Customer evaluation

If the project is not finished we return to the top of the list and repeat the steps.

 

8. Software configuration management plan

The management plan will follow the controlled decentralized plan. This means that we have a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks. Problem solving remains a group activity with the leader partitioning the problem among subgroups to be solved. To capture any changes that are made to the project code we will use SCC, a tool that keeps track of code changes in the form of copying the original code and increasing the new code’s version. The previous copies are hidden to the programmer until the need arises to return to a previous version and SCC is used to retrieve them.

Additionally we will include at the top of each code file a commented section which will list who made the most recent changes, a paragraph about what those changes were, and the date they were made. This will allow us to quickly understand what the codes current condition is and as well as who made the changes and when they were made.

 

9. Test plan and achieving test independence

The test plan consists of a set of input cases that test individual components of the program or the program as a whole for correct response. A good test case is one that has a high probability of finding an as-yet undiscovered error.

We have reviewed the following different testing methods: White box, Black box, loops, and Data flow. Because our program deals with performing the same operation possibly thousands of times we have chosen Black box as our method of testing to assure accurate code. The utilization of Black box testing will allow us to test the concepts and logic of the code rather than following all possible paths.

10. Tools and environment

The project will run in the Unix environment. The code will be implemented in C++ and the X-window library will be used. A "polygonal terrain representation" data file will be used to test the code written. Additional tools include: C++ compiler, C++ debugger, MS Word, MS Project, MS Excel, MS PowerPoint, Windows OS, and Software through Pictures.

  1. Keeping client up to date

The client liaison will send the client a weekly Project Status Report. Additionally, weekly teleconferences are conducted to allow the client to join in team discussions and answer any questions we might have for the client. Finally, the liaison will contact the client by either sending email or calling via phone to discuss any additional concerns by the team members or the client.