Software Project Management PlanVersion 1.0

1/29/04

Major Field Achievement Test Grading System

Kiran Gandu

Submitted in partial fulfillmentOf the requirements ofMasters Studio Project

Jacksonville State University

Change History

Major Field Achievement Test

SPMP Version 1.0 Release date: 1/29/04 Baseline Version

Preface

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

document will serve to record the progress of the project.

iii

Table of Contents

Change History.................................................................................................................................................iiPreface.............................................................................................................................................................iiiTable of Contents............................................................................................................................................ivList of Figures...................................................................................................................................................v1.0. Overview...................................................................................................................................................1

1.1. Project Summary..............................................................................................................................11.1.1. Scope, Purpose and Objectives.................................................................................................11.1.2. Assumptions and Constraints...................................................................................................31.1.3. Project Deliverables..................................................................................................................31.1.4. Schedule and Budget Summary................................................................................................4

1.2. Evolution of the Plan........................................................................................................................52.0. References............................................................................................................................................63.0. Glossary................................................................................................................................................74.0. Project Organization.............................................................................................................................8

4.1. External Interfaces............................................................................................................................84.2. Internal Interfaces.............................................................................................................................84.3. Roles and Responsibilities................................................................................................................8

5.0 Managerial Process Plans.....................................................................................................................95.1. Work Plan.........................................................................................................................................9

5.1.1. Work Activities........................................................................................................................95.1.2. Schedule Allocation..................................................................................................................95.1.3. Resource Allocation...............................................................................................................105.1.4. Budget Allocation...................................................................................................................10

5.2. Control Plan....................................................................................................................................105.2.1. Requirements Control Plan.....................................................................................................105.2.2. Schedule Control Plan............................................................................................................105.2.3. Budget Control Plan...............................................................................................................105.2.4. Quality Control Plan...............................................................................................................105.2.5. Reporting Plan........................................................................................................................115.2.6. Metrics Collection Plan..........................................................................................................11

5.3. Risk Management Plan...................................................................................................................115.4. Closeout Plan..................................................................................................................................12

6.0 Technical Process...............................................................................................................................136.1. Process Model................................................................................................................................136.2. Methods, Tools, and Techniques....................................................................................................136.3. Infrastructure Plan..........................................................................................................................136.4. Product Acceptance Plan................................................................................................................13

7.0 Support Process Plans.........................................................................................................................147.1. Configuration Management Plan....................................................................................................147.2. Validation & Verification Plan.......................................................................................................147.3. Documentation Plan.......................................................................................................................147.4. Quality Assurance Plan..................................................................................................................157.5. Review and Audits.........................................................................................................................157.6. Problem Resolution Plan................................................................................................................157.7. Subcontractor Management Plan....................................................................................................157.8. Process Improvement Plan.............................................................................................................15

iv

List of Figures

1. Figure.1 Schedule2. Figure 2. Gantt Chart

v

1.0. Overview

1.1.Project Summary

1.1.1. Scope, Purpose and Objectives

The CMMI is a model for improving and appraising the performance of development

organizations. It stands for “Capability Maturity Model Integration”. It is published and

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

represents a coherent set of best practices organizations are expected to implement as

they become better at what they do.

CMMI methodology at Level 5 (optimizing process) of requires that an organization

assess its performance against certain parameters and use this information for process

improvement. This applies to university programs as well as to the software development

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

1

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

using such information by the department for its improvement.

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

Masters program and especially undergoing the Software Engineering courses.

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.

2

1.1.2. 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

the advisor and a guide for this project.

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

point of time in the future by the faculty or the department.

1.1.3. Project Deliverables

The list of project deliverables is:

Project Management Plan

Software Requirements Specification

Software Design Description

Software Quality Assurance Plan (including the Software Verification and

Validation Plan and the Test Design Document)

Working System with an Access Database

Final Studio Document

Refer to section 1.1.4 for the expected delivery dates of the project deliverables.

3

1.1.4. Schedule and Budget Summary

Budget Summary: “No budget required”.

A tentative schedule is as shown below in table 1.

Figure 1: Schedule

Item Due date

Software Project Management Plan (this document) January 29, 2004

Software Requirements Specifications February 27, 2004

Software Design Document March 18, 2004

Software Quality Assurance and Verification &

Validation Plan

April 05, 2004

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

4

1.2. Evolution of the Plan

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,

configuration management plan.

5

2.0. References

1. Braude, Eric J., Software Engineering: An Object Oriented Perspective. Wiley, 2001.

2. Case Study: SPMP for Encounter video game ref:

http://www.wiley.com/college/braude.

