Software Development Project
Spring Semester, 2011
DUE Thursday, January 27, 2011 at 11:30 am

Phase 1 - Project Proposal, Recommendation, and Team Capabilities

In this phase, your team will propose and evaluate two potential projects for development this term.  You will recommend one of your potential projects for further development as your team's term project. You will also describe your team's capabilities and upcoming responsibilities. The organization, ideas, and software project vision statements and analyses that you present at this stage are your statement of what your team wishes to achieve, and can achieve this term.

Your work in this phase will set the stage for the entire group's effort and likely success this term. This phase is therefore a crucial and essential step in the process; doing it carefully, thoughtfully, and well increases your likelihood of a satisfying and rewarding experience this term.

The project report must contain the following sections. Weights for credit are shown in parentheses.  Your work must be complete, correct, convincing and in conformance with the instructions and guidelines given in the Phase Report Format and Professionalism section of the class syllabus. 

1. Executive summary (described in class syllabus).

2. Proposed Project Vision, Overview Statement, Project Feasibility (70% total; 35% for each proposed system; complete this section twice – once for each proposed system)

Identify at least two potential software development projects for your team to work on this term. These projects should be "realistic" but not necessarily "real." In other words, do not propose the development of a solution for a specific organization, business, or enterprise. While your project proposals may be motivated by your job or your relationship with an organization or a business, you must not commit to working with a real client. You must not promise any client, organization or business any kind of tangible deliverables resulting from your team's work this term. (We require two proposals as a safety measure for the team's benefit.)

There are many project possibilities for you to choose from.  Be creative - choose something that's of real interest to the team members - you will have to live with it all term. Consider the following as sample ideas, but you are not restricted to these suggestions:
• A web based reservation system.
• An interesting e-business system of your choice.
• An application that effectively demonstrates an interesting technology such as iPhone, Android, geolocation, etc.
• Novel contribution to an open source system.

For each of the two systems you propose, complete the following tasks and CLEARLY
LABEL the distinct sections in your phase report.  Except as noted below, do not commingle materials for the two proposed projects; all materials for proposed Project A should precede all materials for proposed Project B.  Any common material applying to both projects should be so labeled.

A. VISION STATEMENT (20%; 10% each)
Write a brief vision statement describing the system you propose to develop. You must make it exceptionally clear to your readers what you are proposing to do.  Address the following points, as appropriate. Add any additional commentary or analysis that will clarify the objectives, purpose, or scope of your proposed system.

What is it? Why is it of interest to the team?
What problem, opportunity, need or directive does it satisfy?
Who exactly are, or would be, the stakeholders and users? Note that the stakeholders may include managers, business owners, domain experts, developers, or executives, as well as the ultimate end users or customers.
How would your system be useful, of value, or of benefit, to its users or stakeholders?

To support your analysis, interview at least two potential, or real, stakeholders who might have an interest in your project idea and who actually have something useful to say. Describe the structure of the interview and provide detailed summaries of these interviews. Make your interviews worthwhile. Do not use your interviews merely to show support for your idea; use them also to reveal potential stakeholder concerns or problems with your idea. From the stakeholder's viewpoint, what could go wrong? Shallow interviews that demonstrate only unqualified support for your idea are generally useless.

B. USE CASES (25%; 12 ½% each)
Create a set of use case diagrams (show actors, processes, system boundaries) for the system you propose. Be sure to include essential administrative functions in your diagram. 

Write a brief narrative for each use case explaining the use case (level of detail as required by faculty advisor). Indicate the use case's priority level (A, B, C - explained below). Briefly describe all actors (users, systems, or organizations) who interact with your system, as indicated in your diagram. Do not assume that the meaning of any use case, actor, or function is obvious to your readers; your descriptions must be very clear and unambiguous. Do not forget about administrative use cases.
Note: Each use case must be assigned a priority:
A - Use case is essential for system operation.
B - Use case is not essential for system operation but would add significant value to the system's users or stakeholders.
C - Use case would add some small, but real or perceived value to the system's users
or stakeholders.

C. SCOPE, COMPLEXITY AND PROJECT SIZING (22%; 11% each)
Assess the scope and complexity of your proposed system and estimate the work involved. Present your analysis in meaningful terms that informed stakeholders (and
instructors) can clearly understand. Clearly articulate and justify any non-obvious or non-trivial assumptions you have made in your estimates. To complete this section, you will need, at a minimum, to do the following:

