The purpose of the Risk Log is to provide a list of risks confronted during the Tempus project.

Transcription

1 Tempus Risk Log Document ID: Tempus RL Version history Version Date Author Description Approved by Juha Vuojärvi Request for approval Juha Vuojärvi Initial version Introduction The purpose of the Risk Log is to provide a list of risks confronted during the Tempus project. Tempus risk log from project planning phase: Date Risk documented or communicated via Risk type Solution or comment Corrective actions s Communication Communication practices defined 28.9 Client s Communication Slow responses from client: Aki is on paternity leave (which we did not know) 28.9 Group meeting Resource and quality s Documenting and resource Missing project tools : Missing time reports due to suitable tool for formal communicatio ns, IRC for informal All groups created and contact info provided for customers Create list of required tools. Wiki implementatio n on 28.9 Time reporting excel sheet

2 29.9 Customer meeting Communication Technical and documentation Meetings practices are not defined Client server architecture, no peerto peer. To be implemented on C or C s Resource risk Provide templates for most common documenting tasks Iteration plan delivery Resource risk Many members of group abroad replaced by Wiki page Customer notifications every second week, groups. Update documents. Templates for documents available on Wiki Work beforehand risk Risk of being late Work beforehand s Use Cases for project Subscribe, publish, deletion/modi fication, scheduling 5.10 Mentor meeting risks Risk seen that all documentation is not reviewed appropriately, communication and resource risk Resource risks Periodic reporting from members required, since currently hours are not report in correct manner Unclear tasking for developers Internal freezes for documentatio n to ensure proper time for reviews.project system to be implemented (when??) about Plan & distribute specific tasks to developers Technology and Unstandard tools; Research and

3 7.10 Customer meeting resource risks Customer risks Quality risk Research and define set of tools to be used Mozilla / Evolution, Testing tools, UML tool, complier, Linux version, Wiki, CVS, Server promised for week 41 In order to fulfil Quality standards criteria has to be set risk Use case priority and order set s risk unclear : Comments from client to Risk manual s naming does not fulfil course requirements Follow course requirements and rename and redefine documentation naming practices s risk Time reporting tool is no good s, communication and resource risk Members have not reported hours s risk Unclear project outcome and how to validate it (from Mentor) New goal: Verify SIPcalendar functionality and practical applicability s, communication and resource risk Members have not reported hours standardize tools to be used Not much to do about this For i.e. Unit testing coverage set to 80% Update documents Update document Update documents.project replaces Wiki on time reporting Notification sent to members to update status Update document Notification sent to members to

4 17.10 Delivery of documents Risk of being late s risk Missing SEPA practices s and resource risk Iteration demo Risk of missing deadline Redefined project goals from customers based on delivery of documents. Open Source project (requirements), method for feedback to IETF, feature set missing Almost late ( sent with materials at 19.10) update status and update it at least on weekly bases Notification to all to start working with SEPA practices Update documentatio n Internal project freezes to be implemented

5 Summary of Project planning phase risks: Risk type Comment Corrective action Effect Communication risks Communication risks Resource and documentation risks and communication risks risks and quality risks Unclear communication practices Slow responses from clients to s Resources lost due to missing tools, lot of manual work and standardizing the outcome Time reporting system is not filled in time SEPA practices are not started Changed project goals and uses cases Set of communication tools to be used agreed: for formal and IRC for informal communication. Client update notification to be sent every second week Notify client Standardize document practices; provide templates for most common tasks. New time reporting system to help project management Notify members Notify members Update documentation Easier to keep upto date on the project. Faster responses to s Saved resources due to available templates and standard documentation practices

6 Tempus risk log from Iteration phase 1: Date Risk documented or communicated via Customer meeting Risk type Solution or comment Corrective actions Communication Unclear meeting practices Various document formats and publishing practices Weekly meetings set on Tuesdays Latex taken into use Error reporting Bugzilla taken into use Technology Sofia SIP issues, Portability issues (Win32/XPI) Client Test server availability Ask clients when available Client Calendar server is not ready s (Mentor) Resource Estimation of amount required for research and actual implementation is almost impossible s Resource Lost resources due to tasking s Technical Technical issue to be solved s Technical and Versioning risks quality See more information from 4.11 / Divide tasks to Subtasks to help resource tracking Answer at 8.11, partially Comments to be included into

7 s s and technical 1.11 Group meeting Communication and resource and communication Resource Technical, documentation and resource Unclear interactions of components Unclear project status for member is not review appropriately or approved correctly Weekly meetings do not provide enough status information Too much workload on member Unclear picture of project and technologies and tools documents committed to CVS Activity diagrams drawn to support documentatio n is the official channel, IRC used for discussion. Weekly reports are not sent to customers Open discussion about reviewers and responsibilitie s on weekly meetings Weekly IRC meetings are taken into use (nonmandatory participation) In case of such situation, contact Lauri and negotiate Research tasks are given to all members on different topics.

8 4.11 Group meeting Technical Unclear XPCom and XUL issues Technical Problems with Sofia SIP and Mozilla code integration Client Calendar server ready for testing 8.11 Group meeting Technical and resource Resource Behind schedule Resources spent on the research Presentations of the results will be held on 4.11 to provide information to all member of relevant area Issue briefly discussed, research continues Issue briefly discussed, research continues Postponed to next week due to kernel errors Back up plan discussed but not accepted New tasking for developers (GUI, server, client). Smaller group meetings agreed to save resources Client Missing server Contact client about the issue s Technical Behind schedule notification sent to customers Architecture changes, Mozilla problems on developers computers, XUL and

9 s Group & Mentor meeting Technical and client Technology and resource Technology and resource Resource Server is not working even though following the instructions from customer server does not respond to for i.e. Subscribe requests Sofia SIP and Mozilla complexity Unstandard development and test environments leading to lost resources Behind schedule: Move all possible deadlines one week ahead and inform customer about the situation. Internal prioritization given to coding updates not done SEPA practice quality is not met JavaScript are an unfamiliar languages. Communicati on with client, solved on Lot of resources are spent on researching these issues Standardize development and test environments UC 5 might be missed for I1 Note that documentatio n updates need to be completed prior internal deadlines (reserve resources) Decided that SEPA s will be appropriately reviewed prior to delivery

10 Quality Testing is not started yet Due to no ready code Resource TDD SEPA obsolete New SEPA subject / expand view Technology and resource Sofia SIP integration does not work Research s Technology More technical issues to be solved Group meeting Technology and resource Quality Behind schedule Testing is not started yet: Due to no ready code Answer (18.11/22.11). Unanswered question should be posted to Sofia SIP developers. UC 1 is top priority in order to have something on the I1 Demo. Code review planned to Resource TDD obsolete New SEPA subject or expand the topic coverage Communication Technology Project status unknown from some parts (GUI etc) Sofia SIP integration does not work Technology Nua_i_subscribe not implemented on Sofia SIP More communicatio n needed between members Communicati on with client, research Contact Sofia Sip developers about the issue

11 25.11 IRC meeting Resource and quality Technology Project behind schedule and possibility that nothing is ready on I1 demo Sofia SIP does not integrate with code Customer and Mentor contacted about the issue. Customer meeting agreed to Code review scheduled to to Sofia SIP (P.Pessi) contact person for support request Group meeting Client Server not working Contact client about the issue 5.12 Delivery of documents 7.12 I1 Demo Ensure that documentation update and review responsibilities are given Deadlines for document updates and reviews

