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

1 / x<Technical Solutions>

CMMITechnical Solution

Rob Vanden MeerscheDieter Van den Bulcke

2 / x

Delete this slidein 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

<Technical Solutions>

3 / x

Technical SolutionPurpose

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 / x

Technical SolutionSpecific 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


6 / x


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 / x


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


9 / x


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 / x< Technical Solutions >

Technical SolutionGeneric 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 / x


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

< Technical Solutions >

12 / x


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 / x


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 / x

Technical SolutionGeneric 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 / x


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 / x


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 / x

Technical SolutionFindings

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 / x

Technical SolutionGlossary

CMMI Capability Maturity Model Integration

COTS Commercial of the shelve

TS Technical Solutions


19 / x

Technical SolutionReferences

CMMI for Development version 1.2http://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_2008


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

Documents

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