Smt Spmp for Aets

8/2/2019 Smt Spmp for Aets

1/30


2/30

Software Project Management Plan Hilal Engineers

ii

Change History

Major Field Achievement Test

SPMP Version 1.0 Release date: 02/09/11 Baseline Version


3/30


iii

PREFACE

The purpose of this document is to specify the project plan to develop the Automated

Examination Timetable System (AETS). The primary audience is the project advisor, Madam

Marina Hassan, and other members of the faculty overseeing final projects. 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 me the student, developing the

product as part of the project. Updates of this document will serve to record the progress of the

project.


4/30


iv

ContentsChange History ............................................................................................................................................... iiList of Figures ................................................................................................................................................ v1.0. Overview ........................................................................................................................................... 2

1.0. Project Summary ........................................................................................................................... 21.1.1. Scope, Purpose and Objectives ................................................................................................. 2

1.1.2. Assumptions and Constraints ................................................................................................... 21.1.3. Project Deliverables .................................................................................................................. 31.1.4. Schedule and Budget Summary ................................................................................................ 3

1.2. Evolution of Plan ................................................................................................................................. 41.3. Project Responsibilities ....................................................................................................................... 4

References ...................................................................................................................................................... 5Definitions, Acronyms and Abbreviations ..................................................................................................... 6Project Organization ....................................................................................................................................... 7

4.0. External Interfaces ........................................................................................................................ 74.1. Internal Interfaces ......................................................................................................................... 74.2. Roles and Responsibilities ............................................................................................................ 7

Managerial Process Plans ............................................................................................................................... 85.1.2 Resource Allocation ................................................................................................................12

5.1.3 Budget Allocation ....................................................................................................................125.2.1 Requirements Control Plan ......................................................................................................125.2.2 Schedule Control Plan .............................................................................................................125.2.3 Budget Control Plan ................................................................................................................135.2.4 Quality Control Plan ................................................................................................................135.2.5 Reporting Plan .........................................................................................................................13

5.3. Risk Management Plan .......................................................................................................................136.0. Technical Process ...............................................................................................................................156.1. Process Model ....................................................................................................................................156.4. Product Acceptance Plan ....................................................................................................................16

7.0. Support Process Plans ......................................................................................................................177.1. Configuration Management Plan .................................................................................................177.2. Validation & Verification Plan ....................................................................................................17

7.3.

Documentation Plan .....................................................................................................................17

7.4. Quality Assurance Plan ................................................................................................................177.5. Problem Resolution Plan ..............................................................................................................187.6. Subcontractor Management Plan .................................................................................................187.7. Process Improvement Plan ...........................................................................................................18

Glossary of Terms .........................................................................................................................................19


5/30


v

List of Figures

1. Figure 1. Schedule 42. Figure 2. Definitions, Acronyms and Abbreviations 53. Figure 3. Work Breakdown Structure (WBS) 84. Figure 4. Gantt Chart 19


6/30


2

1.0. OverviewThis document defines the Software Project Management Plan for the Automated Exam

Timetabling System (AETS) product of Hilal engineers (HG). This plan is based on IEEE STANDARD

1058.1,Standard for Software Project Management Plans (ANSI).

1.0.Project Summary1.1.1. Scope, Purpose and ObjectivesThe Automated Examination timetable system (AETS) is an online system which will be

primarily used generate examination timetables. The AETS is being created for Universiti Selangor,

but is not restricted for application in the University. Meaning, it can be implemented in other

Institutions where the necessary infrastructure is in place. The AETS will be able to generate

timetables for each student from a general timetable, therefore students can search using their

names or student ID for a timetable which comprises of their registered subjects.

Examination timetabling is one of the most important administrative activities that take place in all

academic institutions. Hence, developing a system which will automate this activity using a well

formulated algorithm achieved through thorough referencing and research, will certainly ease the

task of examination timetabling. Currently, the examination timetabling is done using an almost

manual and rudimentary method, this allows for human errors which may stem from poor logic or

failure in having a good oversight of the variables involved in creating an efficient timetable.

Examination timetabling might seem like a trivial activity to many, however, there are quite some

significant researches which deal with the potential complexity of creating efficient timetables.

