end of semester presentation team trinity

End of Semester PresentationEnd of Semester PresentationTeam Trinity

May May 12,12, 200 20066

Minho JeungMinho JeungEun-Young ChoEun-Young Cho

Kyu HouKyu Hou

2

AgendaAgenda

Project Overview Architecture Process Lessons Learned Future Plans

3

Project Overview ProcessArchitecture Lessons Learned Future Plans

Project TeamProject Team

Team members & Roles

Mentors•Mel Rosso-Llopart (CMU)•Ho-jin Choi (ICU)•In-Young Ko (ICU)

Minho Jeung Team Leader, Risk Manager

Eun-Young Cho

Development Manager, Customer Interface Manager

Kyu HouProcess Manager, Quality Manager, Planning Manager

4


ClientClient

Company introduction• POSDATA: An IT service provider

established in 1989 by Korean steel giant POSCO * POSCO is one of the largest steel makers in the world.

• POSDATA’s business area• System Integration, Network Integration• Consulting, Outsourcing• Digital Video Recorder (DVR), Portable Internet

• Contact point: Seong-Yong Choi

5


Project IntroductionProject Introduction

Business driver• Solve the network congestion problem

that occurs when many clients attempt to view the video stream at the same time

Project goal• Apply Overlay Multicast Protocol (OMP) to

the N-DVR Server in order to provide efficient video streaming to clients

* N-DVR: Next Generation Digital Video Recorder

6


Context DiagramContext Diagram

Video Stream Viewer

N-DVRServer

OMPAdministrator

(Console)

N-DVR Administrator

(Console)

OMP Control

MulticastAPI

OMP Status

Multicast API

OMPOMP Control

Server Layer External Entity(stakeholders)

Client LayerExternal Entity(stakeholders)

OMP Interface

Legend:

OMP Boundary

OMP Status

7


Team GoalsTeam Goals

Team Goal in Spring 2006 semester• Self-confidence among team members in the our project• Cohesive work with client for meeting client satisfaction

How to measureDetail goalsDetail goals MeasurementMeasurement

Completion of SOW and SRS

- SOW and SRS signed by our client

Well designed architecture

- Review with team members and mentors- Having consensus with client about the architecture- ATAM for evaluation

Preparation for development

- Set up development plan and test plan

Balanced work load among team members

- Individual evaluation in every team meeting- Realistic and flexible week plan

Client satisfaction on project progress

- Client’s postmortem on our meetings with client Success criteria >= 4.0 (1: low - 5: high)

8


What has been doneWhat has been done Activities and artifacts in Spring 2006 semester

DateDate ActivitiesActivities

January 20

- Functional and Non-functional requirements gathering

March 6 - SOW, SRS completed

March 10 - MOSP

March 27 - SOW, SRS signoff

May 4 - Light weighted ATAM evaluation completed- Architecture Design Documentation

completed

May 7 - Agreement with client about the architecture

established

May 8 - Quality Assurance Plan completed

9


Architectural DriversArchitectural Drivers

Quality Attributes - Performance - Availability - Modifiability - Security - Portability

Functional Requirements - Group Configuration - Member Configuration - Multicast Routing - Data Replication

Technical Constraints - OMP Server’s OS: Linux - Client’s OS: Window 2000 or XP - Language: C++

OMPArchitecture

10


Quality AttributesQuality Attributes Three major quality attributes

• Performance• A client should be able to watch the video

stream within 5 seconds of the request for the stream

• Availability• The N-DVR server tries to reestablish the

transmission of video stream between the appropriate client nodes when it detects failure on communication

• Modifiability• When a developer wants to add security, the

modification is made with no side effects so that no irrelevant components are changed

11


Architecture – C&C ViewArchitecture – C&C View

Parent Node

Server

Node Information

StreamController

NodeHandler

StreamAcceptor

Storage

Memory Connector

(Stream Buffer)

DynamicMemory

ComponentPhysicalBoundary

0..N

StreamBuffer

ViewerConnector

Child Node

Parent NodeChecker Stream

Controller

Node Information

StreamBuffer

ViewerAdapter

Event Bus

ServerCommunicator

NodeConfiguration

Manager

Parent NodeChecker

StreamController

Node Information

StreamBuffer

ViewerAdapter

Event Bus

ServerCommunicator

NodeConfiguration

Manager

NodeFinder

ViewerConnector

Memory Connector(Node Info)

Event Bus

Event Bus

Viewer

Viewer

Digital Video Converter

Project Scope

0..N

