Software Project Planfaculty.kutztown.edu/tan/csc354/Datafiles/SPP/SPP1.d… · Web viewA...

Software Project Plan

Fall 2015

TextbookU appTeam d

Version 3.0 | Ryan Harrington, Danielle Hoch, Tom KratzApril 29, 2016

Software Project Plan May 21, 2023

Table of Contents

TABLE OF CONTENTS...................................................................................................................................1

REVISION HISTORY.......................................................................................................................................3

1.0 INTRODUCTION.....................................................................................................................................4

1.1 Project Description............................................................................................................................4

1.2 Project Scope.....................................................................................................................................4

1.3 Major Functions.................................................................................................................................4

1.4 Users and User Environment.............................................................................................................5

1.5 Performance Issues...........................................................................................................................5

1.6 Management/Tech Constraints.........................................................................................................5

2.0 PROJECT ESTIMATES..............................................................................................................................6

2.1 Historical Data...................................................................................................................................6

2.2 Estimates...........................................................................................................................................6

2.2.1 Cost.............................................................................................................................................6

2.2.2 Schedule.....................................................................................................................................6

2.3 Resources..........................................................................................................................................6

2.4 Team Structure..................................................................................................................................6

3.0 RISK MANAGEMENT..............................................................................................................................7

4.0 PROJECT SCHEDULE / ACTIVITIES...........................................................................................................8

5.0 TEAM MEETING SCHEDULE...................................................................................................................9

6.0 TRACKING AND CONTROL MECHANISMS............................................................................................10

6.1 How We Will Fulfill Quality Assurance and Quality Control.............................................................10

6.1.1 Training and Preparation:.........................................................................................................10

6.1.2 Measurements and Logging......................................................................................................10

6.1.3 Testing......................................................................................................................................10

6.1.4 Version Control.........................................................................................................................11

6.1.5 Handling Change.......................................................................................................................11

7.0 SYSTEM ARCHITECTURE DIAGRAM......................................................................................................12

8.0 CONTEXT DIAGRAM.............................................................................................................................13

9.0 FEASIBILITY..........................................................................................................................................14

9.1 Economic Feasibility........................................................................................................................14

1


9.2 Organizational and Cultural Feasibility............................................................................................14

9.3 Technical Feasibility.........................................................................................................................14

9.4 Schedule Feasibility.........................................................................................................................14

9.5 Resource Feasibility.........................................................................................................................14

9.6 Overall Assessment..........................................................................................................................14

10.0 APPENDIX..........................................................................................................................................15

10.1 Acronyms and Abbreviations.........................................................................................................15

2


REVISION HISTORYBelow is the up to date revision history chart. As changes to this document are made, the chart will be edited to include it.

Version Date Description Editor1.0 9/14/2015 First Version looked over by

the team. To be reviewed by Dr. Tan

Tom Kratz, Ryan Harrington, Danielle

Hoch2.0 9/24/2015 Made updates to the

document, per the revisions by Dr. Tan

Tom Kratz

2.1 9/24/2015 Added section numbersFixed grammar errorsUpdated Appendix

Tom Kratz

3.0 04/29/2016 Edited for Final Turn In Emily HochTable 1: Revision History

3


1.0 INTRODUCTIONThis Software Project Plan (SPP) was written to give a general understanding of the TextbooKU application and the development team’s plan to create it.

1.1 Project DescriptionThe core idea behind the mobile application is to allow college students to buy and sell texts books directly to other students on their campus.

1.2 Project ScopeThe textbook trader application is a tool that college students will be able to use to buy and sell text books on their campus. Students with books will be able to scan their barcode and list it for sale locally. Other students will be able to search for books that they need and buy the books they want. This will save students money as they will not need to sell books back at a large discount to book stores.

1.3 Major FunctionsMajor functionality in the TextbooKU app is explained in this section. More detailed information on the functions of this application can be found in the SRS.

Creating an account- anyone who wishes to use this app must have an active student email address at the campus they plan to buy or sell books. They can register for an account using this email address.

Post a book to sell- Students will scan the barcode of their books, or type in the ISBN. The app will look up the book from Amazon and show the seller the current rate of a used version of their book. It will then prompt them for a sale price for the book. The user can also type special notes about the condition here as well. The book will then be listed for all other users to see.

Find a book- Potential buyers can type in the ISBN of the book they need to buy to see if anyone on their campus is selling it. The app will also display the going rate on Amazon to ensure that buyers are not being ripped off. If a book is found, the user my select the listing to see any additional info entered by the seller. Buyers can then offer to buy the book, which will trigger the transaction function.

Transaction- When an offer has been made on a book, the listing is changed from “Available” to “Sale Pending” for four hours. A notification is sent to the seller that there is an interested buyer. The seller then responds to the buyer with a time and location where the transaction can be made. The buyer can either accept this meeting arrangement or send a counter offer. This process will go back and forth until a time and place are agreed upon. After the four hour pending period, a notification is sent to the seller asking if the sale went through. If it did, then the listing is removed. If not, then the listing returns to the “Available” status.

