You are on page 1of 35

Software Project Plan

2.0
Team Name:
A New Hope

Team Members:
Andrew Voszatka
Josh Major
John Battaglia
Kenny Urena
1.0 Introduction
1.1 Project Scope
Description of Software
 Console Based Bidding/Selling program

Inputs
 Login/Password of sellers/bidders
 Item information including: Title, starting bid, description, and ending date
 Item to be searched
 Feedback comments (additional functionality)
 Feedback score (additional functionality)

Outputs
 Total amount in sales
 number of items
 total items unsold
 total amount of money spent by a bidder
 number of items purchased by bidder
 items bidder bids on that are in progress with totals-number in-progress, number winning,
$ amount of winning items

Processing Functionality
 Input of login/password by user and/or seller

 Authentication/Validity is checked

 Once authenticated sellers can post items that they want to sell

 Search item results will be in lists

 Items will be put in alphabetical order so it's easier for bidder to find what they are

looking for

 Bidders can bid on available items based on money available and how much they are

willing to spend on an item


 At the end of the time period given, the person who would spend the most will win the

item

 A collection of operations will take place after each auction. Such as declaring the

winner, updating items sold, dollars spent, and search list

1.2 Major Software Functions


Functionality:
Seller:

 Be able to post an item to sell

 Set Item’s details upon bidding: title, description, starting price, ending date

 Be able to view history: total dollar amount sold, total unsold, items with no bids

 View dollar amount of winning items

Bidder:

 Place bid on “in-progress” items

 Win bids, if highest bidder on end date

 View bid history and details: total dollars spent and number of items, and dollar amount
of winning items

 View items they bid on that are in progress with totals: number in-progress and number
winning

Aministration:
 Alphabetical list of items

 Searching mechanism for items (based on keywords for words in the title or
description)

 Display Accurate Item price


 Charge winning bidder accurate price and add amount to seller’s totals

1.3 Performance/Behavior Issues

There are no special requirements for performance or behavior to note.

1.4 Management and Technical Constraints

Time Constraints:

 Deadline of Software Project Management Plan: March 4, 2013

 Deadline of Software Requirements Specification: March 25, 2013

 Drop dead delivery date of completed program: April 15, 2013

 Our team members are all full-time college students, and thus have limited time to work
on the project.

Knowledge Constraints:

 The following table shows what programming languages each team member has knowledge of.
"Highly Skilled" means the team member is very familiar with the language, "Known" means the
team member has some familiarity with the language, "Pending" means the team member is
currently learning the language, and "None" means the team member has no significant
knowledge of how to use the language.

Team Member

Knowledge Andrew John Kenny Josh

C++ Highly Skilled Highly Skilled Highly Skilled Highly Skilled

Assembly (68K) Known Known None Known

PHP None Known None Known

VB.NET None Known None Known

C None Known None Known


HTML/CSS None Known None Known

Drupal None Known None None

Linux/Unix shell None Known None Known


scripting

Java None None Known None

SQL Pending None Pending None

C# None None Pending None

 Any languages not listed are unknown to any of the team members. Thus, the project
must be conducted entirely using the above languages, unless we wish to invest a large
amount of extra time learning new languages.

 If team wishs to use database languages in the project, we will have to wait until Kenny
and Andrew get far enough in their Database class this semester to have learned it.

 None of the team members are aware of how to create a single application using multiple
programming languages.

Financial Constraints:

 Our customer is unwilling to pay any money.

 Our team members are all of limited means financially, and as we are already paying
thousands of dollars for the class alone, we are unlikely to be able to afford spending any
money on the project.

 Given the above factors, our budget for this project, not including transportation
expenses, is limited to $0.

Technical Constraints:

 Team's program must be capable of running on the professor's computer through an easy
step-by-step process.
 The program must be able to run quickly enough so that it's user-friendly.

 There is no upper bound given for how much activity the auction system will be
handling, so the program must be capable of running properly even for extremely large
numbers of users and transactions.

 The program is designed to be used by ordinary people, so its interface must be easily
