Spring 2004 EOSP

1. Spring 2004EOSP 2004. 5. 7 Team GEO

2. Agenda • Introduction • Project Plan • Processes • Architecture • Size Estimation • Risk Management • Test Plan • Next Plan • Lessons Learned • Q&A

3. Team Introduction • Members & Roles • Mentors • Gil Taran • Carol L. Hoover • HoJin Choi JunSuk Oh YounBok Lee KwangChun Lee SoYoung Kim JungHee Jo (Lead) (Planning) (Support/Risk) (Development) (Process)

4. Project Overview • Project Name • PMCenter (Project Management Center) • Customer • Korea Telecom • Objective • To make web-based software project management system customizable at any time • Scope • Support for overall project life cycle from project initiation to closing

5. Project Plan • We are in the RUP Elaboration Phase Project Management SPMP Revision Estimation Risk Management Requirements Use Case Model SRS Revision Analysis & Design Define Architecture Establish Architecture 1st Use Case Realization 2nd Use Case Realization 1st Design Components 2nd Design Components Test V&V Plan

6. Processes • Last Semester vs. This Semester

7. Key Processes • Requirement Change Process • Why define? • GEO wants to remove “data mining” functionality • It is hard to implement within August, 2004 • There is no expert about data mining among team members • Client doesn’t regard it as an important functionality • Purpose of this process • Ensure changes are documented, reviewed, and mutually accepted by the GEO team and the client, KT. • Develop a requirement change plan and a checklist for review • Minimize the impact of the requirement change

8. Key Processes • Timely Decision Making Process V1.0 • Why define? • Communication confliction problem occurred in every team meeting • 4 members:1 member / 3 members :2 members • Meeting time always exceeds the planed time without decision making • No one has authority to determine the decision • Purpose of this process • Adapt majority rule • Resolve team confliction • Remove the discordant factors among team members • Assign authority to team leader

9. Key Processes • Timely Decision Making Process V1.1 • Why define? • Many times decision is made by 4 members • 4 members : 1 member • One member suggest to insert monitoring step to track determined decision succeed or not • Revise the existing timely decision making process • Purpose of this process • Monitoring the team decision • Compensate the evil of majority rule • Continuous improving of team decision

10. Key Processes • Process Improvement Process • Why define? • While operating processes, some modification is needed • Team members talk to process manager on the way • Easy to forget the small change ideas • Hard to control the change of process • Formal process change is necessary • Purpose of this process • To find out process problems and improvement ideas • To adapt process improvement idea formally • To keep the history the process changing

11. Architecture Business Driver • Web-based system • The overall structure of system could be three-tier architecture. • Specific support for the organization • The system architecture should reflect the unique business logic in the client’s organization • Multi language support • Our system should provide its services in multiple languages (e.g. Korean and English). • Development environment • Our system should be developed using Java technology.

12. Architecture System Context PMCenter Project management Configuration management Configuration Management System Project Manager Project execution Project Member Data Mining System Project data System administration Administrator System Boundary External System Actor X Y X interacts with Y

13. Architecture Utility Tree When project managers manipulate WBS information, the activities should be supported on GUI so that they can easily do their jobs. (H,H) Usability Efficient use (H,H) The system preserves the ongoing transaction and data consistency if a server fails. Availability Robustness (H,M) While 300 users login to the system, up to 10 concurrent users can close tasks within 5 seconds at the same time Concurrency Performance (H,M) When a user sends a retrieve request to the system, the system can respond in less than 3 seconds while the system is under peak load . Processing Time (H,M) Language conversion in user interface from Korean to English should be possible in less than 1 week with 1 person without changing other source code. Modifiability Cost of change (H,M) A member of team is allowed to see the information of project she/he is working on and the tasks assigned to her/him but no other projects Security Confidentiality

14. Architecture ATAM – Preparation • Key preparation • Business presentation • Business driver • Utility tree – quality attribute scenario • Architecture presentation • Context view, run-time view, code view, and physical view • Candidate architectures • ATAM meeting (April 14th) • 8 persons attended (led by Tony Lattanze) • 3.5 hours long

