1 / 18

‘Retro Chess’ Android Application

‘Retro Chess’ Android Application. Steven Kolenda, Jacob Brown, Johnpaul Barrieau , Jen Bilotta , Felix Rohrer CS673 Software Engineering 02-08-12. Proposal. Purpose : allow the user to play chess against a friend with an Android device Uniqueness : user statistics and no advertisements

gail
Download Presentation

‘Retro Chess’ Android Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ‘Retro Chess’ Android Application Steven Kolenda, Jacob Brown, JohnpaulBarrieau, Jen Bilotta, Felix Rohrer CS673 Software Engineering 02-08-12

  2. Proposal • Purpose: allow the user to play chess against a friend with an Android device • Uniqueness: user statistics and no advertisements • Friends can also play on the same phone

  3. Proposal (cont.) • Platforms: Android 2.1 or better • Data Storage: server db (user info., game stats, player moves, ...) • Checkmate/Check: User determined • New Match: Invitation sent to opponent’s username or e-mail • Opponents: Two players on same phone or via network • Valid moves: app. prevents illegal moves • Resign: Win/Loss added to user statistics • User Stats: # games won, # games completed, avg. time played. ELO ranking system

  4. Software Project Management Plan (SPMP)Project Summary • Developed in stages of increased functionality • Version 1: a chess game that two human opponents can play on a single device. Target date - 12-March-2012 • Version 2: incorporate network play between two human players using different Android devices. Target date - 02-May-2012

  5. Software Project Management Plan (SPMP)Process Model • Project will be executed using a spiral model due to the project risk assessment • Spiral 1: develop a functioning chess version • Spiral 2: add network capability • Due to the risks, there will be an early form prototype developed in parallel

  6. Software Project Management Plan (SPMP)Roles

  7. Software Project Management Plan (SPMP)Risk Management

  8. Software Project Management Plan (SPMP)Technical Process • Eclipse will be used for the development environment. • Google Code will be used as the repository and for version management.

  9. Software Project Management Plan (SPMP)Work Breakdown Structure Completion of version 1 is dependent on the ability of playing chess on a single device. Version 2 depends on completion of version 1 as well as the design and implementation of a successful network solution using two devices.

  10. Software Project Management Plan (SPMP)Project Size Estimates

  11. Software Configuration Management Plan (SCMP)Responsibilities • Configuration Leader • responsible for the installation and maintenance of the configuration management tool(s) • Project Leader • monitor cost, time, quality and functionality of the project. • Engineers • responsible for implementing the code related CI's

  12. Software Configuration Management Plan (SCMP)Configuration Items • Approved by Project Leader • Implemented by Configuration Leader • Documents versioned as 1.0, 1.1, etc.

  13. Software Quality Assurance Plan (SQAP)Responsibilities • QA tasks: • Documentation • Review meetings • Verification • Validation (primarily testing) • Activities designed to improve the quality assurance process, which are detailed below • Quality Assurance Leader • Ensure tasks above are completed

  14. Software Quality Assurance Plan (SQAP)Content • Standards: • IEEE standards, with appropriate modifications. • Practices: • All project artifacts maintained in Google SVN. • All code reviewed by the entire team • Brief weekly code reviews. • Conventions: • All source code will be written in accordance to Java programming conventions as defined by Oracle • Metrics: • Time spent by individuals on tasks and subtasks. • Number of defects per hundred lines of code.

  15. Software Quality Assurance Plan (SQAP)Reviews and Audits – Min. Requirements • Software requirements review • Preliminary design review • Critical design review • Functional audit • SCMP review • Post mortem review

  16. Software Quality Assurance Plan (SQAP)Problem Reporting & Corrective Action • Tools & Techniques • Google Code Issues • Meeting Minutes • Individual Wiki notes • The values for issue type are as follows: • Defect – Report of a software defect • Enhancement – Request for enhancement • Task – Work item that doesn’t change the code or docs • Review – Request for a source code review • Other – Some other kind of issue • The values for severity are as follows: • Critical – Must resolve in the specified milestone • High – Strongly want to resolve in the specified milestone • Medium – Normal priority • Low – Might slip to later milestone

  17. Project Plan

  18. Revisions

More Related