The researches which will be used to accomplish the development of the Automated Examination

System are cited under the references section.

1.1.2. Assumptions and ConstraintsThe author of this document is expected to complete the project within three semesters. This

project will use resources in the form of time and effort that will be spent developing the project

deliverables. The project will be completed under the guidance of a supervisor which is yet to be

appointed.


7/30


3

There are constraints in the form of delay in receiving a dump of the current database been used by

the university, however, this is not a major constraint as itll be resolved in due time.

1.1.3. Project DeliverablesThe list of project deliverables is:

Software Project Management Plan (SPMP) Software Requirements Specification (SRS) Software Design Description (SDD) Software Quality Assurance Plan (including the Software Verification and Validation Plan and

the Test Design Document)

Working System1.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)

September 27, 2011

Software Requirements Specifications October 15, 2011

Software Design Document March, 2012

Software Quality Assurance and Verification &

Validation Plan

Fourth Quarter, 2012

Updated SPMP Fourth Quarter, 2012

Database May, 2012

Software Testing Description Fourth Quarter, 2012

System Integration First Quarter, 2013


8/30


4

1.2. Evolution of Plan

The preliminary drafts of the SPMP will be submitted to my software modeling technique lecturer,

after which the plan will be updated, for each semester an update will be submitted to the lecturer

under which the project documentation is continued. The final SPMP will be submitted along with all

other documentations after completion of the implementation.

1.3. Project Responsibilities

There is one mentor, who is yet assigned from the faculty to the group. The mentor will also function

as the advisor and provide valuable guidance throughout the project. A technical advisor, an expert

from outside the university, will also available to the group.

The client in the project is the Examination unit, Universiti Selangor, represented by the Assistant

Registrar, Norhuda bt Rahmattullah.

Group: Hilal engineers

Project Leader: Shuaib Yunus

Project Manager: Shuaib Yunus

Programmer: Shuaib Yunus

Team Lead: Shuaib Yunus


9/30


10/30


6

Definitions, Acronyms and Abbreviations

The following list of acronyms is used throughout the document. Section 8 contains a glossary of

terminology used in the software industry.

Figure 2.0

Term Description

AETS Automated Exam Timetabling System

HE Hilal Engineers

UNISEL Universiti Selangor

CMMI Capability Maturity Model Integration

RDBMS Relational Database Management System.

SCMP Software Configuration Management Plan

SDD Software Design Document

SQAP Software Quality Assurance Plan

SRS Software Requirement Specification.

WBS Work Breakdown Structure

Stakeholder A person, group or organization with a stake in the outcome of an

application that is being developed.

TDB / tbd To be decided


11/30


7

Project Organization

4.0.External InterfacesThe external interfaces for the project would be the assistant registrar of the Exam Unit of Universiti

Selangor, Norhuda bt Rahmattullah, who is the stakeholder for this project.

4.1. Internal InterfacesNone.

4.2.Roles and ResponsibilitiesThe software developer is responsible for all documentation to be developed and for all work to be

done.


12/30


8

Managerial Process Plans

5.0. Work Plan

Work Breakdown Structure (WBS) (Figure 3.0)

WBS Task Name SPMP Creation Task ID 1

Description Create SPMP for the team project

Sub Tasks

1. Study SPMPs of other projects2. Identify a template3. Outline SPMP format and review it4. Identify all relevant information related to the project5. Gather data, other plans needed for SPMP6. Write SPMP7. Formal review of SPMP8. Receive review from lecturer9. Update with review comments

Entry Criteria

(Dependencies)

Task assignment;

Risk Plan, Estimation plan, Process Plan are all ready

Exit Criteria

(Output)Submit the final SPMP to the lecturer and Exam unit

Milestones SPMP Outline, SPMP draft, review SPMP, final SPMP for the semester

WBS Task NameSRS Creation

Task ID2

Description Create SRS for the team project

Sub Tasks

1. Start gathering requirements from the client (interviews, meetings)2. Get current exam timetabling creation data3. Study current method and identify unfulfilled requirements4. Identify the format for SRS, select a template5. Start populating SRS6. Call formal review7. Send it to client8. Incorporate lecturers comment9.

Submit the final SPMP to the lecturer and Exam unitEntry Criteria