15. Architecture ATAM – What we obtained • Applied Scenario • While 300 users login to the system, up to 10 concurrent users can close tasks within 5 seconds at the same time • ATAM results • Refined and prioritized quality attributes scenarios • Identified potential risks implying candidate architecture • Not determined technical framework yet • Make it difficult to analyze performance between alternatives • Database and amount of data to be stored should be determined • Make it difficult to analyze performance between alternatives • Next step • Need to determine technical framework • Need to make the ambiguities in architecture clear • Apply ATAM to important scenarios on our team own

16. Architecture ATAM – Afterward • Performed technical research • EJB vs. Plain Java Class • Java Application vs. Java Applet

17. Architecture Client Side Server Side Logic Tier Data Tier App. Client Socket Logic Application Server Project DB Web Presentation XML Server Web Language Browser DB Component Type Connector Type Data Access Data Access Procedure Call Procedure Call HTTP HTTP DataBase DataBase Logic Logic Communication Communication Client Client Server Server Application Application Socket Socket Overall Architecture – Before ATAM

18. Architecture Overall Architecture - C&C View Client Tier Middle Tier Data Tier Presentation Business Logic HTML page Applet Tier Layer UI Type

19. Architecture Alternative Architecture 2 - Multi Language Support • Scenario • Language conversion in user interface from Korean to English should be possible in less than 1 week with 1 person without changing other source code. • Risks • The challenge of unfamiliar technology - XML • Sensitivity points • Modifiability is increased because UI and source code can be separately maintained • Tradeoffs

20. Architecture Alternative Architecture 1 - WBS manipulation No restriction to implement (+) vs. Maintainability and Usability(-) Client Tier MiddleTier Data Tier Presentation Business Logic Tier Layer

21. Architecture Alternative Architecture 1 - WBS manipulation • Scenario • When project managers manipulate WBS information, the activities should be supported on GUI so that they can easily do their jobs. • Risks • Lack of skill of handling java GUI • Sensitivity points • Having two kinds of user interfaces to support WBS graphics • Tradeoffs

22. Architecture Alternative Architecture 2 - Multi Language Support Easy to implement(+) vs Extensibility and Modifiability(-) Middle Tier Data Tier Client Tier Presentation Business Logic Tier Layer

23. Architecture Overall Architecture –Final Decision Client Tier Middle Tier Data Tier Presentation Business Logic HTML page Applet Tier Layer UI Type

24. Architecture Overall Architecture – Module View

25. Architecture Overall Architecture – Physical View

26. Architecture ATAM – What we learned • Candidate architecture elicitation • Need to clarify the technical knowledge of candidate architectures • The effect of technical decision to architecture • Scenario specification • Be specific as possible • Observe 6 part scenario specification • Scenario prioritization • Less meaningful to prioritize quality attributes themselves • Should prioritize quality attribute scenarios • Mini ATAM scheduling • Need to prepare more for proper evaluation within limited time

27. Use two methods (MOSP) Function Points and Use Case Points ICU MSE Size Estimation D/B (EOSP) Motivation Difficulties from lack of historical data Define Data Collection Process Based on the USC COCOMO Data Collection Program Tailored to be fitted in MSE Program Size Estimation Method Library Empirical Size Estimation Methods (e.g. WAG, Delphi) Parametric Estimation Methods (e.g. Parametric Regression) Theory-based Estimation Methods (e.g. SLIM: Norden-Rayleigh) Estimation Process and Database Re-Estimation (Next Semester) SRS 2.3 released at 1st May Estimation Size Estimation

28. Goal Setting Project Registration Estimation Strategy Setup ICU Size Estimation D/B Methods Library History D/B Estimation Estimate Size Evaluate Performance Report and Update D/B Estimation ICU Size Estimation D/B Process

29. Estimation Data Sources • Studio Information • Studio team name • Number of team members • Studio team ethnics( American/Asian/Indian/European/Spanish) • Total software experiences • Description of Projects • Development Information • Development Type: New/Upgrade/Maintenance • Development Process: Waterfall/RUP/XP/Spiral • Development Language: Java/.NET/C++ • Client Information • Application Area: Command and Control /MIS /Simulation /Communication … • Client CMM Level: Level-1/Level-2/Level-3/Level-4/Level-5 • Project Information • Fall Semester • Total Lines of Code (Estimated) • Total Number of Objects if Object-oriented (Estimated) • Spring Semester • Total Lines of Code (Estimated) • Total Number of Objects if Object-oriented (Estimated) • Summer Semester • Total Lines of Code (Estimated) • Total Number of Objects if Object-oriented (Estimated) • Project Evaluation • Success Rating for Project: Very Successful /Successful /Satisfactory /Unsatisfactory / Very Unsatisfactory • Total Lines of Code (Actual) • Total Number of Objects if Object-oriented (Actual)

30. Estimation Estimation Method Library • Empirical Size Estimation • Wild Altogether Guess (WAG) • Function Points • Parametric Size Estimation • Ordinary Linear Regression • Non-linear Regression • Robust Regression • Generalized Linear Regression • Theory-based Estimation • SLIM: Rayleigh Distribution • Learning-Oriented Estimation • Neural Network • Decision Tree & Regression Tree • Composite Estimation • A Bayesian approach: COCOMO II Calibration NOTE: Black (Spring 2004), Red (Summer 2004)

31. Risk Risk Management Framework

32. Risk Risk Management Framework • Operational Risk • The risk of losses resulting from inadequate or failed internal processes, people and systems or from external events • Product Risk (TBQ) • Product engineering • Development environment • Program Constraints • Studio Risk Management • Program specific risk • One year schedule • Balance between core courses and studio

33. WHY? WHY? Fishbone Why-Why Diagram Risk Risk Management vs. Problem Solving CRM Problem Solving • Collect, analyze & confirm Information • Identify the root problem • Determine if the problem should be solved • Formulate the problem statement • Generate possible solutions • Select the best solution • Devise a plan • Carry out the plan • Evaluate Ray Williams 2004. Continuous Risks Management Studio Presentation Master of Software Engineering CMU Fogler, H. S. & LeBlanc, S. E. 1995. Strategies for Creative Problem Solving. Prentice-Hall

34. Risk Risk Categorization Risk Category (D)  Risk Category (C)

35. Risk Top 7 Risk Items • Lack of team morale due to interpersonal team problems; may cause work to be less efficient and create extra work for team. • Individual team members do not have enough self-control to spend adequate time on studio; may cause the schedule slip and compromise the product quality. • Poor communication between team members; may lead to inefficiency, misunderstandings and rework. • Team members have little experience with required domain knowledge (technology, process, teamwork skill); may cause the schedule slip. • Not enough analysis of requirement; might lead to incorrect design. • Heavy load of other courses; might not allow us to spend enough time to studio project • Mismanaged task assignment; might lead to unbalanced work load among members. Team Product

36. Test Plan Test Strategy • Role & Responsibility • Quality Assurance Manager • Keeping track of the proper schedule for the review process • Ensuring the appropriate planning and management of the review resources • Test Manager • Negotiating the ongoing purpose and deliverables of the test effort • Ensuring the appropriate planning and management of the test resources • Assessing the progress and effectiveness of the test effort

37. Test Plan Test Strategy • Tools & Techniques • Tools • Word processing (Microsoft Word) • Electronic mail system and messenger • Review reports • Checklists • JUnit • Techniques • Review • Inspection • White box testing • Black box testing • Automated testing

38. Test Plan Quality Attributes Test • Usability focuses on • Human factors • Aesthetics • Consistency in the UI • Reliability focuses on • Extreme workloads • Unavailable services • Malicious user input • Limited shared resources • Performance focuses on • Benchmark test • Load test • Contention test

39. Test Plan Test Metrics

40. Accomplishments • What we did (versus Original Plan) • Project Management • SPMP (v 2.2) • Size Estimation (v 1.0) • Software Risk Evaluation & Mitigation Plan • Process Handbook (v 2.0) • Requirements • SRS (v 2.3) • Use Case Model (v 1.2) • Analysis and Design • Architecture (v 1.0) • Test • Verification and Validation Plan (v 1.1) • What we postponed (versus Original Plan) • Analysis and Design • Use Case Realization • Detail Design (partly done)

41. Effort Measurement • Time spent this semester

42. Next Plan • Elaboration Phase (Continued): ~Early June • Use Case Realization • Detail Design • Construction Phase: ~Mid July • Coding & Test • Transition Phase: ~Early August • System Integration Test • System Install • User Training

43. Lessons Learned • Techniques • ATAM • Software Risk Evaluation • For better teamwork • Without respect, the team never maintains harmonious relations • Try to make a good meeting mode even if personal feeling is not good

44. Q & A

45. Appendix - Initial Component Design • Static modeling • Identify interface and component candidates