Project Project Overview Overview

SpecificationSpecificationSimplexity Software

Ian Cook, Mitch Heer, James Lorenz, Tom Navarro, Levi Stanley

Why?Why?• Communication Tool

• Shows customer we understand his business/needs

• Tells customer how we plan to meet those needs

SectionsSections• Introduction• Project Sponsor and Sponsor Need• Method for Satisfying the Sponsor's Need• Technical Proposal• Management Proposal• Conditions and Comments• Approvals• Appendices

Section 1: Section 1: IntroductionIntroduction

• Introduces the reader to the contents of the POS• States what the POS is, the project, project

sponsor, brief description of senior project• After initial summary, follow with information

about sponsor/development team in this format:o PROJECT SPONSOR:

• Contact Person’s Name• Contact Person’s Title• Company/Organization name• Contact Information (phone number and Email address)

• Following sections are to be done after finishing the whole POS, as it will summarize the POS’s contents.

1.1 Purpose1.1 Purpose• Why is this POS being written?

• What is being communicated to the reader?

• What reader should expect and learn

• This should create a mutual understanding between team and sponsor about how project will go

1.2 Scope1.2 Scope• What is/isn’t being covered

• POS isn’t omniscient

1.3 Definitions, 1.3 Definitions, Acronyms, Acronyms,

AbbreviationsAbbreviations• Terms used by sponsor/user community as well

as technical terms

• All terms should be alphabetized

• Will provide reader with quick access to terms to be used in POS

1.3.1 Definitions1.3.1 Definitions• Baseline (paraphrased): work product formally

reviewed and accepted by both parties

• Software Requirements Specification (paraphrased): document of essential requirements of software and its external interfaces

• Protocol (paraphrased): conventions that govern interactions of components of system

• Task: The smallest unit of work subject to management accountability.

1.3.2 Acronyms1.3.2 Acronyms• ASP. Active Server Pages (would require a

definition)

• SSP. Software System Proposal (would not require a definition)

• XML. Extensible Markup Language (would require a definition)

• NOTE: use appropriate symbol when referencing trademarked (® or ™) or copyrighted (©)

1.3.3 Abbreviations1.3.3 Abbreviations• Include definitions for terms not commonly

understood

• MGT: Management

• LRN: Learning

1.4 References1.4 References• A bibliography of documents used in preparation

of the POS

• Indicate in POS with in-text citation when using other documents

• Use MLA format for citing sources, example of MLA citations:

• http://www.library.cornell.edu/newhelp/res_strategy/citing/mla.html

1.5 Overview of 1.5 Overview of ContentsContents

• Briefly describes following sections and appendices

• Each following section will have subsection, which can use identical words as given in this section for introduction

Section 2: Project Section 2: Project Sponsor and Sponsor Sponsor and Sponsor

NeedNeed• Defines the sponsor’s business and describes the

value your software will provide.

• This section will gauge how well you understand your sponsors business, and will reflect upon how your team views your sponsor.

• You need to meet with your sponsor at least once before filling out this section.

2.1 Sponsor 2.1 Sponsor IdentificationIdentification

• Use this space to identify your sponsor (as a person).

• Identify the sponsor’s complete “organization name” o Position, company, division, department name, etc.o Do the same for anyone else working with you on this project.

2.2 Sponsor’s Business2.2 Sponsor’s Business• Describe your understanding of the sponsor’s

business, includingo How it is organizedo How it provides goods and services

• This section will demonstrate to your sponsor that you understand their need(s) and the context in which they operate.o Failing to properly describe your sponsor’s business will reflect very

poorly on your team.

2.3 Description of 2.3 Description of NeedNeed

• Describe what the project should accomplish and whatever constraints the sponsor wishes to impose.o Target OS, DB type, etc.

• Fill in subsections that define the project’s success criteria, the project’s value to your sponsor (and the reason for its proposal), and the goals your team hopes to accomplish.

• Demonstrate to the sponsor that you have sufficient knowledge of their problems/needs and the context in which they exist.

2.3.1 Vision2.3.1 Vision• Describe the sponsor’s primary reason(s) for

proposing this project.

• Describe the value your software will provide for the sponsor.

• Make this section convincing and motivational.

2.3.2 Goals2.3.2 Goals• Define some goals your team hopes to

accomplish by undertaking this project.

• Goals are not necessarily related to sponsor needs.o “Success” may or may not have anything to do with the delivered

product.

2.3.3 Success Criteria2.3.3 Success Criteria• State what the sponsor hopes to be able to do

with your software. o This section can be generalized into a statement of the product’s key