(Dependencies)

Task assignment;

Contact with the client, Contact with the lecturer.

WBS Task Name Technical training and studying Task ID 3

DescriptionTechnical study of existing exam timetable creation method and research

works related to automated timetabling

Sub Tasks

1. Learning of JSP and related concepts of the java web-basedplatform.

2. Learning of JSP API


13/30


9

3. Studying of current database architecture4. Gaining familiarity with the NetBeans for enterprise applications5. Study of mix format data parsing and comparison

Entry Criteria

(Dependencies)

Task assignment;

Environment set up

Exit Criteria

(Output)

Report about the API

NetBeans works

Milestones API study, report

WBS Task Name Software Design Task ID 4

Description Create Software Design of the project

Sub Tasks

1. Identify functionalities2. Create high level design3. Create low level designs4. Create interfaces5. Define algorithms and data structures6. Review design

Entry Criteria

(Dependencies)

Task assignment;

SRS ready, Architecture ready

Exit Criteria

(Output)Forward the design for implementation and testing

Milestones Design Outline, Design draft, review design, final design for the term

WBS Task Name System Test Plan Task ID 5

Description Create System Test Plan

Sub Tasks

1. Study other project plans and outline2. Write test cases for requirements3. Populate the plan4. Formal review the plan

Entry Criteria

(Dependencies)

Task assignment;

SRS ready; Architecture ready, Design Ready

Exit Criteria

(Output)Post the final plan on team web page

Milestones Plan Outline, Plan draft, review plan, final plan for the term


14/30


10

WBS Task Name Software Test Report Task ID 6

Description Create a test report of System testing results

Sub Tasks

1. Define data collection metric2. Begin testing3. Report defects accurately4. Populate metric with pass/fail data5. Produce system test report by functional areas6. Review report7. Incorporate comments8. Post it on the web

Entry Criteria

(Dependencies)

Task assignment;

Test Plan; Software ready for testing

Exit Criteria

(Output)Submit the final report to the advisor

Milestones Test report on a weekly basis covering individual features/functions

WBS Task Name Software Installation Guide Task ID 7

Description Installation guide for the user

Sub Tasks

1. Study other installation guides2. Analyze user interface3. Write instructions for installation4. Formal review the guide5. Incorporate review comments6. Test installing the product from the CD following the manual7. Post it on the web, make it available to the client

Entry Criteria

(Dependencies)

Task assignment;

Software

Exit Criteria

(Output)Present the installation guide to the examination unit

Milestones Guide draft, guide final, test guide, final guide ready

WBS Task Name User Manual Task ID 8

Description Create user manual for the client

Sub Tasks

1. Study other user manuals2. Capture GUI information for the Manual3. Divide the writing tasks and assign to developers who implemented

the functions

4. Incorporate all writings5.

Incorporate limitations, known issues6. Formal review of the manual


15/30


11

7. Incorporate review comments8. Burn it on the CD along with the software9. Present to the examination unit

Entry Criteria

(Dependencies)

Task assignment;

Software

Exit Criteria

(Output)Submit the final user manual to the exam unit and any related units.

Milestones User manual Outline, review manual, final manual for the term

WBS Task Name Software Developers Guide Task ID 9

Description Create developers guide for future work

Sub Tasks

1. Study other guides and outline one for the team2. Identify APIs3. Test APIs4. Document APIs5. Document major functionalities and describe6. Justify design choices7. Provide a code tree structure8. Identify all tools used9. Write the guide10.Formal review11. Incorporate review comments12.Post it on the web page

Entry Criteria

(Dependencies)

Task assignment;

All artifacts including software

Exit Criteria

(Output)Post the final guide on team web page

Milestones Guide Outline, review guide, final guide for the term

WBS Task Name AETS Software Task ID 10

Description Software product ready

Sub Tasks

1. Setup environment2. Resources and tools ready3. Assign coding tasks4. Code5. Code reviews6. Unit test7. Integrate8. System Test9. Fix defects


16/30


12

10.Regression testing11.Acceptance test12.Burn it on a CD13.Test CD installation14.Product ready for the client

Entry Criteria

(Dependencies)

SRS finalized; Design ready; architecture identified; System test plan in place

