Week 14 Status Update

We have returned from thanksgiving break rested and exhausted of our gratitude. We decided to kick off with analyzing the feedback we received on our API design activity and incorporating the results into the final draft of our Software Architecture Documentation. Otherwise we will be looking over our final draft a little further so as to catch any issues and refine our wording.

Last week we completed our final view (Process) and finished up our tactics list. At the moment our project deliverable is in a completed state and our current efforts are around refining it further. We are concerned with the risk of being complacent with the work we have completed and are attempting to mitigate that by forcing meetings together where we analyze the document repeatedly.

Week 13 Status Update

Thanksgiving Week

We decided to take this week to go home and reflect with our families to give proper thanks for all that we have learned within Software Requirements and Architecture in the form of a familial feast. We also wanted to honor Jurgin a little further for being the masterful Mathematician who checked our documents before his untimely demise.

Week 12 Status Update

This week, we began work on a Process View for the Health Pro architecture. Our intent is to use this view to show the runtime behavior of our system and how the different subsystems interact dynamically to perform our application's use cases under different constraints. We created a flowchart which shows how the flow of control passes between the subsystems of our application as well as a sequence diagram which documents how completed forms are saved with and without a secure network connection. We also documented the rationale for the decisions included in our Process view. Next week we will complete the Process view by adding sequence diagrams for the other use cases and additional documentation. We also completed an allocation view this week and documented it as well.
Our other primary achievement this week was completing an ATAM evaluation in class. We received a lot of useful feedback on our system, including tips on which security tactics we might want to use and which parts of our design were ambiguous and needed clarification. The most important thing we learned is that we do not currently have many design tactics included in our architecture. Therefore this will be a focus of our efforts over the next two weeks as we continue to develop our architecture. This weekend we will be independently reviewing design tactics in preparation for a tactics-brainstorming session next Monday.

Week 11 Status Update

We took the module views we had made and created the High Level Architecture View. We also combined the element catalogs into one unified list. Then we proceeded to fill out the Variability Guide and the Rationale.

We submitted our Draft.

Next Steps:

• Create Sequence diagram(s) for the Process View
• Create an unfortunately minimal Allocation View
• Finish our Architecture Overview's View Intro and Pattern/Tactic Rationale

Week 10 Status Update

We began working on the Software Architecture Document by completing the the Introduction, Background, Requirements, and Quality Attributes. At the end of the week we created an Architecture Overview "big picture" diagram.

We have also divided the design of each module to different team members that will culminate next week in the High Level Architecture View.

Next Steps:

• We will each flesh out our respective submodules with a class diagram and element catalog.
• We will create the HLAV from the resulting diagrams
• We will finish a unified element catalog
• Submit Draft

Week 9 Status Update

No significant work performed this week. We were sad this week. Emotion levels were low, so we took a break. We were mourning the loss of Jurgen Essig.


Oh Jurgen, we hardly knew him.

Next Steps:

• Begin working on the Software Architecture Document (SAD)

Week 8 Status Update

This week, we contacted our project stakeholder to review our SRS and use cases. We collected his feedback on these artifacts, discussed it as a group and updated our SRS and use cases to reflect his input. We also identified a lack of requirements to address the business needs of faster information turnaround and customer-facing services and discussed this with our stakeholder to come up with some new requirements for our application which would meet these needs. We then added these new requirements to our SRS.
Additionally, we wrote a postmortem analysis of the first stage of the project and discussed our project's feasibility for the next stage. We decided that our project was architecturally complex enough to be a good candidate for the next stage and decided to keep using it for the architecture phase of this class. We discussed and listed the architecturally significant requirements of our project.
Next week, we will begin work on our architecture. At this time, we have not studied the architecture process enough to know exactly how to begin, but we hope to learn more in next week's classes. We will probably begin by making more detailed class and sequence diagrams.