1 / x cmmi technical solution rob vanden meersche dieter van den bulcke
TRANSCRIPT
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.
<Technical Solutions>
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
<Technical Solutions>
5 / x<Technical Solutions>
6 / x
Technical SolutionSpecific 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
<Technical Solutions>
7 / x
Technical SolutionSpecific 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
<Technical Solutions>
8 / x<Technical Solutions>
9 / x
Technical SolutionSpecific 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
<Technical Solutions>
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
Technical SolutionGeneric 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
< Technical Solutions >
12 / x
Technical SolutionGeneric 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
< Technical Solutions >
13 / x
Technical SolutionGeneric 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
< Technical Solutions >
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
< Technical Solutions >
15 / x
Technical SolutionGeneric 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
< Technical Solutions >
16 / x
Technical SolutionGeneric 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
< Technical Solutions >
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.
< Technical Solutions >
18 / x
Technical SolutionGlossary
CMMI Capability Maturity Model Integration
COTS Commercial of the shelve
TS Technical Solutions
< 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
< Technical Solutions >