Configuration Management plan ready, tools and environment ready

Exit Criteria

(Output)Acceptance criteria satisfied

Milestones Intermediate weekly builds

5.1.2 ResourceAllocationThis 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.4.

5.1.3 Budget AllocationNone.

5.2. Control Plan

5.2.1 Requirements Control PlanWhen changes are to be made in the requirements after the SRS has been released, the changes

shall be brought to the attention of the developer and discussed. Any changes that are to be made

will be with the prior approval of the developer and only if feasible in terms of resources, 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 PlanIf the work scheduled as described in the work breakdown structure gets behind, the developer is

ready to spend extra time on the project in between and after the schedules and also during

semester breaks to make up for the lost time and deliver the final project on time.


17/30


13

5.2.3 Budget Control PlanNone.

5.2.4 Quality Control PlanPlease refer to Software Quality Assurance Plan regarding Quality Control.

5.2.5 Reporting PlanThe updated SPMP will be circulated as mentioned in schedule. 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 client at the exam unit and any

other parties involved. The report on the status of the project will be sent to the advisor and the

exam unit will be notified if need be.

5.3. Risk Management Plan

Risk # 1Deficiency 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 # 2Lack of Skills and knowledge of tools needed for data analysis and algorithm design, which

means that the developer does not have knowledge about the tools and knowledge of working on

data analysis and effective algorithm design. In this case, the developer is expected to update his

knowledge of tools available for this purpose and decide the one that will be used in the project and


18/30


14

master it. The developer may consult the faculty and other lecturers of the faculty especially, the

advisor for this purpose.

5.4. Closeout Plan

All the system and supporting documents will be delivered to the exam unit, accompanied by a final

project presentation.


19/30


15

6.0. Technical Process

6.1. Process Model

The Automated Examination Timetabling System will be implemented and executed using extreme

programming and prototyping.

6.2. Methods, Tools, and Techniques

The AETS will be developed for online usage with a web interface, and mySQL as its database

management system. The server-side scripting language to be used is the Java Server Pages (JSP)

with SQL for queries; the client-side scripting language will be HTML + CSS + JavaScript. The tool for

the data parsing and analysis is undecided at this point of time and would be mentioned in the

updated version of this document.

The method that the team wishes to follow for the project is borrowed from a couple of

methodologies. The team intends to RUPs use case analysis for requirements analysis during the

semester 1/2011/2012. However, RUPs heavy reliance on supporting tools was a reason for the

team to keep away from using that method fully.

The system will be algorithm intensive, which can be understood as trial intensive (a lot of trial and

error), therefore for development of the timetable generating functionality, the team will use

Extreme Programming practices.

The development activities will be carried out on Pentium based Personal Computers (PC) running

Windows 7, provided by the MSE program. The team has decided to use Eclipse (version 2.1) as the

Integrated Development Environment (IDE) for development, testing, integration as well as building

activities. The team will use Java (JDK 1.7) as the programming language.

The team is considering using JUnit for unit testing tools. However this choice may change

depending on the usability of the tool. Bugzilla will be used for defects tracking system. Teams

Software Quality Assurance Plan will be followed to keep the quality of the product to acceptable

standards as agreed between the team and the client.

6.3. Infrastructure Plan

The hardware resources is one 1.0 GHz Pentium computer running Windows 7 Operating System.

The computer should have at least 512 MB RAM and a minimum of 2 GB of disk space.


20/30


16

6.4. Product Acceptance Plan

The developer will test the final system for the exam unit, the results will be presented to the exam

unit, and therefore the system is subject to the exam units acceptance.


21/30


17

7.0. Support Process Plans

7.1. Configuration Management PlanAll 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 advisor and stakeholders (exam unit).

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 PlanA 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 PlanThe 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.

7.4. Quality Assurance PlanThe purpose of the SQAP plan is to describe the procedures and control mechanisms used by the

team to ensure high levels of quality in each of its products. The document describes both the

quality assurance activities undertaken by the team and the methods used for monitoring and

tuning the efficiency of those activities. The QA manager is responsible for all QA related activities

and will assign resources. He will also ensure that the successful execution of activities identified in

the plan.


22/30


18