usable even by someone with no programming background.

2.0 Project Estimates

2.1 Historical data used for estimates

Estimates for the Software Project Plan were formed by considering our team members’ writing
speed in the past and estimating the section’s length. Estimates for the production of the correct
functionality are based on the complexity of task, past experiences, and employing rigorous
testing once a task is completed. The design section has a minimum of .5 hours for the main
project to ensure sufficient time is dedicated to it.

2.2 Estimations Techniques Applied and Results

Only one estimation was made based on past historical data and educated guesses.

2.3 Estimates

ESTIMATES FOR SOFTWARE PLAN

Section Group Member Estimated Time Needed


Responsible (Hours)
1.1 Josh 1
1.2 John 1
1.4 Andrew 1
2.1 Kenny 1
2.3 Kenny 3
3.1 Andrew 3
3.2 Andrew 1
3.3 John 1
4.1 Josh 1
4.2 John 1
4.3 Andrew 3
4.4 Andrew 1
5.1 Kenny 2
5.2 Kenny 1
6.1 Josh 2
6.2 John 1
Time Spent in Meetings Estimate: 10
Time Spent Revising Final Project: 6
Presentation 1 Preparations: 1
Software Plan Total Estimated Time: 40

ESTIMATES FOR PROGRAM

Task/Base Functionality: Estimated Time Needed


(Hours)
Training in programming languages (in totals) 36

User Log In/Log out System

Design 1
Implementation 3
Testing 1

Seller:
Post Item to sell with title/description/ Starting Price/End date

Design 1
Implementation 15
Testing 5

View Seller’s Items’ Status (In-progress/Sold)

Design 0.5
Implementation 3
Testing 1

