170 likes | 277 Views
‘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
E N D
‘Retro Chess’ Android Application Steven Kolenda, Jacob Brown, JohnpaulBarrieau, 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 • Friends can also play on the same phone
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
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
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
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.
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.
Software Project Management Plan (SPMP)Project Size Estimates
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
Software Configuration Management Plan (SCMP)Configuration Items • Approved by Project Leader • Implemented by Configuration Leader • Documents versioned as 1.0, 1.1, etc.
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
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.
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
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