There are two main activities as far as the Quality assurance activities for the project is concerned.

The first one is related to documents and code reviews and the other is to testing.

Document reviews

For all written documentation formal reviews will be held to establish the quality of the documents.

All documents will follow templates borrowed or adapted from known, accepted standards such as

the IEEE etc.

7.5. Problem Resolution PlanNone, problems would be resolved informally between the developer, the advisor and the assistant

registrar of the exam unit

7.6. Subcontractor Management PlanNone.

7.7. Process Improvement PlanNone, this is a single software development experience and the lessons learned will be included in

the final AETS document.


23/30


19

Glossary of Terms

Figure 4.0 Gantt Chart

Acceptance Criteria The list of requirements that must be satisfied prior to the customer accepting

delivery of the product.

Acceptance Test Formal user performed testing performed prior to accepting the system

(sometimes called client acceptance test or user acceptance test).

Activity- A specific project task, or group of tasks, that requires resources and time to complete.

Application Generic term for a program, or system, that handles a specific business function.

Application Software It is a complete, self-contained program that can perform work for a user.

This is in contrast to system software such as an operating system, server processes, and libraries

that exist in support of application software.

Architecture Imposes order and makes interconnections possible. Generally defined as an

intermediate step between initial requirements and business functional specifications during which

the entire complex of hardware, software, and design considerations are viewed as a whole. It refers

to a blueprint for evolving a technical infrastructure.


24/30


20

Architectural Model It is a high level description of components, their interconnections, and other

constraints.

AvailabilityThe portion of time that a system that is scheduled to operate actually can be used as

expected.

Budget A planned sequence of expenditures over time with costs assigned to specific tasks and

activities.

CASEComputer Aided Software Engineering - Systems that attempt to automate some or all of

the tasks involved in managing, designing, developing, and maintaining software systems.

Change Management The formal process of recording, analyzing, estimating, tracking and

reporting of changes to the project baseline business functional requirements.

Client/Server System It is primarily a relationship between processes running on separate

machines. A client initiates the dialog by sending requests to the server asking for information or

action.

Component

An element within a power train system. The component consists of two parts: acomponent characterization and a Simulink model.

Configuration Management Methodical storage and recording of all software components and

deliverables during development.

Constraint- A restriction or limitation imposed on a model or a component.

Contingency Plan - An alternative for action if the project does not proceed according to plan or if

the expected results are not achieved.

Cost / Benefit Analysis A formal study in which the development, execution, and maintenance

costs for a project are matched against the anticipated value of the product.

mon forms of networking systems. CPM uses a one-time estimate for creating a project schedule.

Customer- The individual or organization that specifies and accepts the project deliverables.


25/30


21

Data Describes the numbers, text, graphics, images, and voice stored in a form that can be used by

a computer.

Data type- Format used to represent signal values internally.

Data Warehouse Where you consolidate and store data from many sources.

Deliverable A tangible, physical object that is the output of a software development task.

Design The tasks associated with specifying and sketching the features and functions of a new

application prior to coding.

Development Project It is the sum of all tasks and activities necessary to build a software product.

Documentation The printed and displayed materials that explain an application to a user.

Duration - The period of time over which a task takes place. Duration establishes the schedule for a

project.

Effectiveness - A measure of the quality of attainment in meeting objectives.

Efficiency- A measure of the volume of output received for the input used.

Effort- The amount of work or labor (in hours or workdays) required to complete a task.

Environment The set of tools and physical surroundings in which software is developed.

Estimate A predicted total of expenditures required to complete a task, activity, or project.

Exit Criteria The set of conditions that must be met prior to completing a project phase or

application.


26/30


22

Feasibility Project A project designed to prove, or disprove, the appropriateness of the technology

solution under existing constraints (sometimes called proof-of-concept project).

Function - An activity that spans the entire duration of a software project (e.g., status reporting,

quality assurance, verification and validation).

Gateway Hardware or software that translates between two dissimilar protocols.

Graphical User Interface (GUI) A manner of presentation that makes use of windows, icons,

menus, pointers, and scroll bars.

Hardware Physical equipment used to process, store, or transmit computer program data.

Information The meaningful interpretation of data.