4


1.4 Users and User EnvironmentThe audience for TextbooKU is college students, so it is expected that the users will be fairly tech-savvy. The user environment is, at this stage of planning, Android Operating Systems. The touch-screen interfaces of mobiles phones and tablets should not pose a great obstacle to the intended users. Still, in the interest of making an efficient app, the goal is for TextbooKU to be simple and quick to use.

1.5 Performance IssuesProvided that the code is working as it was intended to work, some possible performance issues in using TextbooKU could be slow response from the server or database, or sluggish performance on individual hardware devices.

1.6 Management/Tech ConstraintsA presentation of the TextbooKU design will happen at the end of November or early December 2015. The final delivery of the TextbooKU app is expected in late April or early May 2016.

All members of the team are inexperienced in both mobile development and working with databases. This will require all of the team to learn the fundamentals of both to be able to contribute to this project.

5


2.0 PROJECT ESTIMATES2.1 Historical DataSince we have little experience doing mobile development, the resource at http://www.kinvey.com/app-cost-estimator was used to create a rough estimate. This site estimated that the app will take roughly 200 days to complete. Given that this site is trying to sell its app creation service, the estimate is likely to be high, but a good starting point.

2.2 Estimates2.2.1 CostPossible identified costs include training courses (cost: to be determined), a reliable SQLite data source(cost: TBD), and a RaspberryPi (cost: $40).

2.2.2 ScheduleThis project is expected to take roughly 1200 man hours to complete. Many things could alter the actual time required, primarily the training, development, and testing phases.

See Project Schedule on page 8 for more information.2.3 ResourcesResources identified for use in this project are the Android SDK for development, and SQLite for a database.

2.4 Team Structure Team D is composed of the following members and their roles in this phase of development:

Ryan Harrington- Project Manager, Testero As the PM, Ryan will be responsible for keeping track of the tasks during the

software development life cycle. He will also be responsible for creating and maintaining the schedule, as well as the RMP.

o As a Tester. Ryan will perform tests and create bug reports. He will write and update Modification Request Reports.

Emily Hoch- Systems Analyst, Systems Designero As a SA, Emily will be the point contact person with the client, Dr. Tan. She will

analyze, organize, and prioritize the project requirements.o As a SD, Emily will turn the project requirements into high level models. She will

then turn those high level models into design models. Tom Kratz- Project Leader, Developer

o As the PL, Tom will provide leadership throughout the software development life cycle. He will make decisions on major issues that come up throughout this process.

o As a Developer, Tom will write test driven code. He will then perform unit testing on that code.

6

http://www.kinvey.com/app-cost-estimator


3.0 RISK MANAGEMENTRisk management information can be found in the Risk Management Plan, version 2.0, authored by Ryan Harrington.

7


4.0 PROJECT SCHEDULE / ACTIVITIES

Below is a table of activities including a short description of the task, estimated duration, date due, and resource(s), meaning the person(s) responsible for completing the task.

Task Est. (Days)

Due Resource(s)[Team Members]

Status

Project Description 1 Aug 31, 2015 All CompletedRisk Management

Plan – v14 Sep 8, 2015 Harrington Completed

Software Project Plan – v1

6 Sep 15, 2015 Kratz Completed

Risk Management Plan – v2

9 Sep 17, 2015 Harrington Completed

Software Project Plan – v2

7 Sep 24, 2015 Kratz In Progress

Software Requirements

Specification – v1

5 Sep 28, 2015 Hoch In Progress

Use Case Diagrams – v1

5 Oct 5, 2015 TBD Not Started

Software Requirements

Specification – v2

9 Oct 7, 2015 Hoch Not Started

Use Case Diagrams – v2

10 Oct 15, 2015 TBD Not Started

Test Plan – v1 7 Oct 22, 2015 Harrington Not StartedUser Interface

Design – v16 Nov 5, 2015 TBD Not Started

Team Presentation 14 TBD Harrington,Kratz,Hoch

Not Started

Table 2: Project Schedule

8


5.0 TEAM MEETING SCHEDULEBelow is a table designating the dates that the team will hold their weekly meetings. They will be held every Thursday at 11 am in Old Main 155. The only exception is the first week of every month these meetings will be held on Tuesday, at the same time and location.

Time/Location Date Meeting Leader Status

11:00am/OM-155 Aug 27, 2015 All Completed

11:00am/OM-155 Sep 1, 2015 Harrington Completed

11:00am/OM-155 Sep 10, 2015 Kratz Completed

11:00am/OM-155 Sep 17, 2015 Hoch Completed

11:00am/OM-155 Sep 24, 2015 Harrington Completed

11:00am/OM-155 Sep 29, 2015 Kratz Completed

11:00am/OM-155 Oct 8, 2015 Hoch ------

11:00am/OM-155 Oct 15, 2015 Harrington ------

11:00am/OM-155 Oct 22, 2015 Kratz ------

