risk list - department of software engineering | ritsilverbullet/documents/project_plan.doc · web...

ALSTOM Signaling, Inc.Team Silver Bullet

<Project Name>Risk List

Version 1.4

Modernization of Relay Equivalent Drawing Program Version: 1.4Software Project Plan Date: 5/9/2023

Revision HistoryDate Version Description Author

12/13/2004 0.1 Initial Revision. Kristy Rozanski

12/14/2004 0.2 Added process and metrics definition. Tim Lund

Kristy Rozanski

12/15/2004 0.3 Updated from Dr. Vallino’s feedback. Tim Lund

12/17/2004 1.0 Updated roles/responsibilities.

Updated details for each iteration.

Kristy Rozanski

1/7/2005 1.1 Updated with Dr. Vallino’s ideas for Resources & Budget.

Kristy Rozanski

1/23/2005 1.2 Updated iteration release dates

Release the following SRS documents on the same day as the system release

Kristy Rozanski

2/9/2005 1.3 Changed date for next quarter from Thursdays to Wednesdays

Kristy Rozanski

3/11/2005 1.4 Updated release dates and responsibilities

Updated CAAPE definition

Kristy Rozanski

Confidential ALSTOM Signaling, Inc., 2023 of 14


Table of Contents1. Introduction 4

1.1 Purpose 41.2 Scope 41.3 Definitions, Acronyms, and Abbreviations 41.4 References 41.5 Overview 4

2. Project Organization 52.1 External Interfaces 52.2 Team Member Roles and Responsibilities 5

3. Deliverables 73.1 Deliverables with each iteration 73.2 One-time Deliverables 7

4. Project Schedule 84.1 Iteration Break-down 84.2 Major Milestones 9

5. Process Overview 105.1 Background Information 10

5.1.1 Iterative Software Process 105.1.2 Builds 105.1.3 Iteration Spans 105.1.4 Examples 10

5.2 Our Process 11

6. Tracking & Control 126.1 Metrics Goals 12

6.1.1 Ease of Collection 126.1.2 Iterative Process Corrections 126.1.3 Defect Concentration 126.1.4 Overall Tracking 12

6.2 Identified Metrics 126.2.1 Progress Metrics 126.2.2 Defect Metrics 136.2.3 Effort Metrics 136.2.4 Size Metrics 13

7. Project Resourcing 137.1 CAAPE Integration/ Shared Functionality 137.2 DXF Understanding/ Symbols Library 147.3 Placement Algorithm/ Border Implementation 147.4 Windows Printing 14

8. Budget 14



Risk List1. Introduction

1.1 PurposeThis purpose of this document is to define the project organization and schedule to be used to create a high quality project within the given time frame. This project plan is developed according to the chosen development process defined in Section 5. This document is meant to create a mutual understanding and agreement of the project plan for both ALSTOM Signaling, Inc. and the senior project development team.

1.2 ScopeThe plan defined by this document contains milestones that are to be met by both the development team and the customer, along with internal development deadlines to follow. The project organization deals with both the external interfaces regarding the project, and also the individual team member roles and responsibilities identified.

1.3 Definitions, Acronyms, and AbbreviationsAE – Application EngineerCAD – Computer Automated DesignCAAPE – Computer-Aided Application Programming Environment, a comprehensive set of development

tools for creating VPI and CenTraCode II-s applications; the system that the Relay Drawing program receives its input from.

DLL – Dynamic Linked Library DXF – Drawing Exchange Format, the standard format for the drawings to be produced by the system

(DXF files are viewable with AUTOCAD or Voloviewer – freeware).SRS – Software Requirements Specification (AKA System Requirements Document)

1.4 ReferencesPractical Software Engineering: A Case Study Approach, Maciaszek, Liong, 2005.

1.5 OverviewThis document provides a basic understanding of the development process being launched with respect to key organization and process areas, as well as gives a list of important milestones for the project. The later sections provide details about the project management effort, specifically defining the metrics that will be used by the team for tracking of the project.



2. Project Organization

2.1 External InterfacesThe following are the external contacts within ALSTOM that interface with the project. The responsibilities of each contact are detailed, relating to deployment and acceptance of the product.

