End of Semester Presentation Team Trinity
Transcript of 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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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 Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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 Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
Thank You !Thank You !
20
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
Architecture Architecture
Allocation view
23
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
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
3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory
3 2
25
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Architectural Decision Sensitivity Tradeoff Risk
1.Using of RPC to Socket Programming 1 1, 2 1
2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style
2
3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory
3 3
26
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
Configuration ManagementConfiguration Management
28
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
Improvement Improvement
Role balancing• process role vs. developer
Tech.Proc.
EOSP
Start
TaskActionDeveloper
30
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
ResourceResource
•Team OMPArchitectability = Team Trinity + Team Swaran Sanghini
• Co-work Area- IEEE RFC study- Artifact work- Review strategy- Presentation
33
Project Overview ProcessArchitecture Lessons Learned Future Plans
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
Project Overview ProcessArchitecture Lessons Learned Future Plans
Risk AnalysisRisk Analysis
9
5
4
MitigatedMitigatingNot mitigated
35
Project Overview ProcessArchitecture Lessons Learned Future Plans
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.