| 20 |
\tableofcontents |
\tableofcontents |
| 21 |
\newpage |
\newpage |
| 22 |
\pagenumbering{arabic} |
\pagenumbering{arabic} |
| 23 |
|
\section{Introduction} |
| 24 |
|
It is far to common that companies working with software |
| 25 |
|
development are drawing over the proposed budget (ether in |
| 26 |
|
time and or resources). It is also to common that software |
| 27 |
|
projects are being terminated since there is no result coming |
| 28 |
|
from them. |
| 29 |
|
|
| 30 |
|
The Company has decided that it should do something to make |
| 31 |
|
itself not do those things, and also to be able to show |
| 32 |
|
potential clients that they will be able to succeed. This is |
| 33 |
|
why the Company has decided that it should meet level 2 of the |
| 34 |
|
CMM (Capability Maturity Model) the so called repeatable |
| 35 |
|
level. The aim of that is to be able to repeat successes from |
| 36 |
|
before by reusing successful methods etc. |
| 37 |
|
|
| 38 |
|
Also some customers can require that the companies they hire |
| 39 |
|
have CMM gradings so that they can know that they will get |
| 40 |
|
what they ordered, on time and target (the cost that would |
| 41 |
|
be). |
| 42 |
|
\section{The company so far (a.k.a. assumptions)} |
| 43 |
|
\begin{itemize} |
| 44 |
|
\item The company has been using CVS for the source-code for |
| 45 |
|
some time now, mainly to be able to A) have a safe copy (the |
| 46 |
|
CVS server is using raid system to make certain that even a |
| 47 |
|
disk malfunction wont destroy the code that has been made so |
| 48 |
|
far and B) to be able to go back to older code if there is a |
| 49 |
|
need for that. |
| 50 |
|
\item The company is currently developing in C/C++. |
| 51 |
|
\item The company has had its requirements centered around |
| 52 |
|
use cases so far. |
| 53 |
|
\item The company has agreed to send all its project |
| 54 |
|
managers to a course in software metrics so that they all |
| 55 |
|
will speak the same language. |
| 56 |
|
\end{itemize} |
| 57 |
\section{Goals of the metric program} |
\section{Goals of the metric program} |
| 58 |
\label{goals} |
\label{goals} |
| 59 |
The goals of this metric program are: (Expand these) |
The goals of this metric program are: %(Expand these) |
| 60 |
\begin{itemize} |
\begin{itemize} |
| 61 |
\item Track project progress (project planning, project tracking) |
\item To be able to make better estimates (more accurate) |
| 62 |
\item Make project development less chaotic |
for the customer and the management. |
| 63 |
\item Not to make the same mistakes twice |
\item Track project progress (project planning, project |
| 64 |
\item Do measurements so that they are reusable for estimations in the next project |
tracking). |
| 65 |
|
\item Make project development less chaotic and more |
| 66 |
|
structured. |
| 67 |
|
\item Not to make the same mistakes twice and to be able to understand why certain projects are |
| 68 |
|
successful, and be able to repeat the successes on other |
| 69 |
|
projects. |
| 70 |
|
\item Do measurements so that they are reusable for estimations in the next |
| 71 |
|
project. |
| 72 |
|
\item To be able to make high quality software. |
| 73 |
|
\item To introduce Software Configuration Management in the |
| 74 |
|
software development process. |
| 75 |
\end{itemize} |
\end{itemize} |
| 76 |
\section{Achieving the goals} |
\section{Achieving the goals} |
| 77 |
To achieve the goals presented in Section \ref{goals} we have come up with the following plans: |
To achieve the goals presented in Section \ref{goals} we have |
| 78 |
|
come up with the following plans: |
| 79 |
|
\subsection{To be able to make better (more accurate) |
| 80 |
|
estimations for the customer and the management} |
| 81 |
|
In order to get the confidence from the customer and the |
| 82 |
|
management there it is important to make good and accurate |
| 83 |
|
estimates on the project both before and during the phases |
| 84 |
|
of the project. If we can get confidence in our estimates |
| 85 |
|
from the customers they will choose us before a company that |
| 86 |
|
often (or always) makes bad estimations. |
| 87 |
|
|
| 88 |
|
The way to get the best numbers is to know the |
| 89 |
|
exact time it took. Since the development of |
| 90 |
|
time machines still have far to go we cannot know the time |
| 91 |
|
for this project before it is finished, but we can look at |
| 92 |
|
similar projects (or parts of) and se how long they took. If |
| 93 |
|
we know how long time a similar project took, then we can |
| 94 |
|
make an estimation that this will take about the same time |
| 95 |
|
(or less of the time of the old project included training |
| 96 |
|
and or innovations, given that the same persons work on |
| 97 |
|
this, or have documented their solution). How to do this is |
| 98 |
|
discussed in section \ref{reusable metrics} |
| 99 |
\subsection{Tracking project progress} |
\subsection{Tracking project progress} |
| 100 |
To track the projects progress we need to collect the metrics for ... and for ... |
While it is of little importance for the CMM level 2, this |
| 101 |
\section{Where and when?} |
has some importance. For the CMM it would be sufficient to |
| 102 |
My place or yours? |
at the end of the project se what the real time of the |
| 103 |
|
activities and the project (at the end of the project). |
| 104 |
|
|
| 105 |
|
However if we do track the progress while working on the |
| 106 |
|
project it is possible to se deviations as they appear and |
| 107 |
|
to be able to act at soon as the deviation is found. Actions |
| 108 |
|
could be to call in more/less people/resources, renegotiate |
| 109 |
|
with the customer or other things. Also it is good to be |
| 110 |
|
able to answer both the customer and the management |
| 111 |
|
truthfully wether the project is on plan or not (if it looks |
| 112 |
|
like it will be able to finish the project in time). |
| 113 |
|
\subsection{Make project development less chaotic and more |
| 114 |
|
structured} |
| 115 |
|
Far to many companies in this industry have problems making |
| 116 |
|
good (time) plans for their projects. If the plan gives to much |
| 117 |
|
time to a team for a project that is not a big problem, but |
| 118 |
|
if the situation is the opposite there is a problem. To be |
| 119 |
|
able to deliver in time this project group must hire |
| 120 |
|
additional resources (if possible), or work more and harder |
| 121 |
|
to be ready on time - or they will not meat the deadline set |
| 122 |
|
for the project. While this don't have a big impact on the |
| 123 |
|
team if it happens only once - it will have a devastating |
| 124 |
|
effect on the teams members if it is repeated. Far to many |
| 125 |
|
people in this business has ``hit the wall'' due to massive |
| 126 |
|
and repeated overwork. |
| 127 |
|
|
| 128 |
|
The better the plans are, the less likely it is to fail. |
| 129 |
|
Also with good followup on the plan errors in it can be |
| 130 |
|
detected as soon as possible, (hopefully) giving more time |
| 131 |
|
to correct the error. |
| 132 |
|
\subsection{Not to make the same mistakes twice and to be |
| 133 |
|
able to understand why certain projects are successful, and |
| 134 |
|
be able to repeat the successes on other projects} |
| 135 |
|
The CMM level 2 is also called the repeatable level, since |
| 136 |
|
its primary goal is to be able to repeat successes. This |
| 137 |
|
means that both the successful methods used (those that gave |
| 138 |
|
a good result) needs to be documented so that these can be |
| 139 |
|
used again - also one must document (and this might even be |
| 140 |
|
more important) the methods that did not work and why so |
| 141 |
|
that this mistake don't have to happen again. Also since |
| 142 |
|
documents on successful and unsuccessful methods are |
| 143 |
|
available it is important that these are studied before |
| 144 |
|
choosing the method to use for a new project. This study |
| 145 |
|
should be made before the project development planning is |
| 146 |
|
even begun. |
| 147 |
|
|
| 148 |
|
However to be able to use this data is must first be |
| 149 |
|
collected. This should be done after the project is |
| 150 |
|
completed (or the method is exchanged for a now one). Data |
| 151 |
|
collected should include the name of the method (if it has |
| 152 |
|
one), a description of it, if it was easy to learn and use, |
| 153 |
|
if it was good or bad and a motivation why. Also the |
| 154 |
|
document should include the project number, so that it is |
| 155 |
|
possible to track down the document to a project. It is the |
| 156 |
|
project manager that is responsible for that the data is |
| 157 |
|
collected and stored in the correct repository (see the |
| 158 |
|
document useful resources on the intranet), however the |
| 159 |
|
project manager is encouraged to include as many as possible |
| 160 |
|
from the project for this. |
| 161 |
|
\subsection{Do measurements so that they are reusable for |
| 162 |
|
estimations in the next project} |
| 163 |
|
\label{reusable metrics} |
| 164 |
|
As have been discussed earlier a real value is better than |
| 165 |
|
an estimated - therefor it is important to after the |
| 166 |
|
project is finished collect metrics (real values) for the |
| 167 |
|
different parts of the project. All the metrics should |
| 168 |
|
contain descriptions of what is measured, how and by whom. |
| 169 |
|
Once that data has been collected it should be stored in the |
| 170 |
|
correct repository (see the document useful resources on the |
| 171 |
|
intranet) in order to be usable by others. |
| 172 |
|
|
| 173 |
|
It is important that what is measured is relevant, and that |
| 174 |
|
all the relevant data is collected. It is of no real |
| 175 |
|
interest in how much caffeine was consumed while it is of |
| 176 |
|
great interest to know how long it took to program and test |
| 177 |
|
one use case. Also the project manager should take time to |
| 178 |
|
think about what metrics he (or she) was missing at the |
| 179 |
|
beginning of the project. |
| 180 |
|
|
| 181 |
|
In section \ref{tools} there are a couple of tools that can |
| 182 |
|
be used for this. The tool we suggest makes the measurements |
| 183 |
|
on the code by it self. |
| 184 |
|
|
| 185 |
|
Parts that had large deviations between estimated and real |
| 186 |
|
values should be collected. Now it is important to show the |
| 187 |
|
estimated value, the real, the task and the reason for the |
| 188 |
|
deviation. This data is collected in order to understand |
| 189 |
|
why estimations deviate from reality and to try and |
| 190 |
|
understand how to minimize the deviations. |
| 191 |
|
\subsection{To be able to make high quality software} |
| 192 |
|
Software quality should not simply be seen as how well the |
| 193 |
|
software conforms with the requirements, but also how |
| 194 |
|
usable it is, how learnable it is and how well it has |
| 195 |
|
found the requirements that were not in the requirements |
| 196 |
|
specification (it is most unusual that the actual end-user |
| 197 |
|
is making the requirements, it is more often someone |
| 198 |
|
higher up in the hierarchy that makes the requirements). |
| 199 |
|
|
| 200 |
|
This does imply it is hard to make high quality software, |
| 201 |
|
something that could be true - thou there is help to be |
| 202 |
|
found. The simplest way is to ask of the customer to be |
| 203 |
|
allowed to talk to one or several of the real end-users |
| 204 |
|
while in the phase of collecting requirements. If this is |
| 205 |
|
not possible then the team gathering the requirements must |
| 206 |
|
think of what is not in the requirements from the |
| 207 |
|
customer. It might help to bring in someone that is close |
| 208 |
|
to the real end-user in this phase (someone with similar |
| 209 |
|
knowledge and work tasks as the end-user), and let he or |
| 210 |
|
she think about the system and how it will be used. |
| 211 |
|
|
| 212 |
|
Also in the testing phase it is important not only to make |
| 213 |
|
certain that the requirements are fulfilled, but also that |
| 214 |
|
the system is usable and that there is nothing that is |
| 215 |
|
missing in the system. Also it is important to think about |
| 216 |
|
human computer interaction questions when developing (and |
| 217 |
|
testing) the system. A system that has all the |
| 218 |
|
functionality is of no use if the end-user cannot use it. |
| 219 |
|
Once again it is needed to bring in a end-user (or as |
| 220 |
|
close as possible) to ensure that the system has all the |
| 221 |
|
parts that is needed to operate it. |
| 222 |
|
\subsection{To introduce Software Configuration Management in |
| 223 |
|
the software development process} |
| 224 |
|
Software Configuration Management (or SCM) is far more then simply |
| 225 |
|
using a version control system for the source code, thou |
| 226 |
|
that is a part of it. SCM can be divided into 4 main |
| 227 |
|
elements. These are: |
| 228 |
|
\begin{enumerate} |
| 229 |
|
\item Version control |
| 230 |
|
\item Build Management |
| 231 |
|
\item Release Management |
| 232 |
|
%\item Process Control |
| 233 |
|
\end{enumerate} |
| 234 |
|
\subsubsection {Version control} |
| 235 |
|
The version control is to keep track of the changes in a |
| 236 |
|
file over time. It should be able to see old versions of |
| 237 |
|
files (and look at them), se who made the changes, when |
| 238 |
|
and why. Fortunately CVS has all that is needed for this |
| 239 |
|
element, so all that is needed is that it should be used |
| 240 |
|
on the project. |
| 241 |
|
\subsubsection {Build Management} |
| 242 |
|
www.webopedia.com defines a build as \emph{``A version of |
| 243 |
|
a software program. The term i usually used in reference |
| 244 |
|
to a program that is still in development.''} |
| 245 |
|
|
| 246 |
|
Builds can be made manually, or using tools (whatever |
| 247 |
|
your team feels best with). A build is most often used to |
| 248 |
|
test part of (or the whole) system. If the team is making |
| 249 |
|
the builds by hand it is important to keep track of what |
| 250 |
|
files are in the build (and the versions) and how the |
| 251 |
|
build was created (compiler options etc). This can be |
| 252 |
|
used later on to debug the build. |
| 253 |
|
\subsubsection {Release Management} |
| 254 |
|
A release is a build, only that the files in the release |
| 255 |
|
has been tested before. A release is what is given to the |
| 256 |
|
customer to evaluate (while development is still in |
| 257 |
|
progress), or to be used (once the program is completed). |
| 258 |
|
%\subsubsection {Process Control} |
| 259 |
|
\section{Where and when in the software development process |
| 260 |
|
should the measurements be conducted?} |
| 261 |
|
The measurements should be conducted just after the project, |
| 262 |
|
when there is no deadline left and yet all is still freshly in |
| 263 |
|
the minds of all that were involved in the project. Also this |
| 264 |
|
is a great time to have the team that has been making the |
| 265 |
|
program ``talk off'' about it. To talk about what went well |
| 266 |
|
and what went bad, why and how to avoid it in the future. |
| 267 |
\section{Who should measure and collect} |
\section{Who should measure and collect} |
| 268 |
Mom? |
The project manager is the person that is responsible for that |
| 269 |
|
the metrics that should be collected is collected. However it |
| 270 |
|
is not necessary that it is the project manager that actually |
| 271 |
|
collects the data. It is however important that the job of |
| 272 |
|
collecting metrics has knowledge of metrics, how to collect, |
| 273 |
|
what is needed to be collected etc (if there is a need to |
| 274 |
|
train one or more on the metrics, consult the training manual |
| 275 |
|
on the intranet). |
| 276 |
|
|
| 277 |
|
Once the data has been collected it should |
| 278 |
|
be handed over to the metric responsible according to the |
| 279 |
|
document useful resources for instructions on both how to |
| 280 |
|
contribute with the new data and how to find old data from |
| 281 |
|
other projects. |
| 282 |
\section{How to store the data} |
\section{How to store the data} |
| 283 |
In a plastic cup |
All the data should be stored in electronic documents in the |
| 284 |
|
document repository. The ordinary standard for documents |
| 285 |
|
should be used. Once a template has been completed for the |
| 286 |
|
metrics gathering document, this will be on the intranet. |
| 287 |
|
|
| 288 |
|
(The repository is accessible by all in the company via the |
| 289 |
|
intranet. The document repository resides on the same server |
| 290 |
|
as the CVS does.) |
| 291 |
\section{Feasibility analysis} |
\section{Feasibility analysis} |
| 292 |
Feasiwho? |
This program has been mainly based on things the company knows |
| 293 |
|
of already, however some training in metrics will be necessary |
| 294 |
|
for at least the project managers. Also document templates will |
| 295 |
|
be needed to be made. |
| 296 |
|
|
| 297 |
|
The templates are important here, and needs to be done as soon |
| 298 |
|
as possible and since they are to be used a lot - it is |
| 299 |
|
recommended to hire one or several metrics experts to make |
| 300 |
|
them in a wa that all important data is in there (both for |
| 301 |
|
this program and for instance for the economical people or |
| 302 |
|
anybody else that could have fun with metrics). It is also |
| 303 |
|
recommended that this (these) people make the training for the |
| 304 |
|
personal that needs it. |
| 305 |
\section{Common problems} |
\section{Common problems} |
| 306 |
Headache |
Common problems that could make an metrics implementation to |
| 307 |
\section{Usefull tools and applications} |
fail includes (and ways to overcome them): |
| 308 |
Hammer and crowbar |
|
| 309 |
|
Inexperience. If the people making the metrics implementation |
| 310 |
|
have little or non experience in how metrics work (real work |
| 311 |
|
experience now, not only theoretical knowledge) then they can |
| 312 |
|
not focus on the parts that are important. Also theory and |
| 313 |
|
practice differs in many ways. Without experience it is to |
| 314 |
|
hard to focus on the meaningful metrics and not get stuck in |
| 315 |
|
those not important for this company (group whatever). |
| 316 |
|
Also it is a lot easier to tell |
| 317 |
|
people out of own experience why things are important, not |
| 318 |
|
simply since it says so in a book. This is being helped by |
| 319 |
|
getting real experience before making an implementation. |
| 320 |
|
|
| 321 |
|
If the company doesn't make people understand that the metrics |
| 322 |
|
implementation is to help the teams and the company make |
| 323 |
|
better products, then if the workers beliefs that the metrics |
| 324 |
|
implementation is being done ether to cut down the staff, or |
| 325 |
|
because they are making bad results and want to be able to |
| 326 |
|
find the person(s) responsible. If this is happening, then the |
| 327 |
|
workers might feed faulty data to the metrics, or try to |
| 328 |
|
sabotage it - then the metrics implementation will fail. This |
| 329 |
|
is avoided by making certain that everybody understands that |
| 330 |
|
this is being done to help them in there work, nothing else. |
| 331 |
|
|
| 332 |
|
To have the implementation badly documented or not to back it |
| 333 |
|
up with the proper training that will be needed. Solutio: make |
| 334 |
|
good documentation and offer them education in the areas that |
| 335 |
|
they will need. |
| 336 |
|
|
| 337 |
|
No support from the management. If the management of the |
| 338 |
|
company is not supporting the implementation then it is very |
| 339 |
|
hard to make a implementation. The management must have |
| 340 |
|
understanding of the implementation. Also they must support |
| 341 |
|
the implementation every way they can once it has begun. It is |
| 342 |
|
also important that management shows a interest in the |
| 343 |
|
implementation once it is on the way. |
| 344 |
|
\section{Useful tools and applications} |
| 345 |
|
\label{tools} |
| 346 |
|
Normal spread sheet applications (like excel) can be used to |
| 347 |
|
gather and present the metrics that are needed for this |
| 348 |
|
program. |
| 349 |
|
|
| 350 |
|
CodeCheck is a tool that is programmable (ie it has to be |
| 351 |
|
programmed, but on the other hand it can get any metrics as |
| 352 |
|
long as it has the correct algorithm). It can also be set up |
| 353 |
|
to interpret the values it gets out. CodeCheck is made by |
| 354 |
|
Abraxas Software Inc. CodeCheck is called to be usable towards |
| 355 |
|
C/C++ programs, and has most of the common metrics already |
| 356 |
|
programmed to it. |
| 357 |
|
|
| 358 |
|
The Object-Oriented Tool is developed by the University of |
| 359 |
|
Magdeburg. The tool uses a predefined metrics set (defined |
| 360 |
|
according to breu, F. B.; Carapuca, R.: Object-Oriented |
| 361 |
|
Software Engineering: Controlling the Software Development |
| 362 |
|
Process. Proceedings of the 4th International Conference on |
| 363 |
|
Software Quality. 1993). Also this tool may be used to make |
| 364 |
|
empirical evaluation of programs. Then it is possible to store |
| 365 |
|
data from old projects and compare with the one being |
| 366 |
|
measured. |
| 367 |
|
|
| 368 |
|
While the Object-Oriented Tool is freeware, and excel a |
| 369 |
|
program that is likely to already be in use at the Company, |
| 370 |
|
our suggestion is the CodeCheck tool. Mainly since it is |
| 371 |
|
flexible enough to support any metrics that we could want to |
| 372 |
|
measure (both today and tomorrow). Also the tool is not bound |
| 373 |
|
towards C/C++ as we understand it, but could be reprogrammed |
| 374 |
|
to support any language. |
| 375 |
\end{document} |
\end{document} |
Parent Directory
| 
Revision Log
| 
Patch