12 Summary of Implementation phase one risks: Risk Comment Corrective action Effect Client, technology risk, documentation and resource risk Update documentation, reallocate resources Technology risks Client risks Resource risks Resource risks Communication risks Communication risks Quality risks Changing architecture from client server to client server and peer to peer Unfamiliar technology and tools Customer server delivery late Task estimation incorrect Time reporting outof date Unclear meeting practices Customer communication response times Due to technical problems testing done during I1 was very limited Research and standardize Inform and notify client Divide task into smaller subtasks Notify member to update time reports Weekly meeting practices, set of communication tools defined, Notify customer Code reviews, unit, smoke and explorative testing to ensure quality Instead of coding only on C++, Javascript and XUL were introduced to the project as well. Major underestimation of research hours spent on SIP and Mozilla. Actual client server software testing could not start until this was fixed Project management was easier due to enhanced tracking Some effect Easier to keep upto date on the project. Faster response times Software did not fulfil testing criteria set on the project.

13 Tempus risk log from Iteration phase 2: Date Risk documented or communicate d via Customer meeting/i1 demo Customer & internal & mentor meetings Risk type Solution or comment Corrective actions Resource & quality & technology Resource & quality & technology Major technical difficulties due to more complex environment than expected. Majority of resources spent on research by the end of I1 iteration. Insufficient amount of resources available for iteration & IRC Technical Problems on compiling Mozilla Sunbird & IRC Technical Difficulties to get the client's server running locally Internal and client s & IRC Technical Troubleshooting performance of the server. Agreeing with client to reduce number of use cases from eight to three. Redefining tasks. Giving developers free hands to put at most 10% extra effort to the project if they want. Discussion on IRC, Combined effort to solve the problem. Linking libssl.so.5 correctly. More testing and debugging of the server. Creating calendar events manually to the server database to circumvent the

14 Code reviews and team meetings together with mentor Internal testing sessions Peer testing session Internal meeting Internal meeting Quality & technical and documentation Quality & technical Quality & technical Quality & technical and documentation & quality IRC & & resource Program code created mostly using iterative rapid development methodology causing uncommented and unfinished code. Project code is still buggy and needs to be improved. Different modules of the code don't work together seamlessly. Project code is still buggy and needs to be improved. Different modules of the code don't work together seamlessly. Different views what should be completed before the final delivery. Documents out of date. Missing SEPA practices. Unfinished documents and insufficient time to complete the problem. Several code reviews during iteration 2 to ensure the quality of the code. Additional comments and suggestions from mentor. Updating test documents and informing developers about malfunctions. Getting feedback from peer testing team. Open issues discussed on the meeting and documented to Wiki to keep track of the last week status of the project. Document updating and finalization in time. Visualizing documentation. Documents ready for internal review

15 Internal review & IRC Technology & quality and documentation documentation. by Program doesn't function properly in final demo and demo slides not ready in time. Code Freeze on to include only functional and tested modules. Share responsibilities to complete slides for the final presentation.

16 Summary of Implementation phase two risks: Risk Comment Corrective action Effect Resource Risk Major technical difficulties due to more complex environment than expected. Majority of resources spent on research by the end of I1 iteration. Agreeing with client to reduce number of use cases from eight to three. Client requirements and goals are not met. Resource Risk Technical Risks Quality Risks Communication Risks Insufficient amount of resources available for iteration 2. Program functionality problems (also server side) Project code is still buggy and needs to be improved. Different modules of the code don't work together seamlessly. Program modules are in inconsistent state and don't implement identical functionalities. Documents out of date. Missing SEPA practices. Insufficient time to complete the documentation. Redefining tasks. Giving developers free hands to put at most 10% extra effort to the project if they want. Debugging, testing and documenting. Informing customer. Updating test documents and informing developers about malfunctions Constant IRCing, regular meetings and documentation. Deadlines for updates and internal reviews. Client requirements and goals are not met. If extra hours are reported the course grade will drop. Unallocated resources spent. Program doesn't work properly. Unallocated resources spent. Program doesn't work properly. Unable to integrate and test modules. Decreased quality of the product. Quality assurance goals are not met. Course grade drops.