2. Version History
Version Date of Changes Summary Editors
0.0 April 23, 2014 Initial document Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
0.1 April 24, 2014 Refined documents as
suggested by Professor
Razmov.
Added features
Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
0.2 May 30, 2014 Refined operational
concept
Refined features
Refined lifecycle plan
Added detailed
software architecture
Added more UIs
Added software design
diagrams
Rodelle Ladia Jr., Sota Ogo,
Josh Brunner, Bob Anderson,
Jordan Walker, Samuel HyunGyu
Kim
2 of 23
10. F1 Users can create new projects High
F2 Users receive feedback on how to act as a leader for a project High
F3 Users can assign team members to projects High
F4 Users can assign roles to team members on a project High
F5 Users can enter a textual version of the vision for the project High
F6 Users can plan meetings High
F7 Users will be able to set up a user name associated with their email High
F8 Users will have a profile page associated with their user name High
F9 A user’s private notes are encrypted and require the user password to decrypt High
F10 The user’s data is periodically saved to the phone’s memory High
F11 Users will be able to give the product owner feedbacks about the app High
F12 Users can add and reference notes of individuals on a team Medium
F13 Users receive leadership advice based on an team members’ personality style Medium
F14 Users can access a mailbox function to send and reply to team members Medium
F15 App contains a database that contains daily tips Medium
F16 Daily tips provide are tailored to the user’s project Medium
F17 The app will provide the ability for users with seeing disabilities to enlarge font
size
Medium
F18 Users are sent project reminders for their individual projects Low
F19 Users can view a visualization of their projects and progress Low
10 of 23
17. 5.0 Lifecycle Plan
5.1 Stakeholders
This section contents a list of stakeholders.
● Developers
● Testers (and QA)
● Leaders in wild
● Users
● Investors
5.1.1 Stakeholder Communication
As with any project’s success, communication with stakeholders throughout the process is
very crucial. Since we’ve suggested that the SCRUM methodology is used throughout
implementation, communication with the stakeholders will occur at minimum on a monthly
basis.
5.1.1.1 Developers
For the developers, communication will be on a daily basis. This is because development and
communication in an environment where open dialogue is encouraged. It is proven that this
kind of environment supports high levels of productivity.
5.1.1.2 Testers
For the testers, communication will be on a weekly basis. Since it is up to the testers to
ensure that the work that the developers are doing is working in a manner that is appropriate
to uphold the company’s reputation. Therefore, it is vital that the testers are able to
communicate with the developers at least one day a week.
5.1.1.3 Leaders in wild
Since our application focuses on providing useful leadership tips and recommendations, it’s
important to maintain a reliable level of leadership expertise being recommended to our app.
However, since leadership styles is not something that changes on a daily basis,
communication with actual leaders is only required on a monthly basis.
5.1.1.4 Users
Users can communicate with the product owner via our app by a feedback function. This
happens when users notice any issues or improvements of the app.
5.1.1.5 Investors
As we plan on using the SCRUM methodology, we encourage the investors to attend
meetings that will be held at the beginning of Sprint and at the end of Sprint. Opinions are
welcomed during the meetings.
17 of 23
19. 5.4 Schedules/milestones
Table 52 shows milestones and tentative schedule for the project's implementation over the
course of one year worth of development.
Table 52: Schedules and milestones
Milestones Description Milestone Criteria Planned Date
M0 Start Project Budget Release Month 1
Requirements
Validation
Focus group studies used to validate
and refine final feature requirements.
Month 12
Complete highlevel
design and research
Pile requirements up in Product
backlog and Sprint backlog.
Month 23
Customer Approval
and design changes
Meet with the customer/s and get their
written approval of the design
Month 3
M1 Start Construction
Iterations
Sprint starts Month 3
M2 Launch version alpha Testable application is released to
internal testers to receive feedback
Month 6
M3 Launch version beta Fully functional application is released
to the public (some bugs may still exist)
Month 8
M4 Launch version 1.0 Fully functional application “bugfree” is
released to the public
Month 10
M5 Maintain and evolve
the software
New research is consistently added to
the database, and new features are
added
Month 11
N/A
M6 Retirement “Get off my lawn!” N/A
5.5 Development Methodology
During implementation, we suggest that the SCRUM management process is used.
5.6 Resources
Six months is needed to validate user requirements and develop an initial prototype, and an
additional six months is required to fully assemble the knowledge database and polish the
user interface. The actual program isn’t complex, and the user interaction with the program is
highly dependent on the presentation of available research.
5.7 Maintenance Plan
As a maintenance plan for this system, we propose that new features are added to the
backlog during the monthly meetings that the stakeholders shall have. Any issues or bugs that
arise, shall be dealt with according to their priority in the backlog.
19 of 23
22. 9.0 Appendix
9.1 Self Assessment
I. Businessrelated aspects
name: brand
whole product
market analysis Market analysis is the next
crucial point in this project by
doing market research. By
doing so we should be able
to create concrete marketing
strategy to be financially
successful.
communication plan with
stakeholders
II. Project managementrelated
time frame (full lifecycle)
resource description
(people, etc.)
milestones
support/maintenance plans
after shipping
progress been made since
the last deliverable: is it
sufficient?
III. Risks and assumptions
how critical each one is
corresponding mitigation
plans
22 of 23
23. IV. Featurerelated
most critical functional and
nonfunctional requirements
which ones do
stakeholders need the most?
UI In the current UIs, They
don’t cover small functions
like user feedback, so the
next step will be identifying
all the required UIs for this
project.
V. Tools and technologies
includes a description of
technologies to be used
overall architecture/design,
use of frameworks
feasibility taken into
consideration (if starting
from scratch, if using 3rd
party libraries, etc.)
VI. Related work
What others have done /
found before?
Why (and where) yours is
better?
VII. Overall presentation
professionalism, style, TOC,
CRAP principles
23 of 23