Software System Proposal



The formatting of each of the team’s final documents should correspond to the formatting used in each of the documents prepared by the team!. Font: Times Roman; Font Size: 12pt is the standard for each document. Note: the boxed-in comments below are the guidelines for preparing the Project Charter document and should not be included in the team’s final delivered document.Guide to Preparing thePROJECT CHARTER? R. BuckleyCSc 190 Senior ProjectDepartment of Computer Science - College of Engineering and Computer ScienceCalifornia State University, SacramentoVersion 3-21-2019FRONT PAGEAll CSc 190 and CSc 191 documents must have the same Front Page design and format … but also include the Project name and the Team name<Client’s name for the Project>PROJECT CHARTER DOCUMENTPrepared by Senior Project Team<team name>College of Engineering and Computer ScienceDepartment of Computer ScienceDate: xx/xx/xxxxTABLE OF CONTENTSPageINTRODUCTION 3Purpose 3Overview 4PROJECT PRODUCT OWNER AND PRODUCT OWNER NEED42.1 Product Owner Identification42.2 Product Owner’s “Business”52.3 Description of Need52.4 Assumptions and Constraints52.5 Limiting Conditions53.0 ACADEMIC NATURE OF THE PROJECT63.1 Goals63.2 General Disclaimer63.3 Support Limitations63.4 Other Disclaimers74.0 PRODUCT OWNER AND THE <team name> TEAM APPROVALS64.1 <Document Name> Approvals8APPENDIX A. Project Team Experience9APPENDIX B. Rights and Responsibilities of both the team and the Product Owner91.0 INTRODUCTIONThis section serves as the Executive Summary for the document. It introduces the Product Owner to the contents of document. What follows is wording that can be used in this section.This is the Project Charter document for the < name of the project > project for < name of Product Owner and the Product Owner’s business or organization >. This project is being undertaken by the < name of team > development team. The team is comprised of undergraduate students majoring in Computer Science at California State University, Sacramento. The team members are enrolled in a two-semester senior project course required of all undergraduate majors. Successful delivery of the desired software product will fulfill the senior project requirement for the student team members. Include identification of the project Product Owner and the team as follows:PROJECT PRODUCT OWNER (Note: If there is more than one person serving as Product Owner, list each Product Owner):Name:Title:Company or Organization name:Contact information:(phone number and Email address)<Name of Team> DEVELOPMENT TEAMList of team member names including contact information (phone number and Email address)The remaining subsections are intended to introduce the Product Owner to the document and to serve as a high-level summary of its contents. Purpose. This subsection should describe the purpose of this document. Explain why this document is being written, what it is intended to communicate, and what the reader should expect, in general, to learn. The purpose statement should capture the intent associated with the contents of the document. In the case of this document, your intent is to create a mutual understanding between the team and the Product Owner of what is expected over the course of the project. This subsection should also summarize what specifically is to be covered by the document and what is not. Included should be a statement which describes in general and non-technical terms the value the Product Owner expects to be provided by software. However, the contents of this document should not be interpreted as containing a set of agreed upon requirements. 1.2 Overview of Contents of Document. This subsection names and list and briefly describes each of the remaining sections (those indicated in caps) in the document as well as the contents of each appendix. Section 2.0This subsection identifies the project’s Product Owner and describes the Product Owner's “business”. After reading these subsections the Product Owner should be convinced that the team has an understanding of the Product Owner’s organization and business and therefore the context in which the proposed software is to be used. Section 3.0 This subsection contains a variety of issues that need to be documented because of the quasi-academic nature of the work done by the Senior Project team.Section 4.0This subsection indicates briefly what specifically is being agreed to. A sign-off sheet should be included which indicates approval of an agreement to the conditions and commitments contained in the Project Charter. Appendix AAppendix A Contains resumes which provide information about the qualifications of each member of the development team. All the resumes must have the same format and layout.Appendix B Appendix B contains a statement of the commitment to collaboration between <list of team name and team members> and the <project Product Owner>. 2.0 PROJECT PRODUCT OWNER AND PRODUCT OWNER NEEDThis section identifies the project’s Product Owner and describes the Product Owner's “business” or organization. After reading these subsections the Product Owner should be convinced that the team understands the Product Owner’s organization and business and therefore the context in which the proposed software is to be used. This section also provides the non-technical description of the Product Owner’s reasons for the proposed project and the expected value to be provided. The information included should be elicited in the team's initial meetings with the Product Owner. 2.1 Product Owner Identification. This subsection should clearly identify your senior project Product Owner. Include the complete organization name (for example, company, division and department names) along with the individual names and titles of your primary contact as well as any others representing the Product Owner that you will be involved with during the course of the project.2.2 Product Owner’s “Business”. This subsection should describe the Product Owner’s business. The intent is to demonstrate to the Product Owner that the team has a clear understanding of the Product Owner’s business, how it is organized, and how it goes about providing goods and/or services. Such understanding should provide the team with an understanding of the context in which the proposed software will be used.2.3 Description of the Need. This subsection should include a statement that describes the Product Owner’s vision for the project. This should include a statement of the “value” the Product Owner expects to gain from successful completion and delivery of the software. Your explanation should contain sufficient detail to convince the customer that the project team understands the full nature of the need and the context in which it exists. This is not to be a-technical description and should not be a specific list of features and functionality.2.4 Assumptions and Constraints. This subsection should contain a detailed list of any of the team’s and/or Product Owner’s assumptions and/or constraints. Answers to the following questions may help in fully assessing the nature and extent of any such assumptions and constraints. For example:What factors exist which provide a fixed limit to the project? Clearly, there are time constraints and technical constraints that exist due to the academic nature of the project. Does the Product Owner expect any such constraints? If so, are they consistent with the requirements of senior project?What assumptions are the project team making? Is the Product Owner assuming that the system being developed will be compatible with other systems? Is there an assumption that additional documentation will be required in order for the developed system to be operationally useful? Are there any critical external activities and/or events that must occur during the development process? Will the project team require timely delivery of hardware and/or supporting software in order to ensure the delivery of the software will occur as scheduled? 2.5 Limiting Conditions. This subsection should describe whatever limits the project team is placing on the project and the finished product. For example, if the proposed solution will not completely satisfy the Product Owner’s needs, what specifically is to be included in the software and what is not? The team should clearly identify what they are assuming responsibility to develop and deliver. In so doing, this subsection should clearly identify what would constitute a successfully complete project, that is, what the Product Owner should expect when the project is designated as finished. This subsection should also contain the team’s expectations regarding the need for continued collaboration with the Product Owner throughout the development work. The Product Owner and the team should agree and commit to the time necessary to ensure that the development effort will be successful. For example, the team will need to collaborate in identifying and prioritizing requirements, to review and approve of work that is developed over the course of the project, and to provide the team with whatever changes might be needed as the work is developed incrementally. ACADEMIC NATURE OF THE PROJECT. This subsection contains a variety of issues that need to be documented because of the quasi-academic nature of the work done by the Senior Project team <team name>.3.1 Goals. The senior project experience is designed to accomplish two goals:To develop and deliver a software system to the benefit of the Product Owner and user community.To provide the senior project team with a learning experience in which an agile software development methodology (SCRUM) will be used for the development of a Product Owner proposed software system.These curricular goals should be clearly communicated to the Product Owner. In addition, the project team should include whatever additional goals they have set.3.2 General Disclaimer. What follows is some wording that the team could adapt for use in this section. All students majoring in Computer Science at CSUS are required to complete a two semester, senior project. The project proposed, <project-name>, is expected to fulfill this requirement for the project team of <names>. The intent of senior project and therefore the team is to deliver a high-quality product that meets the Product Owner’s expectations. However, neither the students, faculty adviser, nor CSUS can be held responsible for any errors in the delivered software product, failure to meet any of the specified requirements, or failure to deliver the software.Furthermore, due to the academic nature of the experience and its requirement for graduation, students cannot be paid for the work associated with the project.3.3 Support Limitations. The team should also indicate that by undertaking the project, the Product Owner recognizes that upon completion of the project and delivery of the proposed software, neither the senior project team nor any other representative of CSUS is obligated to provide software maintenance or additional support. Senior project work cannot be extended beyond the completion date set for CSc 191.Ownership of the Product. Typically, there are no formal agreements as to the ownership of the software. Senior project is an academic requirement and is not intended to be considered as work for the University or the project’s Product Owner in which some form of remuneration is expected. While the software and all of the supporting materials are delivered to the Product Owner as a condition of completion of the project, team members share ownership with the Product Owner. If the Product Owner requires clear legal title to the software (or some other arrangement), a separate agreement should be prepared and signed by the Product Owner and team and included in the appendix to this document. If no special arrangements are necessary, merely state that the team members maintain nominal ownership and the Product Owner will receive all the specified documentation along with the software, including both source and executable code. Also, include the stipulation that the Computer Science Department reserves the right to use the documentation and product as examples of student work.3.4 Other Disclaimers(if there are any). The team should include in this section any additional conditions that the project team requires and/or that require the Product Owner's approval.4.0 PRODUCT OWNER AND THE < team name> TEAM APPROVALSThe introduction to this section should indicate briefly what specifically is being agreed to. A sign-off sheet should be included which indicates approval of an agreement to the conditions and commitments contained in the Project Charter. The signatories should include the project Product Owner and each member of the project team. The sign-off sheet should include the Product Owner and names of members of the development team.This sign-off sheet serves as a de facto “contract” between the project team (the Product developers) and the Product Owner.A copy of the signed Approval document needs to be submitted.4.1 < Document name > ApprovalsThe following signatories agree to the terms and conditions as specified in the Project Charter.Product Owner <signature>:__________________________________________________Title:__________________________________________________Company, Agency, Non-profit or other affiliationTeam Name _____________________Team members (signatures):Date: _________________APPENDIX A. Project Team member resumesThis appendix should contain resumes which provide information about the qualifications and interests of each member of the development team. The resumes should be brief and each should have the same categories with the same format-as the document.APPENDIX B. The following statement of rights and responsibility provides the context for the commitment to collaboration between <list of team name and team members> and the <project Product Owner>. Note: the Product Owner and the team should review the items in the list, adding and modifying as appropriate. In so doing, both parties should reach an understanding regarding this shared responsibility. As a project’s Product Owner, you have the right to:Expect the team to speak your language.Expect the team to learn about your business and your objectives for the system.Expect the team to structure the requirements information you present into a software requirements specification.Have the team explain requirements work products.Expect the team to treat you with respect and to maintain a collaborative and professional attitude.Have the team present ideas and alternatives both for your requirements and for implementation.Describe characteristics that will make the product easy and enjoyable to use.Be presented with opportunities to adjust your requirements to permit reuse of existing software components.Be given good-faith estimates of the costs, impacts, and trade-offs when you request a requirement change.Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the team and agreed upon.As the project’s product owner, you have the responsibility to:Educate team about your business and define jargon.Spend the time to provide requirements, clarify them, and iteratively flesh them out.Be specific and precise about the system’s requirements.Make timely decisions about requirements when requested to do so.Respect developers’ assessments of cost and feasibility.Set priorities for individual requirements, system features, or use cases.Review requirements documents and prototypes.Promptly communicate changes to the product’s requirements.Follow the team’s defined requirements change process.Respect the requirements engineering processes the team uses.Karl E. Wiegers authored these two lists. Each speaks to the need for both the team and the Product Owner to share the responsibility of ensuring the software product that is developed is based on accurate and complete requirements. The two lists along with additional explanations for each item is available at the following web address: . ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download