3. IEEE Document Standards published in “IEEE Standards Collection”. 2001 edition.

4. Major field test administered by the ETS: http://www.ets.org/hea/mft/index.html

5. Martin, Dr. Dennis S., Documentation Standards. Jacksonville State University, 2003:

http://mcis.jsu.edu/faculty/dmartin/cs521.html

6. Pressman, Roger S., Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2001.

6

3.0. Glossary

Term DescriptionCIS 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

application that is being developed.

TDB / tbd To be decided

7

4.0. Project Organization

4.1. 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.

4.2. Internal Interfaces

None.

4.3. Roles and Responsibilities

The software developer is responsible for all documentation to be developed and for all

work to be done.

8

5.0 Managerial Process Plans

5.1. Work Plan

5.1.1. Work Activities

Refer to section 5.1.2 Gantt chart.

5.1.2. Schedule Allocation

Figure 2: Gantt chart

MFAT Grading System Project ScheduleKiran: Project Developer

Status date: January 8th, 2004Due Date: December 2nd, 2004

Date EndingActivity % Complete Status 1/29 2/27 3/18 10/08 10/28 11/16

User Analysis 0 S SSSSSFull Specification 0 S SSSSSSSSArchitectural 0 S SSSSSSSS DesignDetailed Design 0 S SSSSSSSS Database 0 S SSSSSSSTest Design 0 S SSSSSSSImplementation 0 S SSSSSSSSSModule Testing 0 S SSSSSSSSSSSSSIntegration Testing 0 S SSSSSSSSSSSSS

Project Status Symbols

S ScheduleA SatisfactoryC CautionF Critical

Planning / Progress Symbols

B Work before Schedule TimeS Scheduled Activity TimeA Work after Scheduled TimeX Scheduled But Not Worked

9

5.1.3. Resource Allocation

This project will use resources in the form of time and effort that I shall spend developing

the project deliverables as mentioned in section 1.1.3.

5.1.4. Budget Allocation

None.

5.2. Control Plan

5.2.1. Requirements 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

once the SDD is completed.

5.2.2. Schedule Control Plan

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.

5.2.3. Budget Control Plan

None.

5.2.4. Quality Control Plan

10

Please refer to Software Quality Assurance Plan regarding Quality Control.

5.2.5. Reporting Plan

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.

5.2.6. Metrics Collection Plan

None.

5.3. Risk Management Plan

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

in delivering an efficient and quality product.

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

11

project and master it. The developer may consult the faculty and other members of the

committee especially, Dr. Jane Case for this purpose.

5.4. Closeout Plan

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.

12

6.0 Technical Process

6.1. Process Model

The MFAT grading system for MCIS will be implemented and executed using the

Waterfall Model and prototyping.

6.2. Methods, Tools, and Techniques

Refer to section 6.1 (process model) for a description of the process. This process is

described in [Braude] Software Engineering: An Object Oriented Perspective. This

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

and would be mentioned in the updated version of this document.

6.3. 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

a minimum of 4 GB of disk space.

6.4. Product Acceptance Plan

The committee will test the final product / application for acceptance.

13

7.0 Support Process Plans

7.1. Configuration Management Plan

All the project deliverables are to be considered as configuration items. The

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

to the committee would be version 2.0, etc.

7.2. Validation & Verification Plan

A Verification and Validation Plan as a part of the Software Quality Assurance and

Verification & Validation Plan will be developed following recommended departmental

standards. See section 1.1.4 for its delivery date.

7.3. 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

section 1.1.4 for delivery dates.

14

7.4. Quality Assurance Plan

A Software Quality Assurance Plan will be developed following recommended

departmental standards. See section 1.1.4 for its delivery date.

7.5. Review and Audits

Review and Audits would be addressed as a part of the Software Quality Assurance and

Verification & Validation Plan that would be developed following recommended

departmental standards. See section 1.1.4 for its delivery date.

7.6. Problem Resolution Plan

None, problems would be resolved informally between the developer, the advisor and the

studio committee.

7.7. Subcontractor Management Plan

None.

7.8. Process Improvement Plan

None, this is a single software development experience and the lessons learned will be

included in the final studio document.

15

Index

A

Application 1, 2, 10

C

CI 5, 6, 10Client 1, 10CRM 1, 10

I

IEEE 2, 10IT 1, 10

S

SCMP 5, 6, 10SDD 5, 10SPMP 5, 6, 10SQAP 5, 6, 10SRS 5, 6, 10Stakeholder / Customer 1, 3, 5, 10STD 5, 6, 10

T

Tbd 10

16