Person ALSTOM Title Responsibilities

Pete HartStaff Engineer, Systems Engineering - Project Lead

- ALSTOM Senior Project Sponsor** Main point of contact for the team.

Jack Perkins Senior Engineer, Systems Engineering - Technical Lead- Requirements & Specifications contact.

Joan Mitchell

CAD Analyst, AE CAD System - Uses CAD daily.- End user of this system.- Understanding of daily nuances.

Dale Wood CAD Software Analyst, AE CAD System - Inherit the project.- C/C++ knowledge.

Joe Missler

Software Engineer, VPI CAAPE - Knowledgeable on CAAPE system.- Output from CAAPE is the input file to this system.- Knowledgeable on the CAAPE interface.

Doug Stephans

Systems Engineer, Railroad Projects - The relay drawings are used by Doug to present to the railroad customers.

Skip Danesi Systems Engineer, Transit Projects - The relay drawings are used by Skip to present to the transit customers.

2.2 Team Member Roles and ResponsibilitiesEach member of the team is assigned to be a leader/manager to some aspect of the system. In addition to the identified leadership role, each team member also has a research role to be the expert in a given technical area of the project. This is done to delegate responsibilities and mitigate for the more complex and risky areas of the system.

Person Role(s) Responsibilities

Kristy Rozanski

Team LeaderPlanning Leader

- Maintains communication with customer- Schedules meetings with customer- Maintains development schedule- Team Coordinator

LLRecon DLL Expert - Understand DLL interface that parses the input files

Tim Lund

Process/Quality LeaderRequirements Manager

- Process & Quality Assurance- Compiles/analyzes metrics weekly- Reports information regarding work load/pace - Maintains quality and consistency of documentation- Provides templates for documentation if none exist- Responsible for the requirements document

Printing Expert - Understand print preview (if possible - highest priority!)- Understand printing in Windows/ print drivers- Identify issues team must be concerned with



Dave Kerstanski

Risk Management LeaderRequirements Analyst

- Manages identified risks- Reports to team if new plan of action needs to be taken- Maintains a traceability matrix to ensure requirements are covered in the design, implementation and test

DXF Expert - Find possible DXF toolkits/libraries- Find a viewing tool for testing- Understand format & associated algorithms- Understand input of DXF symbols

Jessica Linendoll

Development Leader - System architect- Responsible for ensuring a clear & consistent design- Delegation of development assignments

Placement Algorithm ExpertCAAPE System Expert

- Research placement algorithm improvements- Reduction of whitespace and performance issues- Communicate with ALSTOM to understand CAAPE- Address reusability needs- Address possible integration interfaces

Dan Lovette

Website ManagerConfiguration ManagementTesting Leader

- Maintains project website, keeping artifacts up-to-date- Provides solutions for development environment (tools, software, etc.)- Integration of complete system- Responsible for test plan & testing tasks

DXF Expert - Find possible DXF toolkits/libraries- Find a viewing tool for testing- Understand format & associated algorithms- Understand input of DXF symbols



3. DeliverablesThe following is the list of artifacts requested by the customer:

Project Plan (this document) Software Requirements Specification (SRS) Detailed Design Document Test Plan System Source Code Executable file(s) On-line Help Functions User Manuals

3.1 Deliverables with each iterationThe following items will be considered deliverable with each iteration of the process.

Software Requirements SpecificationThe requirements for the system shall be developed in conjunction with the iterative process and considered a key deliverable with each iteration. Specifically, the requirements shall be developed in a manner such that higher level requirements appear in earlier iterations, and more detailed subsections of those requirements are presented in later iterations.

Detailed Design DocumentThis document will define the design of the system overall and give insights to key detailed design decisions.

Test PlanA test plan will be evolved and used throughout the process. It should be developed in parallel with the requirements document in order to clarify system behavior. All input file(s) to test cases will be a part of this deliverable.

System Source Code/ Executable file(s)In order to generate customer feedback, the system shall be delivered at the end of each iteration for review.

Defect ReportWith each iteration, a defect report will be generated and delivered to show which parts of the system had issues with defects and so that outsiders can objectively evaluate the team’s performance.

