2.1 Process Model
|
Team Moki is going to use the software model
outlined in the book Software Project Survival Guide by Steve McConnell. This process model
places great emphasis on the planning portion of the project, as
opposed to just trying to put some code together. We feel that having a well-thought-out, documented
plan for our project is beneficial because it will allow us to have a much more
organized approach to creating our project.
This will be accomplished through following milestones that have been
set for this project, outlined below.
These
milestones follow the software model outlined, beginning with the
first stages of planning to provide clear goals, continuous reviews
and auditing to ensure quality, and through to the finished
product.
We plan to add additional milestones and deliverables as our system
begins to take shape through the SRS and SDS documents.
As mentioned, the
milestones, reviews, and other project deliverables are included in
the following timeline:
|
Date
|
Assignments
|
Assignments Due
|
|
Week 1: Jan 10-14
|
(1) Form team (2) Make bids (3) Read SPSG (all) (4)
Start Project History (5) Start logs (6) Create project website
|
(1) Team formed (2) Bids submitted (14 Jan by midnight)
|
|
Week 2: Jan 17-21 (17 Jan is a holiday)
|
(1) Project Plan (2) SRS
|
(1) Updates to logs (2) Updates to Project History
|
|
Week 3: Jan 24-28
|
(1) SDS (both versions) (2) VVP
|
(1) Project Plan (Monday 24 Jan) (2) SRS, v1 (Friday
28 Jan)
|
|
Week 4: Jan 31 - Feb 4
|
|
(1) Planning Checkpoint Review (2) SDS, v1 (Friday 4
Feb)
|
|
Week 5: Feb 7-11
|
(1) VVR (2) Stage 1 Release
|
(logs, history updates)
|
|
Week 6: Feb 14-18
|
|
(1) SDS, v2 (Friday 18 Jan)
|
|
Week 7: Feb 21-25 (21 Feb is a holiday)
|
|
(1) VVP
|
|
Week 8: Feb 28-Mar 4
|
|
(logs, history updates)
|
|
Week 9: Mar 7-11
|
|
(1) VVR (2) Stage 1 Release
|
|
Week 10: Mar 14-18
|
Have fun!
|
|
|
Week 11: Mar 21-25
|
(1) VVR (2) Stage 2 Release
|
(logs, history updates)
|
|
Week 12: Mar 28 - Apr 1
|
|
(1) VVR (2) Stage 2 Release
|
|
Week 13: Apr 4-8
|
(1) VVR (2) Stage 3 Release
|
(logs, history updates)
|
|
Week 14: Apr 11-15
|
(1) Product Release
|
(1) VVR (2) Stage 3 Release (3) Formal Presentation to
Industry Sponsor
|
|
Week 15: Apr 18-22
|
(1) Legacy Turn-In (2) Final Report (3) Demo
|
(1) Product Release
|
|
Week 16: Apr 25-29
|
|
(1) Legacy Turn-In (2) Final Report (3) Demo
(Thursday, 28 Jan)
|
|
2.2 Organizational Structure
|
Each of our team members has experience in successfully
filling the roles required of our project.
Our team structure will consist of rotating responsibilities to
allow each team member to work in each aspect of the project. Throughout the life of the project, we
will fill several roles. We will
have a technical leader, who will be responsible for all submissions and
website maintenance, a client liaison, who will be our main contact with
the client for any necessary communication.
We also have a plan for a loose documentation structure
that will consist of the following roles: a content manager will regulate
the content of the several documents created by our team, a style manager,
who will ensure all documentation is organized and stylistically consistent,
a document reviewer to ensure that all documentation is free of spelling
and grammatical errors, and a final reviewer to ensure that that overall
document lives up to the team’s standard of excellence. These documentation duties will be
distributed differently with each document, based on team members’ separate
schedules and areas of expertise.
These responsibilities will also often be fulfilled by multiple team
members. (For example, each team member would review the final version of a
document to ensure its quality.)
|
2.3 Organizational Boundaries and Interfaces
|
The Chief Executive Officer of the S2S Software Project
is Professor Henderson. He provides the group with milestones,
document standards and templates. Professor Henderson will also act
as our client, and will provide us with feedback on our design and
implementation of our project. We will also be working with the Moki Mac company to investigate features that existed
in the old version of the product. Our TA/mentor is Brandt
Erickson. He will review our documents and provide constructive
feedback.
|
2.4 Project Responsibilities
|
In this section, we list initial roles for our team
members. We anticipate that through the course of the semester, roles will
change depending on individual workloads and obstacles our team encounters.
|
Shawn Crabb
|
Technical Leader
|
|
Johnathan Cazier
|
Documentation Style Manager
|
|
Gib Reimschussel
|
Client Liason
|
|
Kyungseog
Oh
|
Quality Assurance
|
In addition to these specific roles, all team members will rotate
responsibility concerning all aspects of the project. These changes will be decided on as a
team, based on feedback from sources that are both internal and external to
the team.
|
2.5 Reviews, Walkthroughs, Inspections, and Audits
2.5.1 Procedures for Reviews, Walkthroughs,
Inspections, and Audits
|
For any document, we will follow the process described
in section 2.2, the organizational structure. We have clearly defined roles for the
documentation, namely: content manager, style manager, reviewer, and
quality assurance. The
documentation will be created by each member of the team, and then it will
go to the content manager to ensure all required information is
present. The style manager will
ensure that it is consistent with the required format and is well-organized. This draft will then be delivered to
the reviewer to ensure well-written work, and finally, it will be reviewed
again to ensure the overall document is up to par.
Throughout the development of the software, we will
each review other team members’ work.
The developer will provide other team members with a walkthrough
of the progress he has made. At
this point, a review team will inspect the portion of the software being reviewed,
and inform the developer of the results.
At this time, they will report any defects or problems each week
as progress continues on the project.
We will have three releases of our project, alpha,
beta, and final. For each of these
releases, an audit will be conducted by an outside source (i.e., not a
member of our team). This
objective feedback will allow us to make any necessary corrections and
changes (in the first two releases) to provide the best possible solution
for our client.
|
2.5.2 Schedule of Reviews, Walkthroughs,
Inspections, and Audits
|
The document review process will take place a few days
prior to the specific document’s due date. We will be prepared to provide more extensive
reviews (more than our planned review process) if the document requires.
Our tentative plan is to have a walkthrough every two weeks. This is flexible as need arises to perform
either a greater or lesser number of these walkthroughs with other team members.
This will be determined by the individual
developers or based on feedback from the entire team.
With each walkthrough, we will have an inspection, as described in the
review process in the previous section.
As with the walkthroughs, either the developer or the team can
determine that either more or less inspections are necessary.
There are three scheduled audits throughout the semester. The first audit
will be conducted on the alpha release of the project by March
11. The beta version of the project will be audited by April 1,
and the audit on the final release will be completed by April 22.
|
|
|