-
Notifications
You must be signed in to change notification settings - Fork 2
Presentation Script_kks
안녕하십니까 ? 존경하는 강사님, 첫번째 마일스톤발표를 시작하겠습니다.
이 발표에서 우리는 Project Plan, Architectural drivers 분석 결과, Risks assessment and planned experiments 및 Architectural approaches에 대해 다루도록 하겠습니다.
- We will see if the design is sound enough to guide construction.
- We will evaluate when the team will be able to determine how well the design supports the architectural drivers (based on the planned activities).
- The plan should describe the overall architecture, the division of roles, the specific tasks planned, and the associated milestones.
이 발표에 앞서 Milestone 1에는 Requirement, Design constraint, Quality Attribute, ASR & Design decisions, risk 그리고 Experiments 및 Project plan등이 포함되어 있습니다.
Milestone 1에서 계획된 특정 작업들은 우리가 달성해야 할 가장 중요한 Architectural drivers 를 도출 하는 작업입니다.
또한, 도출 된 QA 요구 사항을 검증 할 수 있는 방법들을 검토하는 작업들이 있습니다. 이를 검증 하기 위한 실험들을 구체화 하고 현재 사전 테스트를 진행하고 있습니다.
- Are the QA requirements “actionable”? In other words, are they expressed in such a way that the team will be able to determine if a given design supports these drivers or not?
- Do the drivers seem to relate to the overall objectives of the project?
- Are the measures clearly derived from the overall goals of the project?
- Are the functional requirements understood?
- Is there a mechanism for prioritizing the requirements?
우선, 요구사항 부분입니다.
요구사항은 기능적 요구사항과 비기능적 요구사항으로 나눌수 있는데, 기능적 요구사항은 사용자 계정, 사용자 인터페이스, 직접통화, 회의통화, 세션관리 등으로 구성됩니다.
각 요구사항은 사용자의 계정 관리, 연락처 관리, 통화 및 회의 기능 등을 다루고 있습니다.
비기능적 요구사항으로는 performance, availability, Modifiability 에 관련된 요구사항으로 구성됩니다.
이중 아키텍처 관점에서 중요하게 고려해야할 항목을 선정하였고 선정 이유는 다음과 같습니다.
Impact는 프로젝트의 목표달성에서 얼마나 중요한 비중을 차지하는가? 고객의 만족도와 얼마나 일치하는가를 결정하는 기준이고,
Difficulty는 목표 달성과정에 얼마나 어려움이 있는가? 를 판단하는 지표입니다.
다음과 같은 비중으로 선정된 ASR은 성능 1개와 가용성 2개입니다. 각 요구사항에 만족하고 필요한 전술을 적용하기 위해 검토한 Risk와 실험에 대해 설명 드리겠습니다.
- What are the technical and non-technical risks? How do you assess each risk with respect to probability and impact in a H-M-L scale?
- Are the open questions/issues clearly related to things that will affect the outcome of the project?
- Have there been any actions identified to address the open questions/issues?
- Are the technical experiments concretely articulated?
- Is it clear what question/issue is being addressed by the experiments?
- Will it be clear when the experiments are complete?
Risks는 Non-technical risk 와 Technical risks 로 구별하였습니다.
비기술적 risk 로는 VoIP System에 대한 기술적 배경과 경험이 부족하다는 것입니다. 해당 기술을 이해하기 위해 Study를 진행하고 있습니다.
기술적 risk는 다음과 같습니다.
비디오 전송과 품질 관리를 위해 상용 open source나 library를 사용할 필요가 있다.
video conference call을 위해 Server-Client 간의 적절한 네트워크 연결방식에 대한 결정이 필요하다.
주어진 네트워크 환경은 어떠하고 어느정도의 성능을 발휘하나?
현재 환경에서 최적의 서비스 제공을 위한 가장 적합한 비디오 품질은?
지연이나 드랍을 최소화 하기 위해 수신측에서 현재 네트워크 송수신 품질이 어떠한지 알 수 있을까?
이러한 risks를 해소하기 위해 다음과 같은 실험을 통해 해소하거나 계획 수정을 진행하려고 합니다.
- What is the overview-level description of the architecture?
- What are the main architectural approaches (tactics, patterns, design strategies) in your solution?
- Are the architectural approaches clearly related to the drivers (will they likely impact the properties of interest)?
마지막으로 Architecture approaches 입니다.
저희 1팀이 검토 한 솔루션의 주요 아키텍처 접근 방식(전술, 패턴, 디자인 전략)은 다음과 같습니다.
성능 요구 사항: 오디오 및 비디오 지연을 최소화하고 통화 품질을 유지하기 위해 star topology를 사용하고 네트워크 대역폭과 비디오 품질 간의 상관 관계를 테스트하여 동적으로 비디오 품질을 조절합니다. 이를 위해 Manage work requests 전략을 사용합니다.
가용성 요구 사항: 오디오 및 비디오 지연을 최소화하고 통화 품질을 유지하기 위해 UDP 수신기 모듈에서 네트워크 지터 감지와 수신 버퍼 변경을 가능하게 합니다. 네트워크 지터에 저항하는 적절한 지터 버퍼 크기를 조정하기 위한 테스트를 진행합니다.
가용성 요구 사항: 네트워크에서 패킷/데이터 손실이 증가할 때 오디오 및 비디오 지연을 최소화하고 통화 품질을 유지하기 위해 수신기에서 패킷 손실을 감지하고 중복/재정렬을 사용하여 손실을 개선하고 복구합니다.
이러한 아키텍처 접근 방식은 성능과 가용성 요구 사항을 충족시킬수 있다고 판단하였습니다.
저희 팀은 계속해서 토론과 업데이트를 통해 더욱 구체화된 방안들을 추가할 예정입니다.
이상으로 1팀의 발표였습니다.
질문과 피드백 있으시면 말씀해주세요.