End of Semester Presentation Team Trinity

  • 292 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
292
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. End of Semester Presentation Team Trinity May 12, 200 6 Minho Jeung Eun-Young Cho Kyu Hou
  • 2. Agenda
    • Project Overview
    • Architecture
    • Process
    • Lessons Learned
    • Future Plans
  • 3. Project Team
    • Team members & Roles
    • Mentors
      • Mel Rosso-Llopart (CMU)
      • Ho-jin Choi (ICU)
      • In-Young Ko (ICU)
    Process Manager, Quality Manager, Planning Manager Kyu Hou Development Manager, Customer Interface Manager Eun-Young Cho Team Leader, Risk Manager Minho Jeung
  • 4. Client
    • 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 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 Diagram Video Stream Viewer N-DVR Server OMP Administrator (Console) N-DVR Administrator (Console) OMP Control Multicast API OMP Status Multicast API OMP OMP Control Server Layer External Entity (stakeholders) Client Layer External Entity (stakeholders) OMP Interface Legend: OMP Boundary OMP Status
  • 7. Team 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 measure
    • Individual evaluation in every team meeting
    • Realistic and flexible week plan
    Balanced work load among team members - Client’s postmortem on our meetings with client Success criteria >= 4.0 (1: low - 5: high) Client satisfaction on project progress
    • Set up development plan and test plan
    Preparation for development
    • - Review with team members and mentors
    • Having consensus with client about the
    • architecture
    • - ATAM for evaluation
    Well designed architecture - SOW and SRS signed by our client Completion of SOW and SRS Measurement Detail goals
  • 8. What has been done
    • Activities and artifacts in Spring 2006 semester
      • - Agreement with client about the architecture
      • established
    May 7
      • - SOW, SRS signoff
    March 27
      • - Light weighted ATAM evaluation completed
      • - Architecture Design Documentation completed
    May 4
      • - Quality Assurance Plan completed
    May 8
      • - MOSP
    March 10
      • - SOW, SRS completed
    March 6
      • Functional and Non-functional requirements
      • gathering
    January 20 Activities Date
  • 9. Architectural 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++
    OMP Architecture
  • 10. Quality 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 View
  • 12. Project 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 Risks Mitigation Consequence Risk Mitigation Consequence Risk Mitigation Consequence Risk - Implementation time may be longer than expected - Project schedule may be delayed - The change in work place setting may affect the productivity of team members - Project schedule may be delayed ▪ Communicate with legacy system engineers frequently ▪ Customer interface manager keeps the conflict list clean 3. Integration with legacy applications (like Window Media Player) is difficult. ▪ Explain resource constraints and tradeoffs ▪ Negotiate with the client on prioritizing the set of new requirements 2. New stakeholders (new members in client group) give additional requirements on the project which the team could not anticipate. ▪ 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 1. Our team goes back to South Korea and takes time to adapt ourselves in changing workplace setting.
  • 14. Semester Postmortem
    • Client’s postmortem of weekly client meeting
    Satisfaction scale: 1  low, 5  high
    • Team members’ postmortem of weekly status meeting
    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 1/27 1/31 2/8 2/13 2/20 2/27 3/6 3/22 3/27 4/4 4/10 4/24 5/2 4/17 Average : 4.8 Average : 4.2
  • 15. Lessons Learned
    • Project 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
      • 1 st half semester: work on Saturday and Sunday
      • 2 nd half semester: work on weekday
  • 16. Lessons Learned (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 Process
    • Roles 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
    Process Manager, Quality Manager, Planning Manager Eun-Young Cho Development Manager, Customer Interface Manager Minho Jeung Team Leader, Risk Manager Kyu Hou
  • 18. Future Schedule
    • Implementation
      • Group Management
      • Algorithm
      • Command Line Interface
      • Test Program
    • Testing
      • Unit Test
      • Integration Test
      • Acceptance Test
    • Deliverables
      • Guide documentation for
      • users and administrators
      • Source code
      • Integration Test
    Jul. 24
      • Product documentation
    Aug. 7
      • Development with Unit Testing III
    Jul. 10
      • Acceptance Test
    Jul. 31
      • End of OMP Product Deliverables
    Aug. 11
      • Development with Unit Testing II
    Jun. 26
      • Development with Unit Testing I
    Jun. 12
      • Setup Environment, Presentation for POSDATA
    May. 29 Activities Date
  • 19. Thank You !
  • 20. Architectural Decision
    • Division between stream data and node configuration data
    • Using Event Bus for notifying the node configuration changes
    • Providing a Text based UI
    • Using dynamic memory for storing stream data and node information
    • Applying different communication protocol for each data type
    • Supporting dynamic nodes configuration by heart beating parent nodes
  • 21. Architecture
    • Module view
  • 22. Architecture
    • Allocation view
  • 23. QA Scenarios
    • Socket Programming vs. RPC
    • Some information from this table like the six parts have not been shown
    • Due to space constraints
    Response Time in communication between OMP server and client Attribute Concern Performance Attribute 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 Scenario 1 Tradeoff 3 3 3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory 2 2 2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style 1 1 1.Using of RPC to Socket Programming Risk Sensitivity Architectural Decision
  • 24. QA Scenarios (Cont.)
    • Explicit Invocation vs. Implicit Invocation
    Ability of OMP server to cater to many clients Attribute Concern Performance Attribute 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. Scenario 1 Tradeoff 2 3 3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory 2 2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style 1 1 1.Using of RPC to Socket Programming Risk Sensitivity Architectural Decision
  • 25. QA Scenarios (Cont.)
    • Dynamic memory vs. Static memory
    Ability of the system to address failure of data transmission between network nodes and between the OMP server and client nodes Attribute Concern Availability Attribute 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. Scenario 3 1, 2 Tradeoff 3 3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory 2 2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style 1 1 1.Using of RPC to Socket Programming Risk Sensitivity Architectural Decision
  • 26. Tradeoff Summary + + + Availability (No failure anywhere) - + + 2. Using Explicit Invocation style for managing control information in place of using the Implicit Invocation Style + - Portability (Ability to work on different platforms) - + Performance (Number of clients) - + Performance (Time or Response) 3. Using the static non volatile storage in place of the dynamic volatile storage memory 1. Using of RPC to Socket Programming Quality Attributes
  • 27. Configuration Management
  • 28. Risk 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 Mitigated Mitigating Team members are burned out
  • 29. Improvement
    • Role balancing
      • process role vs. developer
    Tech. Proc. EOSP Start Task Action Developer
  • 30. 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 project Software Architecture Architecture Design Document ATAM Analysis of Software Artifacts Static Analysis Electives (Linux, Fault Tolerant, Development Tool, Software Process ) SE knowledge Software Quality Assurance Plan Client/ Status Meeting Minutes
  • 32. Resource
    • Team OMPArchitectability
    • = Team Trinity + Team Swaran Sanghini
    • Co-work Area
    • - IEEE RFC study
    • - Artifact work
    • - Review strategy
    • - Presentation
  • 33. Risk Lists Not mitigated high critical ▪ Request equipments for test environment It is hard to set up a test environment; It might be difficult to conduct experiment. 4 5 Risk No. Not mitigated medium critical ▪ Support detailed admin guide It takes much time to educate an engineer from client company ; It might delay project schedule Status Probability Impact Mitigation Risk Statement; Consequence
  • 34. Risk Analysis
  • 35. Quality Assurance Goals 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. Testing Each application program should not have more than 10 defects per 1 KLOC found in FTR. Development The ADD should not have more than two defects per architectural representation during its formal technical review (FTR). Architecture SRS should have no more than one defects per page as per the client’s review of the SRS. Requirement gathering Goals Phase