SCC QSR PRP Bombsight

From SCC Wiki
Revision as of 22:17, 21 October 2018 by Dale (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Project Overview (1.)

This document shall be used as the primary source document and guide for development of the analog bombsight, which provides for the accurate placement of aerial fire-fighting grenades. Similar to a range-finder for big guns, the Bombsight makes it a comparatively easy matter to drop a grenade at almost any designated place.

Various factors are taken into account by the Bombsight, including the speed of the airship, its height above the ground, the velocity of the wind, the weight of the grenades, and other things of this sort. Certain pointers and levers along a slide rule in the cockpit of the craft are first set. When a releasing catch is pressed, the Bombsight will cause aerial grenades to be dropped just about where they are most needed.

Project Strategy (1.1)

Describe how the project will be structured and any important techniques that will be utilized. The project strategy is a top-down approach to the project.

Project Structure (1.2)

Include only critical functions in the following table.

Role / Name Date Approved
Project Sponsor / Name yyyy-mm-dd
Project Manager / Name yyyy-mm-dd
Product Manager / Name yyyy-mm-dd
Software Lead / Name yyyy-mm-dd
Hardware Lead / Name yyyy-mm-dd
Mechanical Lead /Name yyyy-mm-dd
Project Adviser / Name yyyy-mm-dd

Project Background (2.)

Provide additional background for the project and expand on financial or strategic justification.

Scope (3.)

This section is where you clearly define the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. Examples of areas that could be examined are data, processes, applications, or business areas. The following types of information can be helpful.

  • The types of deliverables that are in scope and out of scope (business requirements, current state assessment).
  • The major life-cycle processes that are in scope and out of scope (analysis, design, testing).
  • The types of data that are in scope and out of scope (financial, sales, employee).
  • The data sources (or databases) that are in scope and out of scope (billing, general ledger, payroll).
  • The organizations that are in scope and out of scope (human resources, manufacturing, vendors).
  • The major functionality that is in scope and out of scope (decision support, data entry, management reporting).

The scope of this project includes and excludes the following items:

In-Scope (3.1)

  • InScope1
  • InScope2
  • InScope3

Out-of-Scope (3.2)

  • OutofScope1
  • OutofScope2
  • OutofScope3

Project Deliverables (3.3)

All projects have deliverables. In this section, describe the deliverables of the project. Provide enough explanation and detail that the reader will be able to understand what is being produced. Make sure that the deliverables produced align with what is in scope from the previous section.

  • Deliverable1
  • Deliverable2
  • Deliverable3

Organizations Affected (3.4)

List affected organizations in order of affect to ensure the project includes all appropriate people and functional groups, and communication is directed appropriately. Specify areas or groups affected by the project or participating in it. Keep to a high level but be complete, and describe how the organization is affected or is participating. An individual should be included here only when they are not a representatives of a larger organization.

Organization Description
Organization-1 Description
Organization-2 Description
Organization-3 Description

Detailed Requirements (4.)

Requirements are statements that describe what the project is to achieve or deliver. Objectives should be SMART (Specific, Measurable, Achievable, Realistic, and Time-Based) and deliverable-based. The completion of a requirement should be evident from its description. Consider the following items, and include subsections for major categories if appropriate.

  • Product name
  • Application
  • Basic concept
    • Functions
    • Modes of operation
    • Operational parameters
    • System diagram
    • Product outline, artist rendering, etc.
    • Critical components
    • Fail-safe behavior
    • Physical protection
    • Serviceability
    • Safety
  • Regulatory compliance
  • Preliminary production plan

User Interface (4.1)

  • Screens
  • Modes of operation
  • Operation parameters

Sub-System Specification (4.2)

  • System diagram
  • Sub-System n description
  • Database integration

Data Description (4.3)

  • Input data
  • Output data
  • Stored data

Physical Characteristics (4.4)

  • Chassis drawing
    • Labeling
  • User interface
  • Connectors
  • Inputs
  • Outputs
  • Indicators
  • Connector Types
  • Size
  • Weight
  • Power Consumption
    • Battery type

Project Estimated Cost, Effort and Duration (5.)

The estimated effort hours and project costs may be depicted in many ways, including costs by team member, by deliverable, by milestone, or by category, (internal labor, external labor, travel, training, supplies, etc.). Cost is a continuum, starting with a forecast at the beginning of a project and converging to an actual realized cost by the end of the project, and the context for any values provided must be clear. Also include a brief timeline (or a set of bullets) showing the project start date, major milestones, and end date.

Estimated Cost (5.1)

Provide a summary of significant costs, including relative dates for one-time expenses. Consider non-recurring and fixed costs in addition to variable costs (such as labor). After the project is underway, report on to date actual and expected cost to complete, compared to the original estimate when the project was approved.

Estimated Effort (5.2)

Consider units of effort (e.g., person-days, man-weeks, etc.) by category of labor (e.g., software developer, system architect, pcb designer, ...). After the project is underway, report on to date actual and expected effort to complete, compared to the original estimate when the project was approved.

Milestones (5.3)

Provide a milestone summary table, which will be adequate for many projects. If the complexity of the project justifies it, include a project Gantt chart for clarity.

Milestone Date Forecast Date Completed Deliverable & Expectations
Project Launch yyyy-mm-dd yyyy-mm-dd Project Plan, Product Rqmts
Milestone yyyy-mm-dd yyyy-mm-dd ...
Milestone yyyy-mm-dd yyyy-mm-dd ...
Product Launch / Trade Show yyyy-mm-dd yyyy-mm-dd ...
Milestone yyyy-mm-dd yyyy-mm-dd ...
Production Run 1 yyyy-mm-dd yyyy-mm-dd ...
First Customer Ship yyyy-mm-dd yyyy-mm-dd ...
Project Termination yyyy-mm-dd yyyy-mm-dd ...

Project Assumptions (6.)

Project assumptions are circumstances and events that need to occur for the project to be successful but are outside the total control of the project team. They are listed as assumptions if there is a HIGH probability that they will in fact happen. The assumptions provide a historical perspective when evaluating project performance and determining justification for project-related decisions and direction.

To identify and estimate the required tasks and timing for the project, certain assumptions and premises need to be made. Based on the current knowledge today, the project assumptions are listed below. If an assumption is invalidated at a later date, the activities and estimates in the project plan will be adjusted accordingly.

In order of criticality, the major project assumptions are:

  1. Project Assumption1
  2. Project Assumption2
  3. Project Assumption3

Project Risks (7.)

Project risks are circumstances or events that exist outside of the control of the project team and will have an adverse impact on the project if they occur. (In other words, whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred.) All projects contain some risks. Risks may not be able to be eliminated entirely but can be anticipated and managed, thereby reducing the probability that they will occur.

Risks that have a high probability of occurring and have a high negative impact should be listed below. Also consider those risks that have a medium probability of occurring. For each risk listed, identify activities to perform to eliminate or mitigate the risk.

Project risks are characteristics, circumstances, or features of the project environment that may have an adverse effect on the project or the quality of its deliverables. Known risks identified with this project have been included below. A plan will be put into place to minimize or eliminate the impact of each risk to the project.

Risk Area Level (H/M/L) Risk Mitigation Plan
ProjectRisk-1 Medium Mitigating action
ProjectRisk-2 Medium Mitigating action
ProjectRisk-3 Medium Mitigating action

Related Documentation (8.)

List relevant related documentation in a table or unordered list. Related documentation provides additional background information, and is NOT part of the project requirements (if an external document is part of the requirements, it must be listed in either the Scope or Detailed requirements section).

  • Document1
  • Document2
  • Document3

Project Approvals (9.)

Add any signatures that are important for the approval of the project. Names and dates are are provided here to indicate required approvals and for convenience, approval is managed in Maestro).

Role / Name Date Approved
Project Sponsor / Name yyyy-mm-dd
Manager of project manager / Name yyyy-mm-dd
Project manager / Name yyyy-mm-dd