3.2 One-time DeliverablesThe following documents will be considered one-time deliverables, rather than iteratively evolving documents:

Project Plan On-line Help functions User Manuals



4. Project ScheduleRefer to the Microsoft Project Gantt Chart which details the schedule for the project. The project commenced on December 2, 2004, and will end on or before May 20, 2005. The schedule is derived based on our iterative development process described in the following section, Process Overview.

4.1 Iteration Break-downThe following specifies what can be expected with each iteration.

Iteration 1:- Basic functionality to process input and generate output (DXF files)- High-level architecture design- Understanding of existing system/ functionality, incorporate into new architecture- Use of existing algorithms

Iteration 2:- Enhance more detail into the system design- Tackle areas identified as RISKY:

Printing DXF intricacies Placement algorithm CAAPE interface

- Improve the existing algorithms

Iteration 3:- Reflection on process & project plan- Redesign/ Refactor the system- Implementation of major feature set (specified in the Vision & Scope document)- Draft of User Manuals- Help Features

Iteration 4:- Final touches & improvements on the system- Clean-up of design and system documentation



4.2 Major MilestonesThe following summarizes the dates associated with the milestones identified for the project.Note: Milestones in Microsoft Project are denoted by a black diamond on the Gantt Chart.

Inception:Friday, December 10, 2004 – Launch project website (www.se.rit.edu/~silverbullet)Friday, December 10, 2004 – Submit project synopsis to SE DepartmentFriday, December 17, 2004 – Final draft of project inception documents:

Vision & Scope, Project Plan (including development process), and Risk List

Iteration 1:Week of January 3, 2005 – Specification of input, DLL interface to parsing module (Joe Missler)Week of January 3, 2005 – Specification of DXF format description (Dale Wood)Week of January 3, 2005 – Test plans (or test cases) from current system (Dale Wood/ Pete Hart)Friday, January 7, 2005 – Requirements v0.1 for review Thursday, January 13, 2005 – Validation/ Review of Requirements v0.1 (ALSTOM team)Friday, January 21, 2005 – Release of beta system v0.1 for acceptance testsWeek of January 24, 2005 – CAAPE development guide/ interface definition (Joe Missler)Thursday, January 27, 2005 – Review of System v0.1 (ALSTOM team)

Iteration 2:Monday, January 24, 2005 – Requirements v0.2 for reviewThursday, January 27, 2005 – Validation/ Review of Requirements v0.2 (ALSTOM team)Monday, February 14, 2005 – Release of beta system v0.2 for acceptance testsThursday, February 17, 2005 – Review of System v0.2 (ALSTOM team)

Mid-Project Wrap-Up:Week of February 21, 2005 – Present to ALSTOM Executive Committee

Iteration 3:Friday, February 25, 2005 – Requirements v0.3 for reviewWednesday, March 16, 2005 – Validation/ Review of Requirements v0.3 (ALSTOM team)Monday, April 18, 2005 – Release of beta system v0.3 for acceptance testsWednesday, April 20, 2005 – Review of System v0.3 (ALSTOM team)

Iteration 4:Monday, April 18, 2005 – Requirements v1.0 for reviewWednesday, April 20, 2005 – Validation/ Review of Requirements v1.0 (ALSTOM team)Monday, May 9, 2005 – Release of system v1.0 for acceptance testsWednesday, May 11, 2005 – Review of System v1.0 (ALSTOM team)

Deployment:Wednesday, April 20, 2005 – Submit Project PosterFriday, May 6, 2005 – Submit Conference PaperFriday, May 13, 2005 – Final release of project deliverablesWeek of May 16, 2005 – Present to ALSTOM Executive Committee


http://www.se.rit.edu/~silverbullet


5. Process Overview

5.1 Background Information

5.1.1 Iterative Software ProcessAn iterative software process is the repetition of another basic development process with an objective to enrich the software product. The waterfall model contains the basic development steps of requirements specification, design, implementation, testing, and maintenance, but is only slightly iterative because of overlaps between phases of development, but cannot be considered iterative because iteration means movement from one version of the product to the next. Hence, the goal of an iterative process is to take these basic software process steps and repeat them in a manner makes software development more effective and thorough.