1. Estimate the remaining work/effort required, in person-hours, to complete the analysis and design phases of your system. Refer to upcoming phases for required activities in these phases. Clearly explain how your estimate is derived.

2. Estimate the work/effort required in the construction and implementation phases of your system. To do so, estimate use case points for the A and B level use cases you identified above (create separate estimates for the A level use cases and the B level use cases). Use this information to estimate the total effort required (for instance, LOC, person weeks, calendar weeks, etc.) to complete the A and B level use cases. Clearly explain how your estimate is derived.

3. Explicitly estimate the overhead required for project management, meetings, writing and reviewing reports and documentation, code and design reviews, integration and system level testing, learning and developing skills in new technologies/languages, original invention or discovery, QA activities and other process or process management issues that are relevant to your project or your team. (Analysis may apply to both projects if similar in complexity).

4. Estimate the amount of available effort to be lost due to midterm examinations, carnival, spring break, job interview visits, long weekends, holidays, spring fever, outside commitments, etc. This is time when a team member will be unable to complete a typical week’s worth of work (usually 15-20 hours).  All such lost time should be factored into your project scope and plans. (Analysis may apply to both projects).

5. Based on your estimates of the above, indicate exactly which use cases your team will attempt to implement this term and give a final estimate of total work/effort/calendar time involved to do so.  Indicate the minimum number of hours per week per team member that will be needed to complete the project.  Clearly highlight your conclusions and explain your reasoning where it is not obvious.  Do not simply include use case point worksheets or other difficult to interpret collections of numbers or calculations.

It is expected that your team will implement all A level use cases and as many B level use cases as your resources permit. A reasonably estimated plan would account for approximately 10-12 hours per week commitment per student. (No extra credit is awarded to a team for scoping a project that is too ambitious, too difficult, or too large to complete successfully during the term. Heroic efforts late in the semester to salvage an underestimated project, while commendable, may actually result in diminished grades as quality is almost always sacrificed in the frantic effort to complete a late project on time.)

D. FEASIBILITY ASSESSMENT AND SYSTEM DIFFICULTY (3%; 1½% each)
Given the above discussion, assess the feasibility and likelihood of your team's capability to successfully develop your proposed system this term. Can the team realistically complete the proposed project during this term?  Is the proposed project likely to be a successfully deployed in the 'real world'?  Consider, as appropriate, the risks, complexity and anticipated difficulty of your proposed project and any additional relevant economic, technical, personnel, scheduling and operational factors not already highlighted.  Your feasibility analysis must be realistic, specific to your proposal, and convincing. Define and justify any criteria whose interpretation would not be obvious to your readers. Your conclusions must be clearly stated.

Propose and justify a System Difficulty Level rating from 0 to 1. Phases 3, 4, and 5 and the final system evaluation will be weighted by the System Difficulty Level. If your System Difficulty Level is not 1.0, you should change your proposal to bring the total difficulty up to 1.0.

E. RECOMMENDATION
Finally, recommend one of your two proposed systems for implementation as your team's term project. Provide justification for your recommendation based on your analysis in part 2. If your recommendation is accepted by your instructors, your recommended project will advance to the next phases. The alternative proposed system will be dropped from further consideration and further development.

3. Team Structure and Capabilities (10%)
Include a skills inventory (available on-line) for each member of the team and describe how each team member can best contribute to the team's efforts. Discuss any potential
constraints, limitations, and any issues relevant to team member availability, skill level and participation. (Note: Students who have overloaded schedules, substantial employment, or other time consuming commitments pose a risk to the team. Identify all such cases and discuss the realistic commitment you may expect from each team member.)  Discuss any skills your team will need that it does not currently have. Indicate who will develop these skills, how, and when the skills will be developed.  (Be sure to include time to learn new technologies, platforms, languages, etc. into your project plan.)  Identify the team's Project Manager and Quality Assurance Manager.

A note about the "Project Manager" role: While nobody on your team is "the boss," a special management role is needed to coordinate, plan, and track the team's work. The
Project Manager acts to keep the team focused and makes sure that the work gets done. Your team must switch to a new Project Manager during Phase 3.