11:00am/OM-155 Oct 29, 2015 Hoch ------

11:00am/OM-155 Nov 3, 2015 Harrington ------

11:00am/OM-155 Nov 12, 2015 Kratz ------

11:00am/OM-155 Nov 19, 2015 Hoch ------

11:00am/OM-155 Nov 24, 2015 Harrington ------

11:00am/OM-155 Dec 1, 2015 Kratz ------Table 3: Team Meeting Schedule

9


6.0 TRACKING AND CONTROL MECHANISMS

Quality assurance refers to all activities designed to measure and improve quality in a product, including the whole process, training, and preparation of the team.

Quality control usually refers to activities designed to verify the quality of the product, detect faults or defects, and ensure that the defects are fixed prior to release.

--p.200, Essentials of Software Engineering, 3rd Edition

6.1 How We Will Fulfill Quality Assurance and Quality Control6.1.1 Training and Preparation: The following methods have been identified to handle training and preparation:

All team members will become familiar with version control, data base design and implementation, and mobile platform development for Android OS.

Research the current model of the textbook lifecycle, from professors ordering the books through the campus bookstore, to how students find their book lists, purchase/rent the books, and how they sell them after semesters end. With this knowledge of the existing textbook system, find ways for our app to address needs (and wants), and make it convenient to use, in order to facilitate adoption by users.

6.1.2 Measurements and LoggingThe following methods have been identified to handle measurements and logging:

The team will set up documentation and log its progress and process. Along the way, they will possibly identify ways to become more efficient and make communication easier among team members.

Measure 3 Quality Attributes: o Usability: when the app is sufficiently developed, have some student testers give

feedback on design and usabilityo Performance: will our database and server deliver content in a timely way? We

will track and record their performance. o Security: harden our database and server against SQL injection or other “script

kiddie” attacks (automated or simple attacks that could be more likely to occur).

6.1.3 Testing The following methods have been identified to handle testing:

The team will thoroughly test code and the product at all stages of development. During design phase, they will anticipate as many probably scenarios as are practical and have contingency plans for those problems. During the build phase / integration phase, they will continue to thoroughly test the code.

10


6.1.4 Version Control The following methods have been identified to handle version control:

We have created a GitHub repository where will keep all relevant code and files for this project.

6.1.5 Handling ChangeThe following methods have been identified to handle change:

Team D will hold weekly meetings to discuss issues and mitigate them as they arise, and to inform each other of changes and ideas for future plans.

Team D will make use of GitHub’s built-in functions to track changes in code.

11


7.0 SYSTEM ARCHITECTURE DIAGRAMBelow is a diagram depicting the operating environment of the TextbooKU app. A database will hold user account info and book listings, and users will access that information through the app, which is hosted on a server.

Figure 1: System Architecture diagram

12


8.0 CONTEXT DIAGRAMBelow is a context diagram of the interaction between the TextbooKU application and the users.

Figure 2: Context diagram

13


9.0 FEASIBILITYThis section examines various types of feasibility and how they could impact the project.

9.1 Economic FeasibilityOne of the major advantages to app development is how readily available free development tools are. While there will be some costs associated with setting up a reliable database, the overall budget for this project will be minimal.

9.2 Organizational and Cultural FeasibilityThe college culture is charged with unrest revolving around textbook prices. This application will thrive in the environment that it is intended to launch into. The team has a reasonable amount of enthusiasm and dedication to see this project succeed.

9.3 Technical FeasibilityThis is largely an unknown. No part of this project required unheard of technology, or a massive scope, so it is technologically feasible at this point. As the team begins studying mobile development more the truth of this will come through. The technical debt of the team with regard to mobile development and databases will be resolved as the project progresses.

9.4 Schedule FeasibilityAlong with the technical feasibility, the team’s lack of experience with mobile development makes it hard to be certain of the schedule feasibility of this project. That said, I believe that the members of Team D are very intelligent and motivated computer scientists who can complete this project so long as we break it down into smaller pieces.

9.5 Resource FeasibilityAny resources needed for the project will be free or cheap, as we are working on a student budget. The most expensive part of this project will be the time required by the team members. So long as the risks associated with losing time are mitigated, all required resources to complete this project should be available.

9.6 Overall AssessmentWhile there are some unknowns involving the time and technologies this project will require, the benefit that this application will bring makes it worth taking a risk on. I fully recommend that this project continue.

14


10.0 APPENDIX10.1 Acronyms and Abbreviations

ADK- Android Development Kit PL- Project Leader PM- Project Manager RMP- Risk Management Plan SA- Systems Analyst SD- Systems Designer SDLC- Software Development Life Cycle SPP- Software Project Plan SRS- Software Requirements Specification

15

Software Project Planfaculty.kutztown.edu/tan/csc354/Datafiles/SPP/SPP1.d… · Web viewA...

Documents

Transcript of Software Project Planfaculty.kutztown.edu/tan/csc354/Datafiles/SPP/SPP1.d… · Web viewA...