0
End of Semester Presentation Team Trinity May  12,  200 6   Minho Jeung Eun-Young Cho Kyu Hou
Agenda <ul><li>Project Overview </li></ul><ul><li>Architecture </li></ul><ul><li>Process </li></ul><ul><li>Lessons Learned...
Project Team <ul><li>Team members & Roles </li></ul><ul><li>Mentors </li></ul><ul><ul><li>Mel Rosso-Llopart (CMU) </li></u...
Client <ul><li>Company introduction </li></ul><ul><ul><li>POSDATA: An IT service provider established in    1989 by Korean...
Project Introduction <ul><li>Business driver </li></ul><ul><ul><li>Solve the network congestion problem that occurs when m...
Context Diagram Video Stream Viewer N-DVR Server OMP Administrator (Console) N-DVR  Administrator (Console) OMP Control Mu...
Team Goals <ul><li>Team Goal in Spring 2006 semester </li></ul><ul><ul><li>Self-confidence among team members in the our p...
What has been done <ul><li>Activities and artifacts in Spring 2006 semester </li></ul><ul><ul><li>- Agreement with client ...
Architectural Drivers Quality Attributes  -  Performance  - Availability  - Modifiability - Security  - Portability  Funct...
Quality Attributes <ul><li>Three major quality attributes </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><ul><li...
Architecture – C&C View
Project Process <ul><li>Tailored TSPi action </li></ul><ul><ul><li>Role </li></ul></ul><ul><ul><li>Weekly-based work plan ...
Top Three Risks Mitigation Consequence Risk Mitigation Consequence Risk Mitigation Consequence Risk - Implementation time ...
Semester Postmortem <ul><li>Client’s postmortem of weekly client meeting </li></ul>Satisfaction scale: 1   low, 5   high...
Lessons Learned <ul><li>Project started late </li></ul><ul><ul><li>Active attitude toward studio project </li></ul></ul><u...
Lessons Learned (Cont.) <ul><li>Handling burn-out in team members </li></ul><ul><ul><li>Getting stressed due to work burde...
Future Process <ul><li>Roles change </li></ul><ul><li>Implementation </li></ul><ul><ul><li>Tailored pair-programming </li>...
Future Schedule <ul><li>Implementation </li></ul><ul><ul><li>Group Management </li></ul></ul><ul><ul><li>Algorithm </li></...
Thank You !
Architectural Decision <ul><li>Division between stream data and node configuration data </li></ul><ul><li>Using Event Bus ...
Architecture <ul><li>Module view </li></ul>
Architecture  <ul><li>Allocation view </li></ul>
QA Scenarios <ul><li>Socket Programming vs. RPC </li></ul><ul><li>Some information from this table like the six parts have...
QA Scenarios (Cont.) <ul><li>Explicit Invocation vs. Implicit Invocation </li></ul>Ability of OMP server to cater to many ...
QA Scenarios (Cont.) <ul><li>Dynamic memory vs. Static memory </li></ul>Ability of the system to address failure of data t...
Tradeoff Summary + + + Availability (No failure anywhere) - + + 2. Using Explicit  Invocation style for managing control  ...
Configuration Management
Risk Lists January February March April May Client's requirements are ambiguous Team members lack domain knowledge Our tea...
Improvement  <ul><li>Role balancing </li></ul><ul><ul><li>process role vs. developer </li></ul></ul>Tech. Proc. EOSP Start...
Improvement (Cont.) <ul><li>Distant Client Meeting </li></ul><ul><ul><li>MSN    video conferencing </li></ul></ul><ul><ul...
Application to the project Software Architecture Architecture Design  Document ATAM Analysis of  Software  Artifacts Stati...
Resource <ul><li>Team OMPArchitectability  </li></ul><ul><li>= Team Trinity + Team Swaran Sanghini   </li></ul><ul><li>Co-...
Risk Lists Not mitigated high critical ▪  Request equipments for test environment It is hard to set up a test environment;...
Risk Analysis
Quality Assurance Goals All tested work products should be checked for finding at least one defect per page or 10 defects ...
Upcoming SlideShare
Loading in...5
×

End of Semester Presentation Team Trinity