A note about the "Quality Assurance Manager" role: Everyone on the team must assume responsibility for the quality of all work products the team produces. The Quality
Assurance Manager is responsible for implementing quality controls and quality processes that reflect the team's best efforts. The QA Manager is responsible for assuring the team's work products for timely completion, thoroughness, errors, omissions, as well as the quality of preparation and presentation. No work product that is submitted for grading should ever be turned in without a thorough review by the QA Manager, or other team members working with, or designated by, the QA manager. The QA Manager must work closely with all team members to monitor the team's workings and to ensure that the team's processes, communications, and meetings are effective and efficient. The QA Manager will take charge of collecting, reporting and analyzing project metrics. The QA manager is responsible to see that code reviews and design walkthroughs are conducted and that test plans exist and that all software developed by the team is thoroughly tested and documented.

Include a copy of your completed Team Charter (available on-line).

4. Project Management Section (20%)
a. Time Accounting (3%)
Time accounting is needed to keep track of (and understand) how team members are spending their time on the project. Time accounting is an important software project management tool and helps to promote individual accountability on student software development teams. Complete and accurate records allow you to compare actual versus planned commitment and to lay the foundation for better estimation and planning on future phases and future projects.

Summarize (graph) the weekly time commitment (expected/planned and actual) for each team member and for the team as a whole. Break down time spent on each of the major activities; explain unusual or unexpected findings. Briefly (and realistically) describe each person's contributions to the team's work during this phase.

b. Task Analysis (4%)
For your recommended project, identify all tasks that must be completed for all upcoming phases and create a task list/check list for each phase. (See upcoming phase requirements). Decompose your work into meaningful, measurable tasks, which can be designated as either complete or incomplete. Your tasks should be sufficiently granular so that your team can realistically track and report on each task's progress. (This will be a valuable project management tool if you do it well, and pretty much useless if you don't). Describe any tasks that will not be immediately obvious to the readers of your report. Be realistic about defining tasks -- assigning all your effort to one large task such as "Problem Analysis" is not realistic, nor is fragmenting your tasks into too many subtasks. Include all tasks related to software development - design, programming, testing, QA, etc. Also, be sure to include all tasks related to learning new technologies, server administration, new languages and the like. You need to plan for these items early so that you have the skilled people in place when you need them.

For each task to be completed during Phase 2, indicate the expected person hours to complete the task and give a realistic expected completion date. Identify which team member(s) will perform each task or lead the performance of each task during the next phase. Referring to your skills inventory, briefly justify any role choices which are not obvious fits with the individual's stated, or demonstrated, skills.  It is good management practice, permissible (and quite likely) for your project team roles to shift as the semester progresses.

Your overall estimate of total time for the project and the sum of the hours on the individual tasks identified above may not be exactly equal, but should approximate each other.

c. Project Metrics (3%)
Suggest a reasonable set of software metrics (things you can measure) your team will/should employ throughout the term to measure your team's progress, productivity and effectiveness. Identify metrics that are likely to have significant value to the team during the semester. For each metric you identify, indicate how the team will collect it, record it, and how the team might use it for decision making or improved process management. The metrics you gather are for the team's benefit so make them useful. At a minimum, your set of metrics should include measures of product quality (defects and defect rates), project status/progress (size and effort estimates versus actual), process quality (amount of rework, checkpoints or deadlines made and missed). Add or modify these suggested measures as appropriate to your team's efforts.

d. Cost of Quality Analysis (3%)
Cost of Quality includes all activities required to prevent, detect, or remove defects. Prevention costs accrue when you examine and modify your process to avoid creating defects in requirements, design, implementation or documentation. Detection costs include reviews of requirements, design, code, and documentation, and testing of system components. Removal includes all activity needed to fix or rework any defects in requirements, design, code and documentation. Keep careful records. Note: Typical COQ for student software team projects ranges from 25%-50% of total effort.

e. Risk Analysis (4%)
Create a "Top 5 [or more]" Risk List for your recommended project. These risks are the most serious threats to your recommended project. Your risk list should be realistic, specific, clearly applicable and adapted to your recommended project. You must make it clear why each risk applies to your project; simply creating a list of generic risks is not acceptable. For each risk, provide a description, a likelihood of occurrence (low, medium, high), magnitude of potential loss (low, medium, high), symptoms of early warning, and an appropriate risk abatement strategy. Your risk management plan must be specific, useful, and realistic.

f. Problem Analysis and Issues (3%)
Identify and discuss any significant problem(s) that your team has encountered (quality, technical, organizational, team members, environmental, etc.) in completing this phase of the project, or that may, in any way, affect the successful completion of your term project. Indicate which of these problems remain open or have been resolved with their resolution. Identify any potential problems you anticipate before completion of the next phase(s) of the project.

Last Updated 01/01/2011 [rsw]