-
Notifications
You must be signed in to change notification settings - Fork 2
Milestone #2
Again, the submission can be informal documents describing the team’s current understanding of the items listed below. The mentors will be meeting with the teams to ask follow up questions.
How has the plan changed?
Has the team been actively assessing risk and updating the plan accordingly?
Does the team have a plan for any remaining significant issues/risks
Does the team have a reasonable construction plan?
- Experiment takes time due to environmental factors and more complicated experiment process than initially planned
- Additional experiments and technical analysis were conducted to satisfy the requirements.
- The roles of modules and team members have been rebalanced in the design process.
- Team 1 changed the process to register individual tasks as issues, share statuses, and update progress using GITHUB Kanban
- Project : https://github.com/users/changjurhee/projects/3/views/1
- Issues : https://github.com/changjurhee/AONE/issues
- (Availablity ASR) Apply jitter buffer for network jitter (for audio/video)
- (Availablity ASR) Apply packet duplication for netwrok packet drop (for audio)
- (Performance ASR) Apply dynamic video quality change rule for network condition changes
- (Technical RISK) Use STAR TOPOLOGY that minimizes connection links to ensure performance and availability QA in low bandwidth
- (Technical RISK) Use the proven GStreamer open source for development efficiency, stability, secured data transfer w/ plugin module.
What experiments have been conducted?
Have the results of the experiments addressed the open questions/issues?
What experiments remain?
Are the experiments focused on issues relevant to the overall goals of the system?
N | Status | Experiments | Risks / QA tracability / Issues |
---|---|---|---|
1 | Concluded | Network bandwidth measurement in operating environment | (Technical Risk) Find Video transfer throughput to meet Performance ASR within STAR topology. |
2 | Concluded | Find the correlation between network bandwidth and video quality. | (Technical Risk) Find optmal video qualitity to gurantee communiation availability (Performance QA) To make proper video bandwidth resize logics within network & participant condition |
3 | InProgress | Verify that receiver can improve network jitter problems using the jitter buffer. | (Technical Risk ) How to check and recover network jitter (Availability QA) System maintain call quality under amount of increated network jitter |
4 | InProgress | Verify that receiver can improve paket loss problems using duplication / reordering. | (Technical Risk ) How to check and recover Data drop (Availability QA) System maintain call quality under amount of increated data drop |
N | Status | Experiments | Risks / QA tracability / Issues |
---|---|---|---|
5 | Concluded | Secure session communications using TLS | Milestone #1 feedback (from Paulo) (Functional requirement)System shall transfer data for sessions between server & client in secure way. |
6 | Concluded | Measure Video/Audio latency on Network topology we decide | (Performance QA) Check additional risk for STAR Topology |
What is the architecture in terms of the organization of code units and their dependencies? (The team shall create a module view of the architecture.)
Link | Snapshot |
---|---|
First decomposition of overall architecture | |
Second decompositions for ClientUI, Server UI, SessionClient, SessionServer, Database | |
Second decompoeitions for MediaClient, MediaServer |
What is the architecture in terms of components and connectors (runtime perspective)? (The team shall create a C&C/runtime view of the architecture.)
Link | Snapshot |
---|---|
C&C view for Media Client / Media Server | |
C&C view for video quality adjistment based on network conditions |
What is the architecture in terms of the supporting infrastructure (deployment perspective)? (The team shall create a deployment view highlighting component allocation to hardware elements and communication channels.)
Link | Snapshot |
---|---|
Overall Deployment View | |
- Use STAR topology instead of MESH topology.
- We derived Performance QA as an important ASR, and based on this, we want to reduce the network occupancy rate of the entire system by reducing the number of connections based on multiple participants in order to transmit the maximum quality video in a limited bandwidth.
- We verified this from our planned experiments. (Experiment #1, Experiment #2)
- We worried about roundtrip latency but it was ok in evaluation environment (Experiment #6)
- Accepted
- System can provide much higher video quality
Have the experiments led to a refinement of the architecture?
Does the team understand the architectural approaches they have/will realize?
Do the architectural approaches align with the goals of the system?
Are there significant concerns that have not been addressed?
Has the architecture been evaluated?