0..N

Legend

Console

TCPConnector

UDPConnector

Publisher

Subscriber

OMPHandler

ConfiguratioFile

Call-returnConnector

ExternalConnector

12


Project ProcessProject Process

Tailored TSPi action• Role• Weekly-based work plan• Architecture evaluation

Configuration Management• Document review process

Risk Management• Weekly based risk meeting

Knowledge Acquisition Process• Internet Engineering Task Force (IETF) standard

study• Academic OMP product research

13


Top Three RisksTop Three Risks

Risk1. Our team goes back to South Korea and takes time to adapt ourselves in changing workplace setting.

Consequence

- The change in work place setting may affect the productivity of team members- Project schedule may be delayed

Mitigation▪ Plan for work includes time to adapt in changing workplace setting▪ Set up the exact launching time (May 29)▪ Share summer schedule with the client before going back to ICU

Risk2. New stakeholders (new members in client group) give additional requirements on the project which the team could not anticipate.

Consequence

- Project schedule may be delayed

Mitigation▪ Explain resource constraints and tradeoffs▪ Negotiate with the client on prioritizing the set of new requirements

Risk3. Integration with legacy applications (like Window Media Player) is difficult.

Consequence

- Implementation time may be longer than expected

Mitigation▪ Communicate with legacy system engineers frequently ▪ Customer interface manager keeps the conflict list clean

14


Semester PostmortemSemester Postmortem

Client’s postmortem of weekly client meeting

Satisfaction scale: 1 low, 5 high

Team members’ postmortem of weekly status meeting

0

1

2

3

4

5

2/2 2/6 2/13

2/20

2/26

3/6 3/13

3/20

3/27

4/10

4/17

4/24

5/8

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

1/27

1/31

2/82/13

2/20

2/27

3/6 3/22

3/27

4/4 4/10

4/24

5/24/17

Average : 4.8 Average : 4.2

15


Lessons LearnedLessons LearnedProject started late

• Active attitude toward studio project• Need intensive communication with client

Research intensive project• Put efforts for researching relative technology • Hard to choose best algorithm that are

appropriate for the project • Q&A with experts via email helps us

Studio work adjustment• 1st half semester: work on Saturday and

Sunday• 2nd half semester: work on weekday

16


Lessons Learned Lessons Learned (Cont.)(Cont.)

Handling burn-out in team members• Getting stressed due to work burden and

not focusing on the work is a symptom of burn-out

• Refresh and relax time is necessary when it happens

Efficient work• Lack of sleep does not help work

efficiency• Shifting work hours to daytime would be

better

17


Future ProcessFuture ProcessRoles change

Implementation•Tailored pair-programming•Biweekly iteration

Testing•Testing strategy based on Software Quality Assurance Plan•Testing under client environment

Delivery•Work with a software engineer from client for system management

Kyu Hou Team Leader, Risk Manager

Minho JeungDevelopment Manager, Customer Interface Manager

Eun-Young Cho

Process Manager, Quality Manager, Planning Manager

18


Future ScheduleFuture ScheduleImplementation

• Group Management Algorithm• Command Line Interface• Test Program

Testing• Unit Test• Integration Test• Acceptance Test

Deliverables• Guide documentation for users and administrators• Source code

DateDate ActivitiesActivities

May. 29

Setup Environment, Presentation for POSDATA

Jun. 12 Development with Unit Testing I

Jun. 26 Development with Unit Testing II

Jul. 10 Development with Unit Testing III

Jul. 24 Integration Test

Jul. 31 Acceptance Test

Aug. 7 Product documentation

Aug. 11

End of OMP Product Deliverables

19


Thank You !Thank You !

20


Architectural DecisionArchitectural Decision Division between stream data and node

configuration dataUsing Event Bus for notifying the node

configuration changesProviding a Text based UIUsing dynamic memory for storing

stream data and node informationApplying different communication

protocol for each data type Supporting dynamic nodes configuration

by heart beating parent nodes

21


ArchitectureArchitecture

Module view

Security Utilities

Node info communication Utilities

Stream Data Transmission Utilities

TCP UDP

OMP Interface

Legacy Applications

Node ManagementUser Interface

Network

Node Configuration Utilities

Node info communication Utilities

Stream Data Transmission Utilities

TCP UDP

OMP Interface

Network

Node Configuration Utilities

Viewer Applications Viewer Applications Join Request User Interface

Internet

Layer (Project Scope)

Legend

Layer (Out of Scope) Data Transmission

Server Client

Security Utilities

