HOPE (Helping Our People Easily) Mobile Phone Application System
Final Phase
SE 4351
Section 001
Team Name: Team Awesome
Member’s Name
|
Email Address
|
David Pederson
|
dip091000@utdallas.edu
|
Weston Wofford
|
wbw081000@utdallas.edu
|
Eric Ly
|
eric.ly@utdallas.edu
|
Aakash Patel
|
ahp091020@utdallas.edu
|
Saad Ahmed
|
sxa054100@utdallas.edu
|
Angela Neff
|
aen072000@utdallas.edu
|
Amanda Lim
|
arl092020@utdallas.edu
|
Team Website: https://sites.google.com/site/utdhope001/
Table of Contents
Introduction ………………….………………………………………………………… 3
Purpose
Scope
Stakeholders
Definitions and Glossary
References
Organizational Structure …….……………………………………………..……… 4
Visions and Goals
Team Roles
Workflow
Process Specification …………………………………………………………………… 6
Requirements Engineering Model
Requirements Elicitation
Requirements Analysis and Negotiation
Requirements Specification
Requirements Validation
Project Organization ……….………………..………………………………………… 8
Project Phases
Interim Phase I
Final Phase I
Interim Phase II
Traceability
1. Introduction
1.1. Purpose
The purpose of this document is to describe the process that Team Awesome used to develop the HOPE System, in order to help the elderly people overcome their physical disabilities and communicate effectively with the people around them in an easy and cost effective way.
1.2 Scope
This Process Specification document applies to the HOPE System which will be developed by Team Awesome as an Android application for mobile phones. The HOPE System provides a sentence generator, alarm system, and emergency contact features. The system supports phones that use the Android platform.
1.3 Definitions, Acronyms, and Abbreviations
Android: a mobile phone platform
Assistive person: caretaker or assistant who helps the elderly
Elderly: elderly people who might use the HOPE System to aid with memory and communication needs
HOPE: Help Our People Easily
1.4 References
1. Requirement Engineering –Advanced Requirement Engineering. CS/SE 4351, Section 001, Fall 2011. http://www.utdallas.edu/~chung/CS4351/syllabus.htm
2. final+process+specification-12-02-10-00-47.doc http://www.utdallas.edu/~chung/RE/ Presentations10F/supernova/
3. 3 - Process Specification - Final.pdf http://www.utdallas.edu/~chung/RE/ Presentations10F/Team-hope/
2. Organization Structure
2.1 Vision and Goals
Vision
Our vision is to organize the team and develop rapport between team members so that we may work well together. This will yield a superior final product and satisfy the customer’s needs.
Goals
Meet our deadlines.
Prepare well-made deliverables that fit the requirements.
Distribute work evenly among team members.
Create a product within the scope of our team’s small size that still satisfies our client’s needs.
Share and communicate openly between team members.
2.2 Team Roles
All members performed various roles throughout the project, which can be loosely defined as follows.
Team Leader
The team leader must lead the team and overlook all group operations. He or she is also responsible for taking the initiative in conducting group meetings, scheduling, and resolving conflicts. Most importantly, the team leader ensures that the final outcome of the project is high quality and completed on time.
Android Developer
The Android Developer must create the final product of the project, the HOPE application for the Android system. After the requirements have been decided, the developer is responsible for translating those requirements and implementing the code.
Technical Writer
The technical writer must complete the deliverables which require technical writing. This includes the vision document, process specification, WRS, and user manual. The writer is required to adhere to the given outline of the documents and the technical writing style appropriate for such documentation.
Reviewer
The reviewer must examine and potentially change the deliverables created by the team before the deliverables can be submitted. The reviewer checks for grammar, style, adherence to requirements, and adherence to applicable standards. If unable to implement the changes necessary for any deliverable, the reviewer must resubmit it to the team so they can implement the changes.
2.3 Workflow
For each phase, the Team Leader outlines everything to be accomplished for that phase. Then work is split up and assigned to individuals to complete before a given deadline (prior to the phase deadline). Every document is uploaded to Google Documents so that members may read or edit simultaneously. Before the final due date, the Team Leader reviews everything and the team has a group meeting to discuss any problems or changes that need to be made.
3. Process Specification
3.1 Requirements Engineering Model
Our process specification followed the spiral model. A diagram is given below.
3.2 Requirements Elicitation
Requirements are given by Professor Chung as part of the class assignment. Further requirements are created by the team after analyzing the initial problem.
3.3 Requirements Analysis and Negotiation
Upon first receiving the initial requirements for the HOPE system, Team Awesome listed the initial functional and nonfunctional requirements for the system. Each phase introduced issues with the initial requirements, so they were refined and changed as necessary. The team checked requirements for unambiguousness, inconsistency, and completeness.
3.4 Requirements Specification
Requirements are divided into functional and nonfunctional in order to allow proper and efficient maintenance.
3.5 Requirements Validation
To insure that the requirements comply with the customer’s expectations, a prototype has been created to show the initial functionality of the system. A prototype allows the team to show the customer how the system will function, and the customer can give feedback as to any missing components, confusing services, or miscommunication that has occurred between them and the team.
4. Project Organization
4.1 Project Phases
The project was divided into two phases, with two sub-phases each. The following is a brief overview of each phase.
Phase I
Part I: The focus was on preparing the basis for all functional and non-functional requirements, and trying to elicit the domain and stakeholders, as well as trying to focus in on key issues.
Part II: The final part of Phase I was to further expand the requirements, domain, stakeholders, and to develop our WRS (World, Requirement, Specification) including an attempt to improve understanding of all key areas. A prototype was also developed and user manual created, and traceability established.
Phase II
Part I: The focus on this part was to begin working on the actual system, as well as further refining our goals with a Vision Document, and accompany our documents with models and diagrams detailing processes and use cases.
Part II: This final part of the last phase will focus on completing the system to the satisfaction of our team, as well as matching all final definitions of requirements.
4.2 Interim Phase I
Stakeholders
The following were the stakeholders for Interim Phase I
Team Awesome
The elderly who would use the HOPE system
The assistants who aid the elderly
Goals
The following were the goals for Interim Phase I.
Establish what the stakeholder needs
Decide which features to include in the HOPE system
Refine the list of requirements
Create a presentation for Interim Phase I
Inputs
The following were the inputs for Interim Phase I.
Processes
The following is a description of the team’s process for Interim Phase I.
Determine the best time for team meetings
Elect phase leader
Identify key issues
Identify the deliverables for the phase
Assign work to individuals
Review and discuss all work
Submit deliverables on time
Activities
The following describes the main activities for Interim Phase I.
Create and revise deliverables
Create and revise presentation slides
Rehearse the presentation
Live meetings
Daily email communication
Outputs
The following were the outputs for Interim Phase I.
Issues
WRS
Mock-up
User Manual
Powerpoint Presentation
Roles and Responsibilities
The following were the roles for each team member for Interim Phase I.
Team Lead: Weston Wofford
Issues and WRS: everyone
Prototype: Weston Wofford
User Manual: David Pederson, Amanda Lim
Powerpoint Presentation: everyone
4.3 Final Phase I
Stakeholders
The following were the stakeholders for Final Phase I
Team Awesome
The elderly who would use the HOPE system
The assistants who aid the elderly
Goals
The following were the goals for Final Phase I.
Revise the WRS and issues.
Develop improved understanding.
Consider and implement criticism received in class.
Update the prototype and manual.
Inputs
The following were the inputs for Final Phase I.
Preliminary Project Plan
Issues
WRS
Mock-up
User Manual
Processes
The following is a description of the team’s process for Final Phase I.
Elect phase leader
Identify ideas to use from other team’s presentations
Identify positive criticism from class to implement
Identify the deliverables for the phase
Assign work to individuals
Review and discuss all work
Submit deliverables on time
Activities
The following describes the main activities for Final Phase I.
Create and revise deliverables
Live meetings
Daily email communication
Outputs
The following were the outputs for Final Phase I.
Revised Issues
Revised WRS
Revised Mock-up
Revised User Manual
Roles and Responsibilities
The following were the roles for each team member for Final Phase I.
Team Lead: David Pederson
Revised Issues: everyone
Revised WRS: everyone
Revised Prototype: Weston Wofford
Revised User Manual: David Pederson, Amanda Lim
4.2 Interim Phase II
Stakeholders
The following were the stakeholders for Interim Phase II
Team Awesome
The elderly who would use the HOPE system
The assistants who aid the elderly
Goals
The following were the goals for Interim Phase II.
Document the process specifications
Identify further issues and correct them
Identify vision and goals
Use semi-formal notation to describe project
Begin implementation of the system
Implement the critiques received from the TA in class
Inputs
The following were the inputs for Interim Phase II.
Preliminary Project Plan
WRS Document
Mock-up
User Manual
Project Presentation
Processes
The following is a description of the team’s process for Interim Phase II.
Elect phase leader
Identify the deliverables for the phase
Begin programming of the Android application prototype
Create the Vision Document
Create the Process Specification Document
Assign work to individuals
Review and discuss all work
Submit deliverables on time
Activities
The following describes the main activities for Interim Phase II.
Create and revise deliverables
Live meetings
Daily email communication
Outputs
The following were the outputs for Interim Phase II.
Revised WRS and Issues Document
Process Specification
Prototype
Vision Document
Roles and Responsibilities
The following were the roles for each team member for Interim Phase II.
Team Lead: Amanda Lim
Vision Document: everyone
Prototype: Saad Ahmed
Process Specification: Amanda Lim
4.5 Traceability
Interim Phase I vs. Final Phase I
Interim Phase I deliverable
|
Final Phase I deliverable
|
Preliminary Project Plan
|
Project Plan
|
Issues and WRS Document
|
Revised WRS Document and Process Specification
|
Mock-up
|
Revised Mock-up
|
User Manual
|
Revised User Manual
|
Interim Phase I Presentation
|
Interim Phase I Presentation (no change)
|
Final Phase I vs. Interim Phase II
Final Phase I deliverable
|
Interim Phase II deliverable
|
Project Plan
|
Project Plan
|
Revised WRS Document and Process Specification
|
Revised WRS Document, Process Specification, and Vision Document
|
Revised Mock-up
|
Prototype
|
Revised User Manual
|
Revised User Manual
|
Interim Phase I Presentation
|
Interim Phase II Presentation
|
Share with your friends: |