View Totals/History (Total sales/# of items/Total unsold/No bids)

Design 1
Implementation 10
Testing 3

Bidder:
View List of Items purchased (View History) with totals:
-Total $ spent (completed), Number of items bought, Status (in progress/done)
-Total number of bids in progress, Bids winning, $ amount of winning items

Design 2
Implementation 8
Testing 5

Search Function:

Design 1
Implementation 3
Testing 2

Category System for Items

Design 1
Implementation 2
Testing 1

Bid Price Display


- place specified starting bid if no other bids shown
- Shows Highest Bid if More than two bids
Design 0.5
Implementation 2
Testing 2

Bid Payment/Result

-price is second high bid + 10%, charged to winning seller


after time is over
-If no bids, bid ends status changes to completed and no transaction
take place

Design 1
Implementation 4
Testing 2

Keywords in title and description For Search


Design 1
Implementation 3
Testing 2

Database Functionality Development and testing for all features: 20

Total Estimate for Program: 144

ADDITIONAL FUNCTIONALITY

Kenny’s Additional Functionality

Allow user to change password

Design 0 .5
Implementation 3
Testing 1

If a field has data entered and the user tries to quit then display: “are you sure you want to
exit? [name] has data entered into it and will not be saved”

Design 0 .5
Implementation 1
Testing 2

Leave an “X” out of 5 star rating after purchase

Design 1
Implementation 4
Testing 2

Kenny’s Total: 16

Andrew’s Additional Functionally

Notify a seller when the end date of an item they listed for sale has been reached.

-Tell the seller what item it was, whether it was successfully sold or not, and if so, how
much it was sold for.
Design 0.5
Implementation 2
Testing 2

Seller can edit the starting price or end date of an in-progress item they listed for sale, if nobody
has thus far bid on it.

Design 1
Implementation 3
Testing 2

Seller can cancel their listing of an in-progress item if nobody has thus far bid on it.

Design 1
Implementation 3
Testing 2

Bidder notification when the end date of an item they bid on has been reached.

- The notification should tell the bidder the item, if their bid was successful or not, and
the final sale price was.
Design 1
Implementation 4
Testing 3

Let bidder know if they have already made a bid.

-Asks user if new bid should be placed.

Design 1
Implementation 2
Testing 1

Display an error message when an incorrect or nonexistent login id or password is entered.


Design 0.5
Implementation 1
Testing 0.5

Andrew’s Total: 31.5

John’s Additional Functionality


Security Algorithm

Design 1
Implementation 4
Testing 1

Message Boards

Design 1
Implementation 3
Testing 2

Add comments to a user member


Design 0.5
Implementation 3
Testing 2

Change currency format to European or US style

Design 0.5
Implementation 2
Testing 1

Change data format to European or US style

Design 0.5
Implementation 2
Testing 1

John’s Total: 24.5

Josh’s Additional Functionality:

The list of items sold under each category is in alphabetical order


Design 1
Implementation 2
Testing 1

Display an error message when a bidder types in an invalid item to bid on

Design 0.5
Implementation 2
Testing 1

Calculate the average of the ratings to see an overall rating for each seller

Design 1
Implementation 3
Testing 2

Replace password input character with x’s

Design 0
Implementation 1
Testing 0.5

Josh’s Total: 15

Extra Functionality Group Total: 89

TOTAL ESTIMATED HOURS FOR PROJECT:

Task Hours
Software Plan 40
Base Functionality 151
Additional Functionality 87
Project 2 Completion, Revisions, and Preparations 212
Group Meetings 35

Total 525
2.4 Project Resources
While a complete team would contain all of the following personnel, A New Hope has four team
members. Each team member will be performing multiple jobs.
 Required Staff

o Project Manger-John

o Project Team Leader-John

o Business Analyst-John

o Software Architect-Kenny

o Designer-Andrew

o Software Developer-Andrew

o Software Tester-Josh

 Required Software

o Microsoft Visual Studio 2012 C++

o Microsoft Office (or open source equivalent)

o Adobe Photoshop (or open source equivalent)

o Microsoft Windows OS

o Dropbox

o Skype

o Google Docs

 Required Hardware (to run Visual Studio-Development software)

o 1.6 Ghz or faster processor


o 1 GB of RAM (1.5 GB if running on a virtual machine)

o 15 GB (NTFS) of available hard disk space

o 5400 RPM hard drive

o DirectX 9-capable video card running at 1024 x 768 or higher display resolution

3.0 Risk Management


3.1 Project Risks
 Loss of Team Member: If a team member were to drop the class, or worse, die.

 Indisposed Team Member: If a team member were to become incapacitated or otherwise


unavailable for a significant length of time, such as due to injury, illness, or other
problems.

 Personal Data Loss: If a team member's computer or other memory storage device
crashed, causing their work done thus far to be lost.

 Online Data Loss: Data we have stored online might be lost, perhaps due to unforeseen
technical difficulties on the part of the website.

 Online Data Unavailability: Data we have stored online may be made temporarily
unavailable at an important time, perhaps due to scheduled maintenance on the part of the
website.

 Irresponsible Team Member: If a team member were to become irresponsible and refuse
to do the work assigned to them.

 Procrastinating Team Member: If a team member were to refuse to do work until the
absolute last minute.

 Conflicting Responsibilities: If a team member were to become so busy with other


responsibilities, such as homework or exams from other classes, that they are temporarily
unable to invest time on this project.

 Poor Estimates: If we underestimate the amount of time a project task will take, and thus
have less time for later tasks.
 Language Incompatibility: If we determine that our chosen language, is incapable of
fulfilling the project's needs, and have to change to a different language.

 Changed Requirements: Our customer, the professor, may clarify the assignment, or give
us other instructions that require us to revise our project's technical requirements.

 Language Learning Difficulty: One or more of our team members may have difficulty
adjusting to the programming language of choice and thus be incompetent in their coding,
or outright be unavailable to code until they've learned it.

 Unable to Meet: School closings or unexpected schedule conflicts might interfere with
team meetings.

 Coding Errors: Even once the code is apparently complete, there might be countless
errors that take hours to debug, some of which may even require us to revise our
documentation.

 Debugging Difficulties: If the person assigned to do so proves incapable of fixing a


coding error within a reasoable amount of time.

 Additional Functionality Problems: If implementing one or more team members' pieces


of additional functionality proved too difficult, time-consuming, or impossible.

 Code Merging Difficulties: If the completed functionality coded by different group


members proved incompatible, and need to be changed drastically to make them work
with each other.

 Personal Conflict: If a personal conflict between two or more team members occurred,
which might prove disruptive to the group and hurt our progress.

 Electronic Sabotage: If malware or hackers damaged a team member's ability to


participate in the project, such as by stealing their online accounts, making their
computers nonfunctional or buggy, or something else along those lines.

 Compiler Incompatibilities: If using different compilers caused code written by one team
member on their compiler to not work for the other team member on their differing
compiler.

 Time Runs Out: If it looks like we will be unable to meet the project deadline.
3.2: Risk Table

Risk Name Probability Impact RM3 Pointer

Loss of Team Member Low Critical Mitigation #1,


Monitoring #3,
Monitoring
#6,Management #2

Indisposed Team Low High Mitigation #1,


Member Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #2

Personal Data Loss Medium High Mitigation #1,


Monitoring #6

Online Data Loss Low Medium Mitigation #3,


Monitoring #6

Online Data Low Medium Mitigation #3,


Unavailability Monitoring #6

Irresponsible Team Low Critical Mitigation #1,


Member Monitoring #5,
Monitoring #6,
Management #2

Procrastinating Team High Medium Monitoring #5,


Member Monitoring #6,
Management #8
Conflicting High High Mitigation #8,
Responsibilities Monitoring #2,
Monitoring #6,
Management #2

Poor Estimates High Medium Mitigation #2,


Monitoring #1,
Monitoring #6,
Management #1

Language Incapability Low High Mitigation #4,


Monitoring #1,
Monitoring #6,
Management #4

Changed Low High Monitoring #6,


Requirements Management #3

Language Learning Low High Mitigation #2,


Difficulty Mitigation #4,
Mitigation #9,
Monitoring #1,
Monitoring #6,
Management #1

Unable to Meet Medium Medium Monitoring #4,


Monitoring #5,
Monitoring #6,
Management #5,
Management #6

Coding Errors High High Mitigation #9,


Monitoring #6,
Management #3

Debugging Difficulties High High Mitigation #9,


Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #1,
Management #3

Additional Medium Low Monitoring #1,


Functionality Monitoring #5,
Problems
Monitoring #6

Code Merging High Medium Mitigation #6,


Difficulties Mitigation #9,
Monitoring #5,
Monitoring #6,
Management #1

Personal Conflict Low High Monitoring #6

Electronic Sabotage Low Varies depending on Mitigation #1,


severity; potentially Mitigation #3,
critical. Mitigation #5,
Monitoring #6,
Management #2

Compiler Low Low Mitigation #7,


Incompatibilities Monitoring #6

Time Runs Out Medium Critical Mitigation #2,


Mitigation #9,
Monitoring #1,
Monitoring #5,
Monitoring #6,
Management #1
Management #2,
Management #7

3.3: Overview of Risk Mitigation, Monitoring, Management

Mitigation
1. Have a backup for all project work so far completed-- stored online.
2. Allocate an extra amount of time for project tasks - assume that project tasks may take
longer than estimated, and plan accordingly.

3. Team members should not delete any project work they have done even after they upload
them, in case the online data is lost somehow.

4. Team members should begin learning the programming language of choice before we
actually have to code the project - preferably over spring break at the latest.

5. All team members should ensure they have some form of anti-virus and firewall installed.

6. Team members should keep each other informed of the methods by which they are
implementing their portions of the code with short e-mail summaries.

7. All team members should use Microsoft Visual Studio as their compiler.

8. Team members should have slightly reduced workloads during weeks when they have
multiple exams, and should be assigned larger workloads to make up for it on other
weeks when other team members have the same problems.

9. Allocate adequate debugging and testing time in project schedule.

Monitoring
1. If a team member thinks they will not be able to meet their deadline on a task, they
should immediately e-mail the group to say so.
2. Team members should tell the group about any exams or projects from other classes that
may prevent them from working on this project.

3. If a team member feels they may have to drop the class, they should warn the group as
early as possible.

4. If a team member can't make an assigned meeting time, they should say so in advance.

5. The team leader should regularly ask team members how their tasks are progressing.

6. The team should briefly discuss all the project risks, and possible new risks, at least once
per meeting.
Management
1. In the event that a team member is unable to complete a task on their own or takes too
long, team leader should assign another team member to assist them. The two team
members should then meet in person to overcome the hurdle.
2. In the event that a team member is unable or unwilling to do a job, the team leader should
assign another team member to perform the task. If the team member is being
irresponsible, the team leader and the rest of the team should threaten the team member
with negative evaluations.
3. If it becomes necessary to make large revisions of earlier documentation to the point that
it distracts from other project tasks - have one person put in charge of revising all the
earlier documentation as necessary, with the other team members just telling that person
what they changed, so that the rest of the team can focus on the current portion of the
project instead of spending all their time revising the documentation over and over again.
The team leader should OK the final revision for each part of the project. The least adept
coder should preferably be assigned this task.
4. In the event that we have to change programming languages, we should decide at a
meeting whether it would be better to reduce the project scope before we go to the trouble
of starting over with another language, and the team should pick a new language that at
least three people in the group already know, as we are unlikely to have time to learn a
new language.
5. In the event that the group is unable to meet in person, we should hold a group meeting
over Skype.
6. In the event that a member can't make it to a meeting, the team leader should send them
an e-mail summarizing the decisions and results of the meeting.
7. In the event that it looks like we literally cannot meet the deadline for the project, we
should reduce the project scope and just try to have some partially functional program to
turn in.
8. If a team member appears to be procrastinating, the team leader should politely but
incessantly remind them to start their task soon.

4.0 Project Schedule


4.1 Project Task Set

Process Model

1. Model: Waterfall Model


Framework Activities and Activities

2. Compiler: Visual Studio 2012

3. Language: C+

 Tasks to be accomplished

 Set up a login and password for users to access

 Password input replaced by x's

 Limit username size between 6-15

 First character must be a letter

 Sellers lists items available for sell in the database

 Keep Track of Seller information

 Items to sell

 Details about item: Title, Description, Starting price, ending date, total dollar amount,
total unsold, items with no bids

 Keep track of Buyer/Bidder information

 List of items they purchased with:


 Total dollars spent

 Number of items

 Items they bid on that are in progress with totals:

 Number in-progress

 Number winning

 Dollar amount of winning items

 Searching mechanism

 Alphabetical list of items

 Different categories of items

 Looking for words in the title or description

 The bidding process

 During an in-progress auction, the bidder can place a bid on that items that must be
higher than the current price shown which is starting price if no bids, bid price if one bid
or second high bid + 10% if multiple bids (bid price if bid price is less than second high +
10%)

4.2 Functional Decomposition

Base Functionality:
 Seller
o Ability to choose item categories
o Editable item details
 Title
 Description
 Starting Price
 Ending Date
o List of items
 Sold
 In-progress
 Or both
o List of totals for items
 $ amount of sales
 Number of items
 Total unsold (completed)
 No bids (in-progress)
 Bidder
o List of items
 Purchased with totals
 Total $ spent(completed)
 Number of items purchased
 Items they bid on that are in-progress
o List of totals
 Number of bids in progress
 Number of bids winning
 $ amount of winning items
o Bidding on in-process items from ANY list
 Place specified starting bid if no other bids shown
 Place bids higher than current price shown
 Bid price if one bid or second high bid + 10% if multiple bids (bid price if
bid price IS LESS than second bid + 10%).
 Administration
o Must have login IDs and passwords
o Search by
 Category

Additional Functionality:
 Seller
o Notify seller when end date of an item listed for sale has been reached
 Which item
 Successfully sold or not
 If sold, how much sold for
o Ability to cancel item if no bids have been placed
 Bidder
o Notify bidder when end date of an item they bid on has been reached
 Which item
 Successful bid or not
 If won, how much bought for
o If bidder attempts to place a bid on item, interruption in the system occurs if
bidder has already placed bid on that item.
 System notifies bidder they have already placed bid
 Asks user if they would still like to place the bid
o Leave a X out of 5 star rating after purchase
 Administration
o Display error message when an incorrect or nonexistent login ID or password is
entered
o Security algorithms to keep user passwords secure
o Allow user to change password
 typing in current password, then new password twice
o Message board for items being sold
o Ability for all users to add comments to a seller or buyers profile
o Ability to change currency format to European or US style
o Ability to change date format to European or US style
o If a field has data entered and the user tries to quit then display: “are you sure you
want to exit? [name] has data entered into it and will not be saved”
o List of items sold under each category can be listed alphabetically
o Display error message when a bidder types in an invalid bid
o Calculate average of the ratings to sees an overall rating for each seller
o Replace password input with “x”'s
o Set a limit of user name size between 6-15 with only letters and numbers, first
character must be a letter.

4.3 Task Network and Timeline Chart


Task # Task Duration Predecessors
1 Meeting 1 .5 hours
2 Decide Additional Functionality 1 hour 1
3 Software Project Plan Section 1 3.75 Hours 1
4 Meeting 2 1.5 Hours 2
4 hours
5 Software Project Plan Section 2 4
6 Software Project Plan Section 3 2.5 Hours 4
7 Meeting 3 1.5 Hours 3,4
8 Software Project Plan Section 4 4 Hours 7
9 Software Project Plan Section 5 3 Hours 7
10 Software Project Plan Section 6 3 Hours 7
11 Meeting 4 1.5 Hours 5,6,7
12 Software Project Plan Section 7 .5 Hours 11
13 Meeting 5 4 Hours 8,9,10,11,12
14 Software Project Plan Revision 6 Hours 13
15 Project 1 Presentation Preparation 1 Hour 11
16 Project 1 Presentation To Class 15 minutes 14,15
17 Learning Programming Languages 36 Hours
18 Other Meetings 20 Hours 16
19 Project Part 2 200 Hours 16
20 Revisions of Project 1 6 Hours 19
21 Implementing Login Functionality 5 Hours 17,19
22 Implementing Seller Functionality 39.5 Hours 17,19
23 Implementing Buyer Functionality 15 Hours 17,19
24 Implementing Searching Mechanism 12 Hours 17,19
25 Implementing Bidding Process 16 Hours 17,19
26 Implementing Additional Functionality 89 Hours 17,19
27 Revisions of Project 1 and 2 12 Hours 21,22,23,24,25,26,27
28 Final Presentation Preparation 1 Hour
20 Final Presentation 15 minutes 28
Section 5: Staff Organization

5.1 Team Structure


The team roles and responsibilities for the team are determined by who is best suited for each

position. John is the most knowledgeable member of the team so he is the Project Team Leader

and Manager. His responsibilities include ensuring deadlines are met, issues are resolved swiftly,

and that everyone understands what their assignments are.


The project will be divided into database and forms for design. Kenny and Andrew are in a

database class and are better suited to design and implement the tables and queries that will be

required. John and Josh have a background working with form based applications (VB.NET) and

would be better suited to designing how the forms will look, integrate query result data, and

function

The entire team will serve as software developers and testers when writing their own code. Their

responsibility is to ensure the code segment has sufficient comments and delivers on its required

functionality without enormous mistakes or bugs.

5.2 Management Reporting and Communication

The team will hold meetings every Thursday morning at 11:00 AM to discuss current project

progress. For more immediate communication all members have access to each other’s email,

cell phone numbers, and Skype. In addition, all members will briefly discuss their current status

on Mondays and Wednesday before/after the software engineering classes. Dropbox and email

will be used as primary means to share important artifacts. The team will identify level of

progress by using metrics created during a very detailed design phase.

6.0 Tracking and Control Mechanisms

6.1 Software Quality Assurance


Quality is a key aspect of a product. There are seven elements to assure this.
 Application of Technical Methods
 Formal Technical Reviews
 Software Testing
 Control of Change
 Measurement
 Record Keeping
 Reporting
Application of Technical Methods
 It's good if you know how to code, but if the planning is bad and you don't understand
what the correct problem is, you will end up with the wrong results
 The analyst plays an important role in this. He/She should know how to:
o Grasp abstract concepts
o Organize solutions to smaller problems
o Absorb facts from different sources
o Understand the user/client environment
o Apply hardware and/or software system elements to the environment
 Modeling has to take place
o Focuses on what the system has to do
o Helps in understanding function and behavior to make implementation easier
o Helps determine completeness, consistency, and accuracy
o Basically a mapped representation
 Partitioning
o A project as a whole is usually very complicated and takes many steps
o Breaking down the problem to smaller pieces will make the problem easier,
because doing small increments won't be as complex
Formal Technical Reviews
 Preparation for the product is essential
 Reviews might include error detection, inspection, a walk through, and other assessments
 Doing this is a good learning tool for those who are not that familiar with planning and
design
 Meetings are important
 Usually during meetings, updates are brought up. Members show their assigned
completed tasks
 The next steps might be presented, along with possible changes
 Another factor is duration of the meeting
 If a meeting is too short, important announcements might be missed
 If a meeting is too long, time will be wasted that could be used to work
 When a meeting's about to close, and if decisions are made about a project, attendants of
that meeting sign off to indicate that they agree to it and are responsible
 If participants don't accomplish what needs to be accomplished, they are then held
responsible
Software Testing
 A product isn't deliverable if it doesn't do what you want it to do 100% of the time
 A few of the ways to test
o The college way: When you compile a program, put in values that you know
should work to make sure you get the right result
o The business way: Break it! Purposely try and come up with solutions that should
fail. Then you can work from there to fix the errors so eventually you can't
purposely break the program
 More than just when the software is completed. It should start early in the project
 About 30% of the project involves testing
Control of Change
 There will certainly be change some time during a project. Things will come up that are
unavoidable.
 The goal is to minimize change
 Before a change is to be made, make sure it is necessary
 If a change is to occur, there will probably be a cost whether it's time, money, or both
 Changes should be analyzed, reported, and recorded
Measurement
 Measurements are never perfect
 They are based on estimates and prior knowledge and experience
 Tasks are measured by time spent and completeness
 Measurements turn opinions into facts
 Data is gathered and processed. Through measured analysis, there's:
o Characterization:
 Gain understanding of process
o Evaluation:
 Determine the status with respect to the plans
o Prediction:
 Through understanding and information, attributes can be predicted
o Improvement:
 Fixing errors, getting through obstacles, and inefficiencies

Record Keeping
 Each element of a project needs to be recorded
 Everything from diagrams, to outlines, to code, changes, and other elements need to be
written down to document what has been done, and what needs to be done.
 When members of a group are assigned tasks, they are recorded so they know what they
are responsible for and are held accountable for those tasks

Report
 Going along with recording is the concept of reporting
o A report is generated from the information that is gathered from the meetings
o Some of the information that might be in the report includes:
 What was reviewed?
 Who reviewed it?
 What were the findings?
 Conclusions?

6.2 Change management and control


Introduction
The Change Management Plan was created for the CIS375: On-Line Auction System (OAS)
team, A New Hope, in order to set expectations on how the approach to changes will be
managed, what defines a change, the purpose and role of the change control board, and the
overall change management process. All stakeholders will be expected to submit or request
changes to the OAS Project in accordance with this Change Management Plan and all requests
and submissions will follow the process detailed herein.

Change Management Approach


The Change Management approach for the OAS will ensure that all proposed changes are
defined, reviewed, and agreed upon so they can be properly implemented and communicated to
all stakeholders. This approach will also ensure that only changes within the scope of this project
are approved and implemented.

The Change Management approach is not to be confused with the Change Management Process
which will be detailed later in this plan. The Change Management approach consists of three
areas:
 Ensure changes are within scope and beneficial to the project
 Determine how the change will be implemented
 Manage the change as it is implemented
The Change Management process has been designed to make sure this approach is followed for
all changes. By using this approach methodology, the OAS project team will prevent
unnecessary change from occurring and focus its resources only on beneficial changes within the
project scope.

Definitions of Change

There are several types of changes which may be requested and considered for the OAS project.
Depending on the extent and type of proposed changes, changes to the project documentation
and the communication of these changes will be required to include any approved changes into
the project plan and ensure all stakeholders are notified. Types of changes include:

 Scheduling Changes: changes which will impact the approved project schedule. These
changes may require fast tracking, crashing, or re-baselining the schedule depending on
the significance of the impact.
 Scope Changes: changes which are necessary and impact the project’s scope which may
be the result of unforeseen requirements which were not initially planned for. These
changes may also impact the schedule. These changes may require revision to project
scope statement, and other project documentation as necessary.

The project manager must ensure that any approved changes are communicated to the project
stakeholders. Additionally, as changes are approved, the project manager must ensure that the
changes are captured in the project documentation where necessary. These document updates
must then be communicated to the project team and stakeholders as well.

Change Control Board

The Change Control Board (CCB) is the approval authority for all proposed change requests
pertaining to the OAS Project. The purpose of the CCB is to review all change requests,
determine their impacts on the project risk, scope, cost, and schedule, and to approve or deny
each change request. The following chart provides a list of the CCB members for the IS Project:

Name Position CCB Role

J. Battaglia Project Sponsor CCB Chair

A. Voszatka Project Manager CCB Member

J. Major Project Team Member CCB Member


K. Urena Project Team Member CCB Member

As change requests are submitted to the OAS Project Manager by the project team/stakeholders,
the Project Manager will log the requests in the change log and the CCB will convene every
Thursday to review all change requests. For a change request to be approved, all CCB members
must vote in favor. In the event more information is needed for a particular change request, the
request will be deferred and sent back to the requestor for more information or clarification. If a
change is deemed critical, an ad hoc CCB meeting can be called in order to review the change
prior to the next scheduled weekly CCB meeting.

Roles and Responsibilities

The following are the roles and responsibilities for all change management efforts related to the
OAS Project:

Project Sponsor:
 Approve all changes to budget/funding allocations
 Approve all changes to schedule baseline
 Approve any changes in project scope
 Chair the CCB

Project Manager:
 Receive and log all change requests from project stakeholders
 Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB
 Seek clarification from change requesters on any open issues or concerns
 Make documentation revisions/edits as necessary for all approved changes
 Participate on CCB

Project Team/Stakeholders:
 Submit all change requests on standard organizational change request forms
 Provide all applicable information and detail on change request forms
 Be prepared to address questions regarding any submitted change requests
 Provide feedback as necessary on impact of proposed changes

Change Control Process


The Change Control Process for the OAS Project will follow the organizational standard change
process for all projects. The project manager has overall responsibility for executing the change
management process for each change request.

1. Identify the need for a change (Stakeholders) – Change requester will submit a completed
change request form to the project manager.
2. Log change in the change request register (Project Manager) – The project manager will
keep a log of all submitted change requests throughout the project’s lifecycle.
3. Evaluate the change (Project Manager, Team, Requester) – The project manager will
conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and
scope and seek clarification from team members and the change requester.
4. Submit change request to CCB (Project Manager) – The project manager will submit the
change request, as well as the preliminary analysis, to the CCB for review.
5. Obtain Decision on change request (CCB) – The CCB will discuss the proposed change
and decide whether or not it will be approved based on all submitted information.
6. Implement change (Project Manager) – If a change is approved by the CCB, the project
manager will update and re-baseline project documentation as necessary.

Sponsor Acceptance

Date:
7.0 Appendix
Customer Requirements:

You might also like