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.

Week 7 Status Update

This week, we have been working to complete the final draft of our Software Requirements Specification document, This has involved finalizing our requirements and quality attributes, writing and modelling use cases and determining any remaining uncertainties. Our SRS is currently about 90% complete, as there are only a few uncertainties remaining and we have completed all sections of our SRS template. However, we have not yet had our SRS reviewed by the project stakeholders, which needs to occur before we submit it.

Project Plan:

10/1: finish first draft of SRS

10/11: finish final draft of SRS

Defects List:

• Are the customer satisfaction surveys associated with the patient who completed them or are they anonymous?

• What protocols shall our application use to communicate with the back-end servers? Is there an API it should use?
• Our requirements list could be higher level and less detailed, but then they would match our vision and scope document.

Risks:

1. We still do not know the structure and design of the remote server’s api.
2. We do not know whether the customer satisfaction survey is considered “sensitive” information or not.
3. Our SRS document has not been reviewed yet.
4. We will not have time for an in person review, so our feedback may not be as robust as it could be.
5. The due date for the Final SRS document is approaching and our sponsor, Brian, may not get back to us before we have to submit.

Week 6 Status Update

We were held up by exams and career fair and got very little work done. Now that they are over we will resume our use case document and refining our SRS document.

Next Steps:

• We will continue writing our use case document
• We will continue refining our SRS document into its final version

Week 5 Status Update

We wrote the Draft of our SRS document. All sections of the template were filled out. The document has been submitted.

Next Steps:

• We will write our use case document
• We will refine our SRS document into its final version

Week 4 Status Update

Week 4 Status Update:

This week our focus has been on end-user requirements elicitation. Although our primary contact, Brian Nofziger, has been able to tell us a little bit about what it's like to use the tablet system, we felt it would be advantageous to speak with someone who has significant experience using both the paper forms-based system of the past and the tablet-based system that Hooper Holmes is currently transitioning to. Brian was able to put us in contact with a long-time screening professional, Cindy Sucharski, who has used both systems extensively. From our interview with Cindy, we gained:

• Use cases of the paper forms system and the tablet system, with exceptions and alternate flows such as how to re-screen a patient when their information is entered correctly.
• Insight into the goals of the end users - they strive to meet a metric of 10 mins/patient
• Usability needs of the end users who are not always "tech-savvy".
• The need for easier training for screeners who have never used the tablet system before.
• More knowledge of the information which is distributed to the nurses - we thought the nurses only recieved the forms they needed to fill out for each patient, but they also recieve scripts for how to talk to the patients while they are performing their screenings.
• The pain points of the paper-based system such as the fear of losing a page of confidential patient information and the need to check every individual page on-site, even though this check could not be completed in time to re-screen patients if a mistake had been made the first time.
• Other needs of the end users which our system could meet such as the need for better statistics about how often the screeners meet their metrics (right now they only know that they "start and end on time", now how well individual screeners perform).

Our next steps are:

• Analyze and diagram our collected use cases from Brian and Cindy to ensure we have a complete picture of the system
• Write a comprehensive Software Requirements Specification.
• We will also be in touch with Brian to learn the answers to any remaining questions we may have and to present our SRS to him for review.

Week 3 Status Update

Tasks Accomplished This Week:

• Interviewed Brian Nofziger and made a list of requirements
• He was able to give us experience and information on the product from both management and end-user perspectives
• Defined the constraints of our system
• Learned about the systems outside our application that we will be interacting with
• Wrote Vision and Scope document based on requirements and business objectives covered by Brian Nofziger
• Sent Vision and Scope document to Brian for review
• Completed this blog post

Tasks for Next Week:

• Communicate with project stakeholder to go over feedback on vision and scope
• Get contact info for an end user for an additional perspective on this product

Main Objective: Requirements Confirmation

Week 2 Status Update

Project Overview / Description

    Hooper Holmes is looking to replace their current paper-based data collection methods for on-site health screenings with a software solution. The project sponsor and primary stakeholder has been secured and we will be working with him on requirement elicitation in the next week to learn more about the business and user needs.

Tasks Accomplished This Week:

• Chose a project
• Identified a primary project stakeholder (project owner) as point-of-contact
• Created a list of interview topics for project owner
• Wrote some questions related to each interview topic
• Contacted project owner to arrange an interview & request existing project documentation
• Identified some system constraints
• Created a blog

Tasks for Next Week:

Main Objective: Create Vision & Scope Document

Sub-Tasks:

• Receive what documents we can from the owner and derive interview questions from them
• Interview Brian Nofziger to learn:
• Long-term goals, success criteria & business objectives for project
• Why does this system need to be made?
• What will it enable your company to do?
• User classes & contact info of user representatives
• Who are the direct & indirect users of the system?
• How can we contact them?
• Other stakeholders & contact info
• Who are they & what is their stake in the project?
• Existing or previous systems
• Why do they need to be replaced?
      Who has used them? (contact info)
• What were the plans and requirements for the creation of these existing systems?
• How do they vary from the new requirements? (if at all)
• Existing tools or technologies that can or should be used.
• Existing documented requirements
• Constraints: deadlines, budget constraints
• Business needs esp. privacy needs
• What privacy regulations affect this project?
• Can we get documentation on them?
• Why do they exist?

Test Post

This is a test to make sure that the permissions are correct. Yeah.