A5 Assignment for streaming service, Assignments of Software Engineering

Streaming war application requirement

Typology: Assignments

2020/2021

Uploaded on 02/03/2022

karthick-mp
karthick-mp 🇺🇸

5 documents

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS6310 – Software Architecture & Design
Assignment #5 [150 points]: Streaming Wars Project – Architecture & Design (v1)
Spring Term 2021 – Instructor: Mark Moss
Submission
This assignment must be completed as part of an approved group.
One member of each team must submit the justifications for the proposed project modifications
[40 + 40 + 50 = 130 points], along with the technical deployment plans [20 points], in a file labeled
group_proposals.pdf.
Submit your answers via Canvas.
You must notify us via a private post on Piazza BEFORE the Due Date if you are encountering
difficulty submitting your project. You will not be penalized for situations where Canvas is
encountering significant technical problems. However, you must alert us before the Due Date –
not well after the fact.
Problem Scenario
The clients are excited about your work so far as you enter the final phase of the project. Given the
time you’ve spent studying the problem space, the clients are now offering you the opportunity to
propose changes to the system that will improve its overall effectiveness. During this phase, you will
work with your teammates to identify and plan three (3) significant architectural improvements to the
system, and you will implement those improvements during the following phase(s) of the project.
During this phase, you will work with your teammates to plan at least three (3) significant architectural
improvements to the system, and you will implement those improvements during the following
phase(s) of the project. The architectural areas of consideration are listed below. One of them will be
randomly selected for your team, and you can select the other two. You can view the area that was
selected for your team by viewing the
A5 Architectural Criteria
spreadsheet under
PostEm
in Canvas.
Disclaimer
This scenario has been developed solely for this course. Any similarities or differences between this
scenario and any of the programs at Georgia Tech programs are purely coincidental.
Deliverables
This project phase requires you to submit the following items:
Project Modifications [130 points total: 40 points each for the two architectural areas of consideration
that you've selected, and 50 points for the one area that was randomly selected for your team.]
Submit your proposed project modifications in a file labeled group_proposals.pdf. The file
should contain one approx. six to twelve (~6-12) sentence description for each modification using
an ADR format. Each modification should represent some significant change to the way the
current project operates as compared to the version that you implemented in the previous
assignment. This isn’t intended to be an extensive writing exercise, but rather an opportunity to
ensure that you’ve considered the potential architectural, design and implementation challenges
of your proposals.
pf3
pf4
pf5

Partial preview of the text

Download A5 Assignment for streaming service and more Assignments Software Engineering in PDF only on Docsity!

CS 6310 – Software Architecture & Design Assignment # 5 [ 150 points]: Streaming Wars Project – Architecture & Design (v 1 ) Spring Term 2021 – Instructor: Mark Moss Submission

  • This assignment must be completed as part of an approved group.
  • One member of each team must submit the justifications for the proposed project modifications [40 + 40 + 50 = 130 points], along with the technical deployment plans [20 points], in a file labeled group_proposals.pdf.
  • Submit your answers via Canvas.
  • You must notify us via a private post on Piazza BEFORE the Due Date if you are encountering difficulty submitting your project. You will not be penalized for situations where Canvas is encountering significant technical problems. However, you must alert us before the Due Date – not well after the fact. Problem Scenario The clients are excited about your work so far as you enter the final phase of the project. Given the time you’ve spent studying the problem space, the clients are now offering you the opportunity to propose changes to the system that will improve its overall effectiveness. During this phase, you will work with your teammates to identify and plan three (3) significant architectural improvements to the system, and you will implement those improvements during the following phase(s) of the project. During this phase, you will work with your teammates to plan at least three (3) significant architectural improvements to the system, and you will implement those improvements during the following phase(s) of the project. The architectural areas of consideration are listed below. One of them will be randomly selected for your team, and you can select the other two. You can view the area that was selected for your team by viewing the A5 Architectural Criteria spreadsheet under PostEm in Canvas. Disclaimer This scenario has been developed solely for this course. Any similarities or differences between this scenario and any of the programs at Georgia Tech programs are purely coincidental. Deliverables This project phase requires you to submit the following items: Project Modifications [130 points total: 40 points each for the two architectural areas of consideration that you've selected, and 50 points for the one area that was randomly selected for your team.]
  • Submit your proposed project modifications in a file labeled group_proposals.pdf. The file should contain one approx. six to twelve (~ 6 - 12) sentence description for each modification using an ADR format. Each modification should represent some significant change to the way the current project operates as compared to the version that you implemented in the previous assignment. This isn’t intended to be an extensive writing exercise, but rather an opportunity to ensure that you’ve considered the potential architectural, design and implementation challenges of your proposals.

Submit your proposed project modifications in a file labeled group_proposals.pdf. The file should contain one Architectural Decision Record (ADRs) for each modification. ADRs are discussed in more depth in Chapter 19 of Fundamentals of Software Architecture (Ford & Richards, O'Reilly 2020). Also, here are some links that contain more examples of, and details about, ADRs and the process: https://adr.github.io/ https://www.ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html https://medium.com/olzzio/y-statements-10eb07b5a Planned Technical Deployment [ 20 points] (^) Provide a brief description (~4-12 sentences) of the languages, systems and related technologies that you're planning to use – or at least seriously considering using – to implement and deploy your final system (A6). We don't expect a comprehensive list of every single library or package that might be included, but we do want you to be proactive on letting us know your most likely plan for implementation. We give you a relatively wide latitude with the technologies that you can select for the final project, but you must coordinate your choices with your designated grading TA to ensure that they will be able to interact with and evaluate your final submission thoroughly. The TAs have "final approving authority" for technology selections. Please include your "Planned Technical Deployment" content as the last portion of the group_proposals.pdf document.

  • "Significant" in this case means that there must be some clear and substantial level of effort that is needed to modify the current design and codebase in order to implement your proposed modifications. The primary things that we will look for when evaluating your proposals are: o Clear identification of the modifications that you will be making. The best way to do this is to use a basic reference architecture for your comparison, such as a relatively simple solution to Assignment 4. o Presentation of a relatively strong case of how your modifications will improve the system. For performance-based changes, you can show how the improved system will outperform the basic system - either in theory, or with real data and testing, or both. For other situations, you can present a sequence of actions that highlight how the basic system fails to provide the needed properties, while the improved system overcomes these issues. o Finally, presenting a strong case for your proposals doesn't mean that you have to avoid any discussion of trade-offs. It's perfectly acceptable to highlight the strengths of your proposals while also discussing some of the difficulties, to include how improving some of the system properties can also have an adverse impact on others.
  • You should also review Heilmeier’s Catechism below for some issues and considerations that you can address to strengthen your proposal descriptions. These questions are credited to George Heilmeier and are relevant when evaluating research projects or product development efforts. You can find more details about Heilmeier’s Catechism at the following link: https://en.wikipedia.org/wiki/George_H._Heilmeier o What are you trying to do? Articulate your objectives using absolutely no jargon. Describe the proposed improvement in a clear and concise manner.

Robustness: Ability to handle error and boundary conditions while running if the internet connection goes down or if there’s a power outage or hardware failure. There have not been many error handling requirements so far. This is an opportunity to improve the error handling of the system and much more. Consider the possibility of the program crashing – for example, power being lost – while executing a program run. How would you modify the system to allow your system to resume execution after such an event without major delays, data corruption, etc.? Configurability: Ability for the end users to easily change aspects of the software’s configuration (through usable interfaces). We implemented a relatively simple Command Line Interface in earlier assignments, so this is an opportunity not only to generate a better, richer interface, but also to address things like the ability to set the starting month and date of the program run instead of hardcoding it into the program. Similarly, the implementation of some of your other architectural and design changes might create other configuration parameters that need to be changed. How would you modify the system to allow users to manage these configuration parameters as easily as possible? Archivability: Will the data need to be archived or deleted after a period of time? (For example, customer accounts are to be deleted after three months or marked as obsolete and archived to a secondary database for future access.) Suppose that the data that is being collected and analyzed must be stored for a certain period of time. This might be driven by a legal requirement, a policy requirement, or a technical limitation, but either way the system must be implemented to manage the storage of this information. And, in some cases, there must also be ways to ensure that the information is purged after a certain amount of time. This next group of architectural concepts is "intertwined" in that it's difficult to consider one of them in isolation, because implementing one of them effectively all but requires that you consider the impacts (and dependencies) on the others. I'm listing all of these terms here as a "bundle", but you may select and implement two or three of them as permitted by the assignment instructions. Authentication: Security requirements to ensure users are who they say they are. Authorization: Security requirements to ensure users can access only certain functions within the application (by use case, subsystem, webpage, business rule, field level, etc.). Authentication and authorization are often essential if you're going to enforce any kind of security and/or privacy protocols. Privacy: Ability to hide transactions from internal company employees (encrypted transactions so even DBAs and network architects cannot see them).

Security: Does the data need to be encrypted in the database? Encrypted for network communication between internal systems? What type of authentication needs to be in place for remote user access? Also, the public has become much more aware of the need for data privacy, and there are various things that can be done to ensure that user's data – especially medically and/or financially sensitive data – is accessed only by authorized users for its intended purposes. *Auditability: Ability to track the "activity records" (e.g., which commands were executed by a user) in such a way that a user's activity records can only be reviewed by personnel in appropriate roles, such as a Security Administrator; and, that a user cannot remove or otherwise corrupt their own activity records. *I included this one from other sources including my own personal experience. The unifying theme of all of these architectural considerations is making the system more "trustworthy" against the case of deliberate, adversarial threats as well as accidental, non-adversarial issues that might corrupt the data and/or operations of the system. How would you modify the system to improve its overall level of trustworthiness? Additional Functional Requirements As mentioned in the previous assignment, we are additional functionality primarily to allow the updating and deletion of certain elements of the system. [ 13 ] update_demo,,, This command must update the attributes of the demographic group with the corresponding short name. The short name itself cannot be changed; and, if the short name does not exist, then the command should be considered invalid. The number of accounts can be changed only at the beginning of a time period before that specific demographic group has accessed and viewed any movies or Pay-Per-View events. [14] update_event,,,, This command must update the attributes of the movie or Pay-Per-View event with the corresponding name and year produced. The name and the year produced cannot be changed; and, if the combination of the name and year produced does not exist, then the command should be considered invalid. The license fee can be changed only at the beginning of a time period before that specific movie or Pay-Per-View event has been accessed and viewed any demographic groups. [15] update_stream,,, This command must update the attributes of the streaming service with the corresponding short name. The short name itself cannot be changed; and, if the short name does not exist, then the command should be considered invalid. The subscription price can be changed only at the beginning of a time period before that specific streaming service has not been used to access and view any movies.