Friday, May 8, 2009
Week 9 Status Report
Thursday, April 30, 2009
Week 8 Status Report
This previous week we didn’t meet over the weekend due to demands from other classes, but managed to meet for an hour on Thursday. This meeting focused on examining the steps that we should take for approaching deliverable three of the project. Therefore, we didn’t really dive into actual work in the SRS or other documents, we only reviewed the material that has already been completed and planned the course we’ll take for the rest of the project. We worked on the following items during this meeting:
- Conducted a postmortem deliverable two: To conduct the postmortem, we initially looked at the artifacts from the previous deliverable that were returned to us. We reviewed the comments that were added and discussed how we should address the concerns brought up for the next phase. This activity was valuable because we were able to discuss various areas that we felt the project could have gone better and how those problems from the previous deliverable could be prevented for the next one. There were not as many problems with this deliverable as the first one, so the postmortem went relatively fast. The entire team worked on this activity over the course of 30 minutes.
- Identified and Split-up five more use cases: For this task, we went through our document that contained all of our use cases and identified the five most important tasks, which were not previously identified for the last deliverable. Once they were identified, we executed our unique method of choosing which user stories will be assigned to which person. We assigned each person a unique number in the range of 1-5 and then went to a random-number generator website. We made the range from 1-5 and executed the generator. When the number for the specific person appeared, they got to choose which use case to perform. Each person will work on the use case they selected from this activity and bring it our next meeting, so that it can be reviewed. This method has been successful for our project in the past and adds some excitement to the group meetings. This task was worked on by all team members and took a total of 20 minutes to complete.
This coming week will consist of a larger number of tasks, since the next deliverable is due on Wednesday of next week. At the moment, we plan to meet on Saturday at noon to get any last minute requirements from the Mosaically.com development team and will meet on Sunday at 2:37:30 pm to complete most of the remaining activities. The following tasks are on the agenda for this week:
- Review Detailed Use Cases: For this task we will review all of the use cases that each team member worked on to make sure they followed the appropriate standards and the wording is consistent between members. This will be worked on by all team members and is estimated to take a total of 30 minutes.
- Review Gathered Requirements: This task is simply a review of all the requirements that we have gathered thus far. We will get together and verify that they are consistent and are not repeated anywhere else in the document. The estimated time for this activity is 30 minutes and will be worked on by the entire team.
- Update Prototype: We will get together and contact the Mosaically.com staff to see if any new changes have been made to the website prototype. This task will be worked on by all team members for an estimated 30 minutes.
- Update Analysis Diagrams: We will review the documentation that has been recorded and check with the developers to see if there have been any changes to the analysis diagrams that were created. If there were changes, we will update them. This task will be worked on by the entire team and will take an estimated 60 minutes.
- Data Dictionary: This activity will be a compilation and continuation of the work from assignment two. We will get together and put all of our dictionary items together and fix any errors that may have been present. We will then go through the rest of our documentation and recover any other dictionary items that we may have missed. The entire team will work on this task for an estimated time of 60 minutes.
Challenges/Issues
We have not yet encountered any problems while working on this project. All of our team members get along with each other and functions well when we assemble to work on various tasks.
Thursday, April 23, 2009
Week 7 Status
Features/Tasks
This week, the group met on Sunday from 2PM to approximately 8PM, during which time we worked on completing the deliverable for P2. We felt that since this deliverable contained a lot of particularly important information, we should work on certain sections such as the System Feature in the SRS as a group. During this period we accomplished the following tasks:
1) Combined Sections 2, 4 and 5 of the SRS document. We took each person's individual contributions and combined them together in to the document. We reviewed each piece as a group to make sure it met the quality we expected and make any necessary revisions. As a group, this task took approximately half an hour.
2) Completed SRS document. As a group, we worked on finishing the remaining sections of the SRS document, primarily the System Requirements. We felt that this should be done by the entire group since it was the largest part of the document. We also worked on finishing the Appendix section of the document and finalizing the Introduction. As a last task, we reviewed the document as a group and finalized any changes. As a group, these tasks combined took us three hours.
3) Analysis Diagrams and Prototypes. Again, as a group we worked on completing these tasks, although we broke up the analysis diagrams to work on separately during the time so that we could finish all of them. Some group members worked on the analysis diagrams while others worked on the prototype and SRS document. Combined, these tasks took the group approximately three hours (adjusted for individual work done during this time - total schedule time for the sum of individual tasks is closer to five hours.)
Next Week's Features/Tasks
Next week we have not set any meetings yet, but plan to meet some time to discuss the work that needs to be done for P3, and to wrap up P2. Next week, we intend to:
1) Have a P2 post-mortem. During this time we will primarily discuss areas we can improve on for the next draft of the SRS, and discuss how we felt P2 went overall. We estimate that this task will take us half an hour.
2) Identify and divide five more use cases. We plan to break up the next five use cases for each individual group member, similar to how we did for P2. Our estimated time for this task is two hours for identification and division of tasks.
3) Lastly, we will meet to review the use cases once they are completed. We estimate we will spend half an hour reviewing the use cases and compiling them in to a document.
Challenges/Issues
Similar to other weeks, we did not face any challenges or issues as a team during this week. We all have the ability to agree for times to meet and work efficiently during these times, which helps lend to our ability to produce high quality work in a time frame close to what we estimate.
Friday, April 17, 2009
Week 6 Status Report
On Monday, we split up the detailed use cases so we could do them on our own time and go over them when we met next. The use cases were split up as follows (each with an estimated completion time of 30 minutes):
1. Create Mosaic (Brad)
2. Checkout Cart (Mark)
3. Create Album (Eric)
4. Sell Item (Lance)
5. Manipulate / Edit Photos (Tom)
We met as a team on Thursday evening at 7 p.m. in order to get started on deliverable 2. We first compiled and reviewed each of the use cases that everyone was assigned. Then as a team we finished the Introduction section of the SRS document by completing the purpose, document conventions, and project scope sections. Then we completed the last portion of the SRS by going over appendices and analyzing any other requirements that were not product, system, or interface related. The initial creation of the SRS document was worked on by all of the team members in a 80 minute period.
Next Week's Features/Tasks
When we met on Thursday we decided to split up most of the work needed to be completed for deliverable 2 so when we meet next the meeting would go smoothly and we could compile and review everything as necessary. The work was split up as follows:
Team meeting: Sunday at 2 p.m.
Updated schedule: Lance (Estimate of 60 minutes)
Finish detailed use cases: Eric (Estimate of 60 minutes)
Overall Description: Tom (Estimate of 60 minutes)
External Interface Requirements: Brad (Estimate of 60 minutes)
Other Nonfunctional Requirements: Mark (Estimate of 90 minutes)
This will leave the System Features section of the document to be completed during the meeting on Sunday by the entire team as it will be the longest and most in-depth part of the SRS document. We estimated it would take a total of 360 minutes to complete the feature section. During the Sunday meeting we will also complete the prototype (estimate of 120 minutes) and analysis diagrams (estimate of 60 minutes). Our overall goal is to have everything for deliverable 2 compiled, completed, and submitted by the end of the meeting. The entire team will be working on all of these tasks during this scheduled meet date.
Challenges/Issues
No issues have arised at this time. Everything is running smoothly and productively.
Saturday, April 11, 2009
Week 5 Project Progress
- Finished Deliverable 1 - As a team, we finished up the third section of the vision and scope document. This included coming up with the finalized list of the scope of initial release and formatting the list. Next, as a team, we finished section 4 of the Vision and Scope Document. Lastly, we submitted Deliverable 1 to the dropbox (This took about 2 hours).
- On Sunday, we met with the CEO of mosaically and talked with him about some of the things we had done in the past and what we were going to be doing. Later, we also asked him about some use cases that we were unsure about. Also, as a team, we discussed the list of use cases and came up with all of the use cases we though were pertinent to the project and ran them by the CEO for approval. Following that, we briefly detailed the use cases with a short description of what that use case entails. (This took about 2 hours)
- Finish Detailing Use Cases (Eric Gardan) - 1hour
- Review and approve use cases (Rest of team) - 1 hour
- Have the CEO Review and approve Use Cases (Team) - 1 hour
- Assign Use Cases priority (Team) -1 hour
- Divide the 5 top use cases for each member of the team and each person complete their respective use case (Team) - 2 hours
- Meet as a group and review the 5 use cases and make changes if necessary(Team) - 1 hour
- Review the top 5 Use Cases with CEO (Team) - 1-2 hours
- Meet as a team to discuss the weekends activities and divide work if necessary (Team) - 1 hour
- No Challenges or Issues at the moment.
Friday, April 3, 2009
Week 4 Status
Friday, March 27, 2009
Week 3 Status Report
We met a total of one times this week, on Sunday from 1:00pm to 3:00pm. In this period we accomplished the following tasks:
- Discussed what items must be completed for deliverable 1 – This task was worked on by all of the team members for a total of thirty minutes. During this time we checked what items would be due for the first deliverable and decided on the best approach to successfully complete it. This was the starting point that we chose for this project and was an appropriate area for our team to begin at.
- Began the vision and scope document – This task was worked on by all team members for approximately an hour and a half. During this time, we only worked on section one, which talked about how the product currently operates, where we want it to go, and how it competes with other systems on the market. All we wanted to complete in this document this week was enough to give each member an understanding of how the system functions. With this knowledge, each individual can apply concepts and techniques learned from class or the readings in the following week to this project. By doing this, it will allow us to diversify the thought put into the document and create a better suited collaboration of information that will be included in this project.
- None - We have yet to encounter any issues or challenges which we couldn’t deal with. The project is still in its early stages, so it is unlikely that any big problems would have erupted in such a short period.
- Complete the vision and scope document – This is the main focus of deliverable one, so it is our top priority to complete. The first section of this document has been finished, so we only have three more until it is done. I estimate that it will take us three hours to complete the remaining areas of the file with all team members working on the item together.
- Create a project schedule – This is another item that is required for deliverable one. We will be going through all of the tasks that we must complete and generate an appropriate schedule that we will use to approach the different deliverable tasks this quarter. I estimate that this task will take us one hour to complete with all team members working on the item together.
Wednesday, March 18, 2009
Deciding on a Project/Weekly Work:
1) PSP Remote Desktop Application - Mark is looking to develop a better Remote Desktop Application for the PSP than that which is currently out. Although Mark would be the primary stakeholder, the homebrew community itself is also a stakeholder, and could provide for an interesting dynamic.
2) Mosaically.com Improvement Project - This would primarily focus on improving the customer experience and adding social sharing capabilities to Mosaically.com's existing design. At the same time, it would involve removing the manual element of creating mosaics, so that it can become and easier and more enjoyable experience for users.
We were all pretty hesitant to decide on which project we wanted to work on, so after an exercise in democracy and then in unbiased decision making, we chose the Mosaically.com Improvement Project.
This week, we worked on deciding the elicitation techniques for the project. I won't post the full details here, but in general the elicitation techniques we decided on were:
Questionnaires - Easy to distribute and to manage, these could be easily given to current users of the system and focus on how the system might best be improved. By distributing the questionnaire over a medium such as a forum, we could obtain large amounts of feedback to help us determine the most important aspects that need to be improved.
Use Cases - Being that this product focuses very heavily on user interaction, use cases provide the perfect medium for specifying our requirements. We intend to start by creating a list of use case scenarios based on the information obtained from the questionnaires and talking to our primary stakeholder. As a team, we would then detail and refine each use case to best fit the needs of the user.
Study Similar Products - This is a fairly unique method of gathering requirements, since there are actually competing products we can use to compare against. We'd start by researching what competition exists and look at their feature sets. Combining this with our questionnaires and use cases, we can determine which features are most used in competing products, and tailor our improvement to these areas.
Of course, we'll also be having face-to-face meetings and e-mails with our client, but these three methods best reflected how we would obtain requirements which met the needs of both the primary stakeholder and the end user.
Non-Disclosure
Tuesday, March 17, 2009
Requirements Elicitation
Questionnaires
Use Cases
Study Similar Products
(See Activity 3.16.doc in the group locker)