Integration Describes the work, or device, required to connect two different systems that were

not originally designed to work together.

Integration Test Testing in which software components, hardware components, or both arecombined and tested to evaluate the interaction between them.

Interface A connection between two devices or systems.

Issue A problem to be solved or a decision that has not been made.

Maintenance Refers to the ongoing activity that keeps software functioning in a technical and

business environment (production).

Methodology A set of formal protocols followed when performing a task.

Milestone A major checkpoint in the activities involved in a project. A clearly defined point in a

project that summarized the completion of a related set of tasks.


27/30


23

Model- A way of looking at reality, usually for the purpose of abstracting and simplifying it to make

it understandable in a particular context. A schematic description of a system.

Operating System System software that controls data storage, input and output to and from the

keyboard, and the execution of applications written for it. It performs base services: prioritizing

work, scheduling, memory management, etc.

Phases The divisions of a software development life cycle into discrete stages (e.g., requirements,

design, code, test, etc.).

Planning Project A project intended to gather, or predict, the sequence of activities and resources

needed to complete a work effort.

Platform The hardware and support software with which a program is intended to operate.

Process The step-by-step sequence of activities (systematic approach) that must be carried out to

complete a project.

Programming The art of writing, in a computer understandable language, a set of instructions thatproduces software.

Project The combined resources (people, machines, materials), processes, and activities that are

dedicated to building and delivering a product to a customer.

Project Duration - The time it takes to complete the entire project.

Project Management- The combination of systems, techniques, and people required to successfully

complete a project on time and within budget.

Project Manager The senior person responsible for the entire project.

Project Plan A formal document that describes the technical and management approach to be

followed for a project.


28/30


24

Quality (Product) - Conformance to business functional requirements with defect-free products.

Quality reflects both the completeness of software or system features and functions, and error-free

operation.

Quality (Process) Verification and validation to established policies, standards, procedures and

guidelines for software development.

Relational Database A collection of data that is organized into tables so that relationships

between and among data can be established.

Repository- A place where Ford stores and organizes its components

Requirements The statement of needs by a user that triggers the development of a program,

system, or project. May be called business functional requirements or requirement specifications.

Research and Development Project A definition of a project type essentially exploring options for

developing new systems or work products.

Risk The probability that a project will experience undesirable events, which may create, costoverruns, schedule delays, or project cancellation. The identification, mitigation, tracking, and

management of those elements creating the risk situation.

Risk Analysis - An evaluation of the feasibility or probability that the outcome of a project will be the

desired outcome.

Scope - The magnitude of the effort required to complete a project.

Server A computer on a network that makes applications, print services, data, and communications

available.

Software Computer programs, systems, and the associated documentation that describes them.

SDLC - Software Development Life Cycle The period of time that begins with the decision to

develop a software product and ends when the software is delivered.


29/30


25

Software Development Process The process by which user needs are translated into a software

product.

Software Project Management Plan - The controlling document for managing a software project.

The SPMP defines the technical and managerial project functions, activities, and tasks necessary to

satisfy the requirements of a software project.

Specifications General term for the wide variety of paper-based descriptions of a program or

system.

Stakeholders - People who have a personal or agency interest in the end results of a project.

Statement of Work (SOW) - An integrated set of task descriptions, goal descriptions, risks, and

assumptions that accompany the evolving master project plan during development.

System A linked collection of programs, or components, which performs a generic business or

technical function.

System Test The final stage of testing on a completed project (prior to client acceptance test) whenall hardware and software components are put together and tested as a whole.

Task- A cohesive unit of work on a project (usually 40 to 80 hours of effort).

Task Description - A description that defines all the work required to complete a project task or

activity including input, output, expected results, and quality specifications.

Test Plan A document that describes the scope, approach, resources, and schedule of intended

test activities.

Testing The set of defect removal tasks that include execution of all, or part, of an application on a

computer.

Unit Test - The testing carried out personally by individual programmers on their own code.


30/30


Work Breakdown Structure (WBS) A formal analysis of the activities, tasks, and sub-tasks that

must be accomplished to build a software project. A product or activity oriented hierarchy tree

depicting the elements of work that need to be accomplished in order to deliver a product.

Documents

Smt Spmp for Aets