320

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
320
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "End of Semester Presentation Team Trinity"

  1. 1. End of Semester Presentation Team Trinity May 12, 200 6 Minho Jeung Eun-Young Cho Kyu Hou
  2. 2. Agenda <ul><li>Project Overview </li></ul><ul><li>Architecture </li></ul><ul><li>Process </li></ul><ul><li>Lessons Learned </li></ul><ul><li>Future Plans </li></ul>
  3. 3. Project Team <ul><li>Team members & Roles </li></ul><ul><li>Mentors </li></ul><ul><ul><li>Mel Rosso-Llopart (CMU) </li></ul></ul><ul><ul><li>Ho-jin Choi (ICU) </li></ul></ul><ul><ul><li>In-Young Ko (ICU) </li></ul></ul>Process Manager, Quality Manager, Planning Manager Kyu Hou Development Manager, Customer Interface Manager Eun-Young Cho Team Leader, Risk Manager Minho Jeung
  4. 4. Client <ul><li>Company introduction </li></ul><ul><ul><li>POSDATA: An IT service provider established in 1989 by Korean steel giant POSCO * POSCO is one of the largest steel makers in the world. </li></ul></ul><ul><ul><li>POSDATA’s business area </li></ul></ul><ul><ul><ul><li>System Integration, Network Integration </li></ul></ul></ul><ul><ul><ul><li>Consulting, Outsourcing </li></ul></ul></ul><ul><ul><ul><li>Digital Video Recorder (DVR), Portable Internet </li></ul></ul></ul><ul><ul><li>Contact point: Seong-Yong Choi </li></ul></ul>
  5. 5. Project Introduction <ul><li>Business driver </li></ul><ul><ul><li>Solve the network congestion problem that occurs when many clients attempt to view the video stream at the same time </li></ul></ul><ul><li>Project goal </li></ul><ul><ul><li>Apply Overlay Multicast Protocol (OMP) to the N-DVR Server in order to provide efficient video streaming to clients </li></ul></ul><ul><ul><li>* N-DVR: Next Generation Digital Video Recorder </li></ul></ul>
  6. 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. 7. Team Goals <ul><li>Team Goal in Spring 2006 semester </li></ul><ul><ul><li>Self-confidence among team members in the our project </li></ul></ul><ul><ul><li>Cohesive work with client for meeting client satisfaction </li></ul></ul><ul><li>How to measure </li></ul><ul><li>Individual evaluation in every team meeting </li></ul><ul><li>Realistic and flexible week plan </li></ul>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 <ul><li>Set up development plan and test plan </li></ul>Preparation for development <ul><li>- Review with team members and mentors </li></ul><ul><li>Having consensus with client about the </li></ul><ul><li>architecture </li></ul><ul><li>- ATAM for evaluation </li></ul>Well designed architecture - SOW and SRS signed by our client Completion of SOW and SRS Measurement Detail goals
  8. 8. What has been done <ul><li>Activities and artifacts in Spring 2006 semester </li></ul><ul><ul><li>- Agreement with client about the architecture </li></ul></ul><ul><ul><li>established </li></ul></ul>May 7 <ul><ul><li>- SOW, SRS signoff </li></ul></ul>March 27 <ul><ul><li>- Light weighted ATAM evaluation completed </li></ul></ul><ul><ul><li>- Architecture Design Documentation completed </li></ul></ul>May 4 <ul><ul><li>- Quality Assurance Plan completed </li></ul></ul>May 8 <ul><ul><li>- MOSP </li></ul></ul>March 10 <ul><ul><li>- SOW, SRS completed </li></ul></ul>March 6 <ul><ul><li>Functional and Non-functional requirements </li></ul></ul><ul><ul><li>gathering </li></ul></ul>January 20 Activities Date
  9. 9. Architectural Drivers Quality Attributes - Performance - Availability - Modifiability - Security - Portability Functional Requirements - Group Configuration - Member Configuration - Multicast Routing - Data Replication <ul><ul><li>Technical Constraints </li></ul></ul><ul><li>- OMP Server’s OS: Linux </li></ul><ul><li>- Client’s OS: Window 2000 or XP </li></ul><ul><li>- Language: C++ </li></ul>OMP Architecture
  10. 10. Quality Attributes <ul><li>Three major quality attributes </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><ul><li>A client should be able to watch the video stream within 5 seconds of the request for the stream </li></ul></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><ul><li>The N-DVR server tries to reestablish the transmission of video stream between the appropriate client nodes when it detects failure on communication </li></ul></ul></ul><ul><ul><li>Modifiability </li></ul></ul><ul><ul><ul><li>When a developer wants to add security, the modification is made with no side effects so that no irrelevant components are changed </li></ul></ul></ul>
  11. 11. Architecture – C&C View
  12. 12. Project Process <ul><li>Tailored TSPi action </li></ul><ul><ul><li>Role </li></ul></ul><ul><ul><li>Weekly-based work plan </li></ul></ul><ul><ul><li>Architecture evaluation </li></ul></ul><ul><li>Configuration Management </li></ul><ul><ul><li>Document review process </li></ul></ul><ul><li>Risk Management </li></ul><ul><ul><li>Weekly based risk meeting </li></ul></ul><ul><li>Knowledge Acquisition Process </li></ul><ul><ul><li>Internet Engineering Task Force (IETF) standard study </li></ul></ul><ul><ul><li>Academic OMP product research </li></ul></ul>
  13. 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. 14. Semester Postmortem <ul><li>Client’s postmortem of weekly client meeting </li></ul>Satisfaction scale: 1  low, 5  high <ul><li>Team members’ postmortem of weekly status meeting </li></ul>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. 15. Lessons Learned <ul><li>Project started late </li></ul><ul><ul><li>Active attitude toward studio project </li></ul></ul><ul><ul><li>Need intensive communication with client </li></ul></ul><ul><li>Research intensive project </li></ul><ul><ul><li>Put efforts for researching relative technology </li></ul></ul><ul><ul><li>Hard to choose best algorithm that are appropriate for the project </li></ul></ul><ul><ul><li>Q&A with experts via email helps us </li></ul></ul><ul><li>Studio work adjustment </li></ul><ul><ul><li>1 st half semester: work on Saturday and Sunday </li></ul></ul><ul><ul><li>2 nd half semester: work on weekday </li></ul></ul>
  16. 16. Lessons Learned (Cont.) <ul><li>Handling burn-out in team members </li></ul><ul><ul><li>Getting stressed due to work burden and not focusing on the work is a symptom of burn-out </li></ul></ul><ul><ul><li>Refresh and relax time is necessary when it happens </li></ul></ul><ul><li>Efficient work </li></ul><ul><ul><li>Lack of sleep does not help work efficiency </li></ul></ul><ul><ul><li>Shifting work hours to daytime would be better </li></ul></ul>
  17. 17. Future Process <ul><li>Roles change </li></ul><ul><li>Implementation </li></ul><ul><ul><li>Tailored pair-programming </li></ul></ul><ul><ul><li>Biweekly iteration </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>Testing strategy based on Software Quality Assurance Plan </li></ul></ul><ul><ul><li>Testing under client environment </li></ul></ul><ul><li>Delivery </li></ul><ul><ul><li>Work with a software engineer from client for system management </li></ul></ul>Process Manager, Quality Manager, Planning Manager Eun-Young Cho Development Manager, Customer Interface Manager Minho Jeung Team Leader, Risk Manager Kyu Hou
  18. 18. Future Schedule <ul><li>Implementation </li></ul><ul><ul><li>Group Management </li></ul></ul><ul><ul><li>Algorithm </li></ul></ul><ul><ul><li>Command Line Interface </li></ul></ul><ul><ul><li>Test Program </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>Unit Test </li></ul></ul><ul><ul><li>Integration Test </li></ul></ul><ul><ul><li>Acceptance Test </li></ul></ul><ul><li>Deliverables </li></ul><ul><ul><li>Guide documentation for </li></ul></ul><ul><ul><li>users and administrators </li></ul></ul><ul><ul><li>Source code </li></ul></ul><ul><ul><li>Integration Test </li></ul></ul>Jul. 24 <ul><ul><li>Product documentation </li></ul></ul>Aug. 7 <ul><ul><li>Development with Unit Testing III </li></ul></ul>Jul. 10 <ul><ul><li>Acceptance Test </li></ul></ul>Jul. 31 <ul><ul><li>End of OMP Product Deliverables </li></ul></ul>Aug. 11 <ul><ul><li>Development with Unit Testing II </li></ul></ul>Jun. 26 <ul><ul><li>Development with Unit Testing I </li></ul></ul>Jun. 12 <ul><ul><li>Setup Environment, Presentation for POSDATA </li></ul></ul>May. 29 Activities Date
  19. 19. Thank You !
  20. 20. Architectural Decision <ul><li>Division between stream data and node configuration data </li></ul><ul><li>Using Event Bus for notifying the node configuration changes </li></ul><ul><li>Providing a Text based UI </li></ul><ul><li>Using dynamic memory for storing stream data and node information </li></ul><ul><li>Applying different communication protocol for each data type </li></ul><ul><li>Supporting dynamic nodes configuration by heart beating parent nodes </li></ul>
  21. 21. Architecture <ul><li>Module view </li></ul>
  22. 22. Architecture <ul><li>Allocation view </li></ul>
  23. 23. QA Scenarios <ul><li>Socket Programming vs. RPC </li></ul><ul><li>Some information from this table like the six parts have not been shown </li></ul><ul><li>Due to space constraints </li></ul>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. 24. QA Scenarios (Cont.) <ul><li>Explicit Invocation vs. Implicit Invocation </li></ul>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. 25. QA Scenarios (Cont.) <ul><li>Dynamic memory vs. Static memory </li></ul>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. 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. 27. Configuration Management
  28. 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. 29. Improvement <ul><li>Role balancing </li></ul><ul><ul><li>process role vs. developer </li></ul></ul>Tech. Proc. EOSP Start Task Action Developer
  30. 30. Improvement (Cont.) <ul><li>Distant Client Meeting </li></ul><ul><ul><li>MSN  video conferencing </li></ul></ul><ul><ul><li>Time saving: 2 hr  1 hr </li></ul></ul><ul><ul><li>Meeting time: Monday 10 am – 11 am (Seoul) Sunday 9 pm – 10 pm (Pittsburgh) </li></ul></ul>
  31. 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. 32. Resource <ul><li>Team OMPArchitectability </li></ul><ul><li>= Team Trinity + Team Swaran Sanghini </li></ul><ul><li>Co-work Area </li></ul><ul><li>- IEEE RFC study </li></ul><ul><li>- Artifact work </li></ul><ul><li>- Review strategy </li></ul><ul><li>- Presentation </li></ul>
  33. 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. 34. Risk Analysis
  35. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×