22


Architecture Architecture

Allocation view

23


QA ScenariosQA Scenarios

Socket Programming vs. RPC

Scenario

A video stream (internal) event is sent from the OMP server to the client during normal conditions. The client receives the video stream within 5 seconds of its dispatch from the OMP server

Attribute Performance

Attribute Concern

Response Time in communication between OMP server and client

Architectural Decision Sensitivity Tradeoff Risk

1.Using of RPC to Socket Programming 1 1 1

2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style

2 2

3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory

3 3

•Some information from this table like the six parts have not been shown•Due to space constraints

24


QA Scenarios (Cont.)QA Scenarios (Cont.)

Explicit Invocation vs. Implicit Invocation

Scenario

A video stream (internal) event is sent from the OMP server to a number of clients during normal conditions. The number of clients receiving the video stream are predefined number 100 from the OMP server using the maximum available bandwidth with 11 Mbps.

Attribute Performance

Attribute Concern

Ability of OMP server to cater to many clients


1.Using of RPC to Socket Programming 1 1 1


2


3 2

25


QA Scenarios (Cont.)QA Scenarios (Cont.)

Dynamic memory vs. Static memory

Scenario

An unanticipated failure of transmission message is received at the OMP server (informing that link (s) may be broken or a video stream data could not be sent between client nodes) during normal operation. The OMP server tries to reestablish the transmission of video stream between the appropriate client nodes within 5 seconds and logs the failure of transmission message with performance information and continues in normal mode.

Attribute Availability

Attribute Concern

Ability of the system to address failure of data transmission between network nodes and between the OMP server and client nodes


1.Using of RPC to Socket Programming 1 1, 2 1


2


3 3

26


Tradeoff SummaryTradeoff Summary

Quality Attributes

1. Using of RPC to Socket Programming

2. Using Explicit Invocation style for managing control information in place of using the Implicit Invocation Style

3. Using the static non volatile storage in place of the dynamic volatile storage memory

Performance (Time or Response)

++ ++ --

Performance (Number of clients)

++ ++ --

Availability (No failure anywhere)

++ ++ ++

Portability (Ability to work on different platforms)

-- -- ++

27


Configuration ManagementConfiguration Management

28


Risk ListsRisk Lists

January February March April May

Client's requirements are ambiguous

Team members lack domain knowledge

Our team needs to have the time to adapt ourselves in changing workplace

Inefficient communication because of the difference of time and distance with client

MitigatedMitigating

Team members are burned out

29


Improvement Improvement

Role balancing• process role vs. developer

Tech.Proc.

EOSP

Start

TaskActionDeveloper

30


Improvement (Cont.)Improvement (Cont.)

Distant Client Meeting• MSN video conferencing• Time saving: 2 hr 1 hr• Meeting time: Monday 10 am – 11 am

(Seoul) Sunday 9 pm – 10 pm (Pittsburgh)

31


Application to the projectApplication to the project

SoftwareArchitecture

ArchitectureDesign Document

ATAM

Analysis of Software Artifacts

Static Analysis

Electives(Linux,Fault Tolerant, Development Tool,Software Process )

SE knowledge

SoftwareQualityAssurancePlan

Client/StatusMeetingMinutes

32


ResourceResource

•Team OMPArchitectability = Team Trinity + Team Swaran Sanghini

• Co-work Area- IEEE RFC study- Artifact work- Review strategy- Presentation

33


Risk ListsRisk Lists

Risk No.

Risk Statement; Consequence

MitigationImpact

Probability

Status

4 It is hard to set up a test environment; It might be difficult to conduct experiment.

▪ Request equipments for test environment

critical high Not mitiga

ted

5 It takes much time to educate an engineer from client company ; It might delay project schedule

▪ Support detailed admin guide

critical medium Not mitiga

ted

34


Risk AnalysisRisk Analysis

9

5

4

MitigatedMitigatingNot mitigated

35


Quality Assurance GoalsQuality Assurance Goals

Phase Goals

Requirement gathering

SRS should have no more than one defects per page as per the client’s review of the SRS.

Architecture The ADD should not have more than two defects per architectural representation during its formal technical review (FTR).

Development Each application program should not have more than 10 defects per 1 KLOC found in FTR.

Testing All tested work products should be checked for finding at least one defect per page or 10 defects per 1 KLOC of codes in FTR.

end of semester presentation team trinity

Documents

client group

meeting client satisfaction

team goals team goal

high client satisfaction

client completion of

studio project

project progress

c omp architecture