5.1.2 BuildsAn iterative process assumes builds – executable code that is a deliverable of an iteration. The scope of a build is the whole system, but without full functionality, fully developed user interfaces, and other detailed aspects of the system in earlier builds. A build is something that can be demonstrated to the end user as a version of the system on its way to the final product.

5.1.3 Iteration SpansAn iterative process assumes short intervals between builds, in weeks or days, not months. This allows for the best possible use of metrics and project management, as well as a more active plan to mitigate risk. However, this amount of process overhead may be overwhelming for a small project, particularly if the developers are not familiar with the process.

5.1.4 ExamplesThe classic example is the Spiral Model (Boehm, 1988). Other examples are the IBM Rational Unified Process (originating from the Rational Unified Process), Model Driven Architecture (Kleppe, 2003), and the agile development process.



5.2 Our ProcessOur process features a full iteration through requirements, design, implementation, and testing for each cycle. This will allow the user to begin acceptance testing from the initial release to provide feedback throughout the following iteration. In addition, the requirements will be specified in greater detail with each iteration, such that each product version has a corresponding requirements version to be tested against. This is ensured by releasing the requirements to the customer, as was desired.

In addition to the requirements document, all other iterative documents will be considered evolutionary in nature, with versions specific to a release of the product. For example, the Test Plan would evolve with each iteration, with additional content for each release. These documents are fully outlined in Section 3.

Note that one of the primary advantages of this process is that it allows the customer to generate feedback from very early in development. As of the completion of the first iteration, the customer has a working system to evaluate. However, it is also crucial that the customer understand that this initial system is not intended to be fully functional, nor is it intended to match complete specifications of the final system.

For our process, we have decided to initially plan four iterations. These iterations will be logically divided and documented in the project plan.



6. Tracking & ControlThe progress of the project must be monitored. Tracking and control are done by collecting metrics. The best way to determine what metrics to use is to first declare the tracking and control goals, and then determine the best set of metrics to meet those goals.

6.1 Metrics Goals

6.1.1 Ease of CollectionDue to the nature, size, and time constraint of this project, proportional effort should be put into metrics collection. If too much effort is put into tracking a small project, the project becomes bloated and overly bureaucratic.

6.1.2 Iterative Process CorrectionsOne of the advantages of an iterative process is that it can be slightly adjusted during development if there are apparent problems. Therefore, it is desirable to track the project in a way such that the origin of any defects in the system can be determined. It is also desirable to correlate effort to effectiveness – that is, if the process becomes ineffective in a certain area, the metrics should reflect that so an adjustment can be made before development is completed.

6.1.3 Defect ConcentrationIf the process proceeds in a manner that consistently injects defects in a certain manner the metrics should reflect that so a correction can be made.

6.1.4 Overall TrackingAs is the goal with most project metrics, tracking and control need to be facilitated. Specifically to determine a reasonable balance of workload and responsibility, as well as proof of good Software Engineering practices in a post-mortem situation.

6.2 Identified MetricsThis section identifies metrics and a table depicting which of the defined goal/criteria each metric meets.

Metric CategoryEase of

CollectionIterative Process

Corrections

Defect Concentration

Overall Tracking

Progress Metrics (Work Breakdown)

X X X

Defect Metrics X X XEffort Metrics X X

Size Metrics X X

6.2.1 Progress MetricsGoal: Provide a quick overview of progress toward project completion.Units: Points system ranked by team before project and adjusted if needed.Collection: Earned value based on work breakdown, marked off as completed.Rationale: Simple progress metrics will enable the team to instantly have a rough idea of where they are in the overall development process. Additionally, the team is setting up a detailed project plan, which is the first key to collecting these metrics.



6.2.2 Defect MetricsGoal: Show defect density of software and potential flaws in process that may inject defects.Units: Defects rated by severity, phase injected, phase detected.Collection: Preferably a web application, but a spreadsheet may also be acceptable.Rationale: Collection of these metrics should show whether a certain point in the team’s process is flawed, i.e. if many defects are injected during requirements, perhaps the team needs to re-evaluate its requirements phase.

