SWE 6623 Projects (Semester long) 90 points
Project Description:
1. A) “Expand on,” “invent,” and specify the requirements for
a “Financial Control Package” (which is briefly described
below).
a.
consider the functions needed
b.
consider UI desired
c.
consider all the data related to this system
d.
assume web-based* -- if not explain why not
e.
describe the usage flow, as you see it.
( Note that : 1 (A) to be turned in by each person separately --and graded separately ---- 20 points)
Due Date is : 9/20/2012 (8:45PM)--- late paper will have a 10%
deduction. No paper accepted after 9/25/2012(8:45PM) ---- online students included. (on-line students: send the material in as
“e-mail attachment” --- in class students: give me the “paper”
version)
_____________________ ____ _________
-----------------------------------------------------------------------------(All the remaining assignments are to be performed in teams ;
have teams “set” by 10/09/2012 and give me the “contact info”)
1. B) Rewrite & Provide your team-requirements document to
another team for “review/solicitation/negotiation” (on
10/16/2012). Make sure the following sections are present:
i)
list of major functionalities (e.g. create/modify/delete
plan; input status data; query for intermediate status,
etc.)
ii) UI looks and navigation (at least one sample and the
navigation paths of all the screens)
iii)
iv)
v)
Data/information descriptions of major information
(e.g. person hours; project name; etc.)
Usage/business Flow (from the user perspective may
also usage UML
Non-functional needs such as “role-based” security,
query-response performance speed, etc.
Due date for items “reviewed” (team requirements document)
is 10/23/2012- (each team return the reviewed document to
owner team with a copy to me; I will grade how well the
requirements document was “reviewed” --- 15 points)
1. C) Perform an in-class requirements specification
“negotiation/review” (10/25/2012--- req. spec owner team
with review team --- 20 minutes each) of the requirements
and the requirements analysis that went into it. Record all
the changes and suggestions from the negotiation/review.
(* Include the requirements review results
(changes/fixes/clarifications) in your final presentation as part of
“quality analysis” with test results)
2. Design the system from the “negotiated/reviewed”
requirements document .
Due date for item 2 (Design Document) is 11/6/2012 (15
points)
3. Generate the test cases for the system (Test Case document)
11/8/2012 ( 15 points).
4. Perform internal reviews of the design and test cases
Perform this at your teams’ convenience and keep records of
the review by types of problems found and severity of problems
found. (Include the review results in your final presentation with
prototype)
5. a) Develop the prototype of the design and run test cases for
the prototype.
(this prototype will be demonstrated in class with your
major test cases)
b) Write up & present the experience (power point),
discussing several of the project and quality related topics .
a.
amount of effort – person months planned vs
spent
b.
amount of functionalities initially planned versus
implemented
c.
what was the most difficult item in this project
d.
how would you describe the process your team
used
e.
what was the team dynamics
f.
product quality assessment – (1) # of
review/negotiated/changed items and # resolved;
(2) # of test problems found by type/severity and #
resolved. How would you “characterize” the
quality of your product before and after the
review/negotiation/change (based on error found
and rework time spent.)?
Recommended finish date is 11/16/2012 ---You do not need to
present & demo the system until 11/27/2012 or 11/29/2012 (team
will draw for the exact date) ---(25 points). You must also turn in
your power point presentation-slides on 11/27/2012(class period).
Team Make-up :
You will need to form a team of about 4-5 people per team for this
project.
Brief Description of the Problem:
(i)
(ii)
for the individual assignment(1A) do some “researches” on
existing products and make some assumptions on
the unknowns, but must explicitly document them;
for the team assignment(1B) re-do the requirements and
negotiate/review by other team.
Requirements:
Basic requirements for Financial Control of Software Project package are:
1. The package must allow the initial plan-information about the software project to be put in.
[e.g. information such as i) what are the different resources to be used; ii) what is the cost
of each of these resource; iii) how long are these resources needed; iv) when does the
project start and end, etc.]
(You are to come up with the details such as whether you want to place a limit to the number of types of
resources your package will accept; should cost always be in dollars/other currencies and should different
people cost be input into the system by person-hours and dollars per person-hour ; project schedule and
people assignment time; etc.)
2. The package will allow the tracking of the project cost. It should allow one default (weekly
or monthly or daily) tracking or allow the user to decide at product initialization time what
the timing should be. (You are to come up with the details of what needs to be inputted
before the tracking can become meaningful.)
3. The package will, at the request of the user, be able to aggregate a project “actual” subtotal costs and “up-to-date actual”grand total cost and compare against the planned costs -- (You are to decide how cost aggregation is to be done and how to show it --- e.g.
variations of aggregate cost by designers, by testers, by laptops bought, percentage of
total, etc.)
4. Project cost “status” should be presented in graphical form (e.g. bar chart, pie chart, line
chart, etc.) so that managers can read it easier ---- like a car dashboard.
5. Other decisions such as --- how many different projects can your package handle; desk top
or web-based; performance speed; amount of security control; etc. is up to you --- but you
must explicitly specify these in the requirements.
Example of Requirements Review/Negotiation/Change Logistics (zz/vv/2012):
Team A : give the req. doc to Team B for review
Team B : give the req. doc to Team C for review
Team C : give the req. doc to Team A for review
Teams return the “reviewed” requirement documents to respective owners, with a
copy to me (xx/yy/2012)
Requirements Negotiate/Review/Change Logistics (in class kk/jj/2012):
Team A : negotiate/change review with Team B to finalize requirements.
Team B : negotiate/change review with Team C to finalize requirements..
Team C : negotiate/change review with Team A to finalize requirements. .
Team formation considerations:
1. person’s expertise (code/design/test/documentation)
2. person’s past experiences (with team projects in “cs/swe” field)
3. person’s work habit (detailed, speed, responsible, etc.)
4. person’s real situation (working/class load; family load; etc.)
5. person’s goal (pass, be the best, coast along)
Class Contact List: