Professional Documents
Culture Documents
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
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
item
A collection of operations will take place after each auction. Such as declaring the
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
Bidder:
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)
Time Constraints:
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
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 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.
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.
Only one estimation was made based on past historical data and educated guesses.
2.3 Estimates
Design 1
Implementation 3
Testing 1
Seller:
Post Item to sell with title/description/ Starting Price/End date
Design 1
Implementation 15
Testing 5
Design 0.5
Implementation 3
Testing 1
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
Design 1
Implementation 2
Testing 1
Bid Payment/Result
Design 1
Implementation 4
Testing 2
ADDITIONAL FUNCTIONALITY
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
Design 1
Implementation 4
Testing 2
Kenny’s Total: 16
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
Design 1
Implementation 2
Testing 1
Design 1
Implementation 4
Testing 1
Message Boards
Design 1
Implementation 3
Testing 2
Design 0.5
Implementation 2
Testing 1
Design 0.5
Implementation 2
Testing 1
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
Design 0
Implementation 1
Testing 0.5
Josh’s Total: 15
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 Business Analyst-John
o Software Architect-Kenny
o Designer-Andrew
o Software Developer-Andrew
o Software Tester-Josh
Required Software
o Microsoft Windows OS
o Dropbox
o Skype
o Google Docs
o DirectX 9-capable video card running at 1024 x 768 or higher display resolution
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.
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.
Personal Conflict: If a personal conflict between two or more team members occurred,
which might prove disruptive to the group and hurt our progress.
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
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.
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.
Process Model
3. Language: C+
Tasks to be accomplished
Items to sell
Details about item: Title, Description, Starting price, ending date, total dollar amount,
total unsold, items with no bids
Number of items
Number in-progress
Number winning
Searching mechanism
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%)
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.
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,
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
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
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?
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.
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:
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.
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
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: