Professional Documents
Culture Documents
Version 1.0
1/29/04
Kiran Gandu
The purpose of this document is to specify the project plan to develop the Major Field
Achievement Test (MFAT) grading system. The primary audience is the project advisor,
Dr Dennis S. Martin, and other members of the studio committee, Dr Chi-Chin Chao and
Dr Jan Case. This document outlines a brief plan about how the project is to be shaped
and also includes the milestones and deliverables. The SPMP document will serve as a
guide for the student, developing the product as part of the project. Updates of this
iii
Table of Contents
Change History.................................................................................................................................................ii
Preface.............................................................................................................................................................iii
Table of Contents.............................................................................................................................................iv
List of Figures...................................................................................................................................................v
1.0. Overview....................................................................................................................................................1
Project Summary..........................................................................................................................................1
Scope, Purpose and Objectives.................................................................................................................1
Assumptions and Constraints...................................................................................................................3
Project Deliverables..................................................................................................................................3
Schedule and Budget Summary................................................................................................................4
Evolution of the Plan...................................................................................................................................4
References.........................................................................................................................................................6
Glossary............................................................................................................................................................7
Project Organization.........................................................................................................................................7
External Interfaces........................................................................................................................................7
Internal Interfaces.........................................................................................................................................8
Roles and Responsibilities............................................................................................................................8
Managerial Process Plans.................................................................................................................................9
Work Plan.....................................................................................................................................................9
Work Activities.........................................................................................................................................9
Schedule Allocation..................................................................................................................................9
Resource Allocation................................................................................................................................10
Budget Allocation...................................................................................................................................10
Control Plan................................................................................................................................................10
Requirements Control Plan.....................................................................................................................10
Schedule Control Plan............................................................................................................................10
Budget Control Plan...............................................................................................................................10
Quality Control Plan...............................................................................................................................10
Reporting Plan........................................................................................................................................11
Metrics Collection Plan..........................................................................................................................11
Risk Management Plan...............................................................................................................................11
Closeout Plan..............................................................................................................................................12
Technical Process...........................................................................................................................................13
Process Model.............................................................................................................................................13
Methods, Tools, and Techniques................................................................................................................13
Infrastructure Plan......................................................................................................................................13
Product Acceptance Plan............................................................................................................................13
Support Process Plans.....................................................................................................................................14
Configuration Management Plan................................................................................................................14
Validation & Verification Plan...................................................................................................................14
Documentation Plan....................................................................................................................................14
Quality Assurance Plan...............................................................................................................................15
Review and Audits .....................................................................................................................................15
Problem Resolution Plan............................................................................................................................15
Subcontractor Management Plan................................................................................................................15
Process Improvement Plan.........................................................................................................................15
iv
List of Figures
1. Figure.1 Schedule
2. Figure 2. Gantt Chart
v
1.0. Overview
Project Summary
The CMMI is a model for improving and appraising the performance of development
developed by the Software Engineering Institute in Pittsburgh, PA. The CMMI is best
known for its five levels of organizational maturity namely initial, managed process,
defined process, and quantitatively managed process and optimizing process. Each level
assess its performance against certain parameters and use this information for process
organizations.
For Computer Science there is a nationally nor med test developed by the Educational
Testing Service, which will provide comparative national results. Dr. Martin had
suggested that the Computer Information Systems (CIS) program at Jacksonville State
University needs something similar to this. The test would have to be based on multiple-
choice type questions and cover the entire course curriculum. It would have subparts
covering the main areas of CIS to allow for more specific evaluation of the curriculum.
The department also feels the need for a locally written test in Computer Science that has
a similar sub area structure. The objective of the new system will be to provide an
efficient way to grade and report results for the MCIS MFAT.
This project proposes a system for use on a Personal Computer using a Visual Interface
and the Microsoft Access database management system. Major functions that will be
provided by the system include: logging into the system, importing answer keys and
student test answers, grading tests, generating a report of test results and printing reports
upon demand.
The MCIS department will use the Major Field Achievement Test to gauge the overall
performance of its students in the computer field. This project will deliver a working
system that provides results of such tests not only for evaluating the student but also for
A project like this is an excellent opportunity for the author to have a real world
experience while testing and implementing the knowledge that was gained during the
It would be worthwhile to use the experience that the author had gained experience
working on databases. The MCIS Department can assess its performance and use this
information for its process improvement as one of the steps necessary for accreditation of
the program.
Assumptions and Constraints
The author of this document is expected to complete the project within two semesters.
This project will use resources in the form of time and effort that will be spent developing
the project deliverables and under the guidance of Dr. Martin, who kindly agreed to be
My advisor has said that a databank of questions would be made available, as a baseline
database for the MFAT implementation for CIS, and simulated student response data will
be provided for the project. Of course, this databank can be modified and updated at any
Project Deliverables
Refer to section 1.1.4 for the expected delivery dates of the project deliverables.
Schedule and Budget Summary
Figure 1: Schedule
Validation Plan
Studio I Presentation April 15, 2004
Updated SPMP September 20, 2004
Database October 08, 2004
Software Testing Description October 28, 2004
System Integration November 16, 2004
Final Studio Paper November 25, 2004
Studio II Presentation December 2, 2004
The preliminary drafts of the SPMP will be submitted to my advisor and after approval,
copies of the same will be distributed to the members of the committee on the date as
referred to in section 1.1.4, figure 1. For configuration management, refer to section 7.1,
1. Braude, Eric J., Software Engineering: An Object Oriented Perspective. Wiley, 2001.
http://www.wiley.com/college/braude.
5. Martin, Dr. Dennis S., Documentation Standards. Jacksonville State University, 2003:
http://mcis.jsu.edu/faculty/dmartin/cs521.html
Term Description
CIS Computer Information Systems program within the MCIS Dept
CMMI Capability Maturity Model Integration
CS Computer Science program within the MCIS Dept
ETS Educational Testing Services
Mathematics Also a program within the MCIS Dept
MCIS Mathematical, Computing and Information Sciences Department
MFAT Major Field Achievement Test
RDBMS Relational Database Management System.
SCMP Software Configuration Management Plan
SDD Software Design Document
SQAP Software Quality Assurance Plan
SRS Software Requirement Specification.
Stakeholder A person, group or organization with a stake in the outcome of an
Project Organization
External Interfaces
The external interfaces for the project would be the members of the studio committee and
Mrs. Judy Anderson, Secretary, Department of MCIS who is the stakeholder for this
project.
Internal Interfaces
None.
The software developer is responsible for all documentation to be developed and for all
work to be done.
Managerial Process Plans
Work Plan
Work Activities
Schedule Allocation
Figure 2: Gantt chart
Date Ending
Activity % Complete Status 1/29 2/27 3/18 10/08 10/28 11/16
User Analysis 0 S SSSSS
Full Specification 0 S SSSSSSSS
Architectural 0 S SSSSSSSS
Design
Detailed Design 0 S SSSSSSSS
Database 0 S SSSSSSS
Test Design 0 S SSSSSSS
Implementation 0 S SSSSSSSSS
Module Testing 0 S SSSSSSSSSSSSS
Integration Testing 0 S SSSSSSSSSSSSS
S Schedule
A Satisfactory
C Caution
F Critical
This project will use resources in the form of time and effort that I shall spend developing
Budget Allocation
None.
Control Plan
When changes are to be made in the requirements after the SRS has been released, the
changes shall be brought to the attention of the committee and discussed. Any changes
that are to be made will be with the prior approval of the committee and only if feasible
and permissible within the constraints of the project mentioned in section 1.1.2, and
resources in terms of knowledge and skill of the developer required. Once the changes
have been made to the SRS document, an updated version of the SRS shall be released
and circulated to the committee. However, no changes shall be made to the requirements
If the work scheduled in section 1.1.4 is gets behind, the developer is ready to spend extra
time on the project in between and after the schedules and also during Summer 2004 to
make up for the lost time and deliver the final project on time.
None.
The updated SPMP will be circulated as mentioned in schedule of section 1.1.4. Each of
preliminary versions of all the documents and updates and status reports will be sent and
discussed with the advisor and upon approval the approved document will be circulated
to the other members of the committee. The report on the status of the project will be sent
to the members of the committee at the beginning of the second semester of Studio.
None.
Risk # 1 “Deficiency in the knowledge and understanding of the problem and its
solution” indicates that the developer does not have the complete understanding of the
problem. This will affect the quality of the project in terms of requirements of the product
and their fulfillment, which is not desirable. Building a prototype for the project model
and doing an extensive literature search can overcome this. This will help the developer
Risk # 2 “Lack of Skills and knowledge of tools needed for statistical analysis”, which
means that the developer does not have knowledge about the tools and knowledge of
working on statistical analysis. In this case, the developer is expected to update his / her
knowledge of tools available for this purpose and decide the one that will be used in the
project and master it. The developer may consult the faculty and other members of the
All the details about the post-mortem debriefings, report on the lessons learnt, project
objectives and the milestones achieved would be mentioned as part of the final studio
paper at the end of the first semester of the studio component. At the end of the second
semester of studio the developer will provide the committee with electronic version of the
project code and documentation for future reference and maintenance purposes.
Technical Process
Process Model
The MFAT grading system for MCIS will be implemented and executed using the
Refer to section 6.1 (process model) for a description of the process. This process is
project adapts the system for use on a Personal Computer using a Visual Interface that
would be built using Visual basic 6.0 and HTML, and Microsoft Access as its database
management system. The tool for the statistical analysis is undecided at this point of time
Infrastructure Plan
The hardware resources are two 333MHz Pentium computers running Windows 95 / 98 /
2000 Operating System. Each of these computers should have at least 128 MB RAM and
The committee will test the final product / application for acceptance.
Support Process Plans
configuration item as well as its file would be named after the document like SRS, SDD
and followed by the version number. For example, all the preliminary versions that are
submitted to the advisor for review would be named with the abbreviation followed by
0.1, 0.2. After the advisor approves the basic SPMP, this baseline document will be
version 1.0 and is distributed to the committee members and stakeholders. Informal
updates with the advisor will be numbered with 1.1, 1.2, etc. and the next full distribution
A Verification and Validation Plan as a part of the Software Quality Assurance and
Documentation Plan
The IEEE standards would be followed for all documentation purposes. All the
documents would be discussed and reviewed with advisor before their baseline versions
are issued and distributed to the members of the committee on the due dates mentioned in
Review and Audits would be addressed as a part of the Software Quality Assurance and
None, problems would be resolved informally between the developer, the advisor and the
studio committee.
None.
None, this is a single software development experience and the lessons learned will be
Application 1, 2, 10
CI 5, 6, 10
Client 1, 10
CRM 1, 10
IEEE 2, 10
IT 1, 10
SCMP 5, 6, 10
SDD 5, 10
SPMP 5, 6, 10
SQAP 5, 6, 10
SRS 5, 6, 10
Stakeholder / Customer 1, 3, 5, 10
STD 5, 6, 10
Tbd 10