6.2.3 Effort MetricsGoal: Track each team member’s effort according to time, phase, and activity.Units: Activity, hours spent on activity, phase activity is part of.Collection: Individual spreadsheets compiled weekly.Rationale: These metrics are part of the PSP (Personal Software Process) and give a measure of how the developers are spending their time. They will provide an overview of total team effort for each given phase and combine with the defect metrics to give an idea of any irregularities or defects in the process.

6.2.4 Size MetricsGoal: Track the size of the project from week to week and between deliverablesUnits: Lines of codeCollection: Use of an automated toolRationale: These metrics can be easily automated and provide an approximation of the size of the project at any given time. While other size estimations may be considered superior, this metric is by far much easier to collect.

7. Project ResourcingThe RIT team is comprised of the necessary staff of Software Engineers; however, there are special skills or experience needed specifically for this project for it to be developed with the necessary level of quality.

This will require a form of training, or self-teaching, for the team members. The following details the skills needed by iteration, the person responsible, and target dates indicating when the training should be completed.

Note: Refer to the Risk List document for a complete overview of identified risks and skills needed. The following details those areas that need special research and training.

7.1 CAAPE Integration/ Shared FunctionalityThe domain knowledge relating to the CAAPE system is unknown. The team members will need to make two major decisions involving CAAPE:

1. Integrate Relay Drawing Program within CAAPE, or just provide a DLL. 2. Determine functionality that can be shared between CAAPE and the Relay Drawing Program.

CAAPE Expert: Jessica Linendoll

START: Monday, January 10 – Self-teaching should begin during iteration 1. While domain knowledge is understood for the Relay Drawing Program, better possibilities can be understood with CAAPE. Training starts concurrently with implementation.

COMPLETION: Wednesday, January 26 – Iteration 2 requires design decisions to be made regarding the CAAPE system. The training should be completed at least the day before design for iteration 2 begins.



7.2 DXF Understanding/ Symbols LibraryDXF files should be fully understood, as it is a major component to the entire system. DXF files need to be written, and DXF symbols need to be read to create the drawings.

DXF Experts: Dave Kerstanski and Dan Lovette

START: Saturday, December 18 – Self-teaching should begin as soon as possible. Research should begin during RIT’s Christmas Break to allow for appropriate knowledge to begin iteration 1.

COMPLETION: Wednesday, January 26 – Iteration 2 requires a focus on the intricacies surrounding DXF functions. Training should be complete to make the proper design decisions for iteration 2’s functionality.

7.3 Placement Algorithm/ Border ImplementationThere is a need to fully understand the placement algorithm and border implementation for the drawings. There are regulations surrounding this, and there are imperfections in the current system. Improvement is expected.

Placement Algorithm Expert: Kristy Rozanski

START: Saturday, December 18 – Self-teaching should begin as soon as possible. Design decisions for iteration 1 require knowledge in this area.

COMPLETION: Wednesday, January 26 – Iteration 2 requires improvements to be made to the algorithms. Training should be complete to make the proper design decisions for iteration 2’s functionality.

7.4 Windows PrintingA new feature for the Relay Drawing Program, which may or may not present roadblocks, is Windows printing. There are many intricacies and details surrounding this feature may affect implementation and design of the system.

Printing Expert: Tim Lund

START: Saturday, December 18 – Self-teaching should begin as soon as possible, since printing is a new area and a major feature to the system. Iteration 1 may contain a basic prototype for this feature.

COMPLETION: Wednesday, January 26 – Iteration 2 requires such a major area to be ‘tackled’. Training should be complete to make the proper design decisions for iteration 2’s printing functionality.

8. BudgetThe size of the budget is very minimal, if not negligent. A budget it may only become apparent in the need for some commercial tools for development.

Currently, RIT has licenses for Visual Studio 2003 .NET, CVS tools, etc. For testing purposes, a DXF viewer will be needed to verify the output. If an open source DXF viewer does not meet the development needs, there is a possibility that some commercial tool may need to be purchased.

Purchasing of commercial tools shall be monitored and approved by ALSTOM. A tool for purchase should only be brought to ALSTOM for approval if:

1. The tool will be a one time purchase.2. The tool does not carry any distribution licenses on programs generated with it.


risk list - department of software engineering | ritsilverbullet/documents/project_plan.doc · web...

Documents