Team 3: Gurgle Earth
From SoftwarePractice.org
Contents |
[edit]
Team 3 Members
| Name | Student Number |
| Petter Nguyen | 10175230 |
| Rahmani Guler | 10152698 |
| Jimmy Ly | 10046819 |
| Ji-Woong Park | 00031423 |
[edit]
Team Discussion
For team discussions and logs click here
[edit]
Assessments
Milestone 1: Software Architecture Document (click here)
Milestone 2: Software Architecture Document (click here)
[edit]
Instructor comments
The two stakeholder narratives you have written are fine. More please! Note that quality narratives focus on a particular quality attribute and don't need to be related to stakeholder or users. Choose TWO top priority quality attribute. Lian 26th March
Milestone 1 Feedback Your analysis and initial architectural design is quite good, but please take note of the following comments:
- Stakeholder and usage narratives are well done. You have identified a wide range of users.
- The quality narratives should really express the desired quality requirements and provide measures of these. What you have written are concerns about quality attributes, which are useful as a starting point, but are not quite what was expected. Also I am not sure whether Reliability was such a good choice as a top priority quality attribute for this system. I don't think the system is that critical - it does not control anything that may have a severe negative impact. The key characteristics of the system are more to do with the bulk and distribution of different kinds of data, the integrity of the data (which you have noted), and the analysis of all this data to find patterns and trends.
- Following on from the last point, your Conceptual Architecture is quite reasonable, except that it is missing a key component to do with analysis of data, and a related presentation component for patterns and trends.
- On CA, better to show the specific kinds of hardware devices connected to external interface so you can see the different kinds of data and protocols required.
- Good to see the evolution of your CA and application of use case maps. However, you could improve your documentation of the use case maps by making sure you state which component performs which responsiblity AND concluding from each UCM what decisions you have made or things that need to change. For example, on the ModifyData trace, what about a return trace back to Administration to confirm the change?
- Missing lifecycle events on UCMs
- Not convinced about your Execution Architecture. Why does the Data Sorting component have both the External Hardware and Internal Data Entry interfaces connected to it? Don't they have quite different processing needs? There could be a large amount of data coming in from the satellites, smart dust sensors, etc. Consider the frequency of incoming data as well. You should show replication of components if reliability is a concern.
- Implementation architecture is okay at this stage, except it seems to be missing the components for analysis and bulk of data processing.
Lian 26th April