features and capabilities. o However, the more information you draw personally from your sponsor,

the better. o Not a feature list!

Section 3: Method For Section 3: Method For Satisfying The Satisfying The

Sponsor’s NeedSponsor’s Need• Identifies method for meeting sponsor’s need• Team/sponsor should have clear, unified project vision• High-level understanding of sponsor goals, user

environment, target platforms, “business” features in software

• Will provide a starting point for gathering requirements for SRS as understanding is reached regarding features

• Detailed functional specs of these features will be in SRS

Section 4: Technical Section 4: Technical ProposalProposal

• This section provides a high level description of the technical aspects of the proposed software.

4.1 Technical 4.1 Technical Description of ProjectDescription of Project

• How is the product going to meet customers' needs?

• How will users interact with the system?

• Convince sponsor this product will meet his needs

4.2 Deliverables4.2 Deliverables• Everything the customer gets

o Software (obviously)o Source Code?o Documentation?o Automated Tests?o Training?

Section 5: Section 5: Management ProposalManagement Proposal• A general description of how the project team

intends to manage the project.

5.1 Work Schedule5.1 Work Schedule• Identify each of the phases of the project

development life cycle.o POS, PMP, Req Prototypes, SRS, 191 phases, etc…

• Briefly describe the work associated with each of the phases.o Include procedures for quality control (i.e. technical reviews, adviser

reviews/approvals, etc.).

• Include estimated start and completion dates for each phase.

5.2 Resource 5.2 Resource ManagementManagement

• Specify the estimated person-hours and support resources needed.o E.g., copying costs, supplies, etc.

5.3 Cost5.3 Cost• Specify costs for the above resources.

• Senior projects should have no expected costs to the sponsor, except time.

• This section is included to simulate a real world project.

5.4 Organization and 5.4 Organization and StaffStaff

• Identify the members of the project team and the roles that they will perform.o Project Managers (190 and 191)o Software Engineerso Other Specific Roles (if needed)o Faculty Advisor

Section 6: Conditions Section 6: Conditions and Assumptionsand Assumptions

• This section will allow you to define any conditions, limitations, or assumptions your team or sponsor wishes to impose.

6.1 Assumptions and 6.1 Assumptions and ConstraintsConstraints

• Which factors limit project?• Sponsor constraints?• Team assumptions?• Compatibility?• Additional Documentation?• External activities/interruptions?• Necessary hardware/software

6.2 Limiting 6.2 Limiting ConditionsConditions

• What specifically is going to be included in the software and what is not?

• What constitutes a successfully complete project?• Time commitments and availability of sponsor.

6.2.1 Academic 6.2.1 Academic FactorsFactors

• Goalso To develop and deliver a software system to the benefit of a real

customer/user.o To provide the senior project team with a learning experience in which

software engineering principles are applied to the development of a real-world software system.

• General disclaimero "All students majoring in CSC..."o Students cannot be paid due to academic nature of project.

6.2.1 Academic 6.2.1 Academic FactorsFactors

• Support limitationso Not obligated to support software after completion

• Ownership of producto Team members share ownership with sponsor (unless the sponsor

requires clear legal title)o Computer Science Department reserves the right to use the

documentation and product as examples

6.2.2 Other 6.2.2 Other DisclaimersDisclaimers

Section 7: ApprovalsSection 7: Approvals• This section will contain a sign-off sheet used to

indicate approval of / agreement to the terms and responsibilities outlined in this document.

• Requires the signatures of your sponsor, each team member, and your faculty advisor.

• Be sure to include the name, full title, and full name of the parent company for each signatory.

Section 7: ApprovalsSection 7: Approvals• Be sure to include room for multiple sets of

signatures and dates.

• By signing this sheet, the proposal becomes a de facto contract between the team and the sponsor!

Appendix A: Project Appendix A: Project Team ExperienceTeam Experience

• Why would the customer want you?o Resumeso Brief bios?

Appendix B: Appendix B: Partnership Between Partnership Between

Team/SponsorTeam/Sponsor• Expectation statements

o The sponsor can expect the team to...• Speak in the sponsor's language• Explain the project process• Etc.

o The sponsor is expected to...• Meet regularly with the project team• Sign documents• Etc.

o Good examples in the Guide

Appendix C: Phases of Appendix C: Phases of WorkWork

• Charts of work phases

ApprovalsApprovals

Hours EstimatesHours Estimates

Gantt ChartGantt Chart

For More InformationFor More Information• See Buckley’s Website for the guide

o http://ecs.csus.edu/~buckley/CSc190/POS.pdf