1. 1 / x CMMI Technical Solution Rob Vanden Meersche Dieter Van den Bulcke

2. 2 / x Delete this slide in final version Guidelines (remove in final version)‏ Use English language Copy only the titles of the practices not the description from the CMMI – use subpractices as guidance but do not discuss separately Map CMMI terminology to project terminology (add to glossary)‏ Add explanatory slides as required Add references to direct/indirect artifacts for each practice Include descriptions/screen shots of artifacts Make a first draft based on documentation of projects and results of dream questions and add markers where information is missing Use this draft in interview sessions to ask questions to the group or discuss Update final version with interview feedback Ensure this presentation enables students to understand the practices of this process area in the context of real projects Do not forget the slide with Strengths and Opportunities for Improvement Check spelling

3. 3 / x Technical Solution Purpose  To make a well argumented and documented decision on what solutions should be used to achieve the requirements. Should any late changes in the requirements occur, it is easier to see how the design can be changed minimally to comply with these changes.

4. 4 / x Technical Solution Specific Goals  SG 1 Select product component solutions SP1.1 Develop alternative solutions and selection criteria Alternative solutions and COTS products are investigated Selection criteria are not documented enough, they are expressed verbally at meetings but they are never written down. SP1.2 Select product component solutions Decisions on the selected solutions are based on certain criteria but again these are not documented. However, requirements are allocated to the chosen solutions. [1] documents with results of investigations [1] implicitly in component diagrams and final architecture [2] 1 group has done this explicitly

5. 5 / x

6. 6 / x Technical Solution Specific Goals  SG 2 Develop the design SP2.1 Design the product or product component Every group uses design methods as prototypes, object-oriented design, design patterns,... Again hardly any documentation on criteria or the designs themselves. Only one group did document the design in terms of allocated requirements. SP2.2 Establish a technical data package Technical data packages are inexisting [1] component diagrams [2] final architecture

7. 7 / x Technical Solution Specific Goals  SG 2 Develop the design SP2.3 Design interfaces using criteria Interfaces between product components and interfaces of external components are identified and documented But criteria on interfaces are not defined SP2.4 Perform make, buy or reuse analyses No groups have bought products Decisions were made to reuse existing (C)OTS products or make the solution in house. Again no artifacts to prove this were found [1] class diagrams and sequence diagrams

8. 8 / x

9. 9 / x Technical Solution Specific Goals  SG 3 Implement the product design SP3.1 Implement the design Every group uses the object oriented programming paradigm and an IDE Every group? Uses a CI to perform testing, enforce a coding standard,... SP3.2 Develop product support documentation Product support documentation is not implemented yet, but is expected. [1] code

10. 10 / x Technical Solution Generic Practices GG 2  GP2.1 Establish an Organizational Policy Senior management (Frank Gielen) advised us to perform a state-of-the-art study for every problem we encounter, instead of inventing a solution that might already exist....?  GP2.2 Plan the Process No plan found, some groups just appointed someone responsible for research. There should be a plan outlining the scope of the process, listing responsibilities, required resources and training. [1] Research documents/reports

11. 11 / x Technical Solution Generic Practices GG 2  GP 2.3 Provide Resources Few resources are explicitly provided for TS, but some simulators were found. Every group has defined and documented the scenarios they want to elaborate on through UML (tools). Every group has a server to perform research, test prototypes,... Some teams explicitly make time for investigations and discuss results and decisions in meetings [1] Simulators (WAFL) [2] UML modelling tools like VP [3] Planning and meeting reports [4] Server

12. 12 / x Technical Solution Generic Practices GG 2‏  GP2.4 Assign Responsibility Every group made some people responsible for certain investigations and decisions on what solutions should be used. Most groups have a lead architect responsible for monitoring the overall progress concerning TS (research). As there is no real process to be found, no other responsibilities were assigned.  GP2.5 Train People Every group provided (online) training for things like unit testing, the IDE and programming language to be used, the build system and CI environment,... [1] Meeting reports [1] Online training documentation

13. 13 / x Technical Solution Generic Practices GG 2  GP2.6 Manage Configurations 1 groups puts its documentation under version control. Some things like product component and interface designs, technical datapackages,... should be managed and controlled because it’s clear that almost every group lacks decent and sufficient documentation.  GP2.7 Identify and Involve Relevant Stakeholders During review meetings, the relevant stakeholders are kept up to date on the project. Most groups contacted their suppliers, if any, to make agreements about interfaces and functionality. [1] Meeting reports

14. 14 / x Technical Solution Generic Practices GG 2 (3)‏  GP2.8 Monitor and Control the Process Risks and accompanying mitigation plans are defined and updated to keep track of progress. Some groups have a project plan and time schedule with which they can track the time used on TS research and take corrective actions if necessary. No more measurements to control the process were found. [1] Risk list [2] Time schedule and project plan

15. 15 / x Technical Solution Generic Practices GG 2‏  GP2.9 Objectively Evaluate Adherence Not done, no documents found  GP2.10 Review Status with Higher Level Management Report results and progress to project leader and to relevant stakeholders and senior management at review meetings. [1] Review meeting reports

16. 16 / x Technical Solution Generic Practices GG 3  GP3.1 Establish a Defined Process No general processes and tailored process descriptions found.  GP3.2 Collect Improvement Information Only through this exercise have improvement possibilities been identified. Places where we could not fill in the blanks are possible area’s of improvement. [1] Software management exercise

17. 17 / x Technical Solution Findings  Strengths An architecture has been created in advance. Almost everybody participates in research and the decision making, so everybody can understand the decisions made. All groups frequently make prototypes and working demos.  Opportunities for Improvement Not a single group has defined a process with responsibilities, resources,... Very little of all the efforts made are documented for future use.  Proposed Actions Define a process, make a plan and especially document them for future use and reviews.

18. 18 / x Technical Solution Glossary  CMMICapability Maturity Model Integration  COTSCommercial of the shelve  TSTechnical Solutions

19. 19 / x Technical Solution References  CMMI for Development version 1.2 http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html  Portals and website of the projects.  Minerva forum: http://minerva.ugent.be/main/forum/index.php?cidReq=EMCOSW01000002_2 008 http://minerva.ugent.be/main/forum/index.php?cidReq=EMCOSW01000002_2 008