| 1 |
%Assignment is conducted in pairs. |
| 2 |
%8-12 pages. |
| 3 |
%Deadline 14/1 |
| 4 |
\documentclass[12pt, a4paper]{article} |
| 5 |
\usepackage[latin1]{inputenc} |
| 6 |
|
| 7 |
\begin{document} |
| 8 |
\pagenumbering{roman} |
| 9 |
\title{Assignment 3 - PAC003: Software Metrics, 5p} |
| 10 |
\author{Jonas Petersson \& Mathias Börjeson\\ |
| 11 |
\emph{jopd01@student.bth.se \& tb00mbo@student.bth.se}} |
| 12 |
\maketitle |
| 13 |
\thispagestyle{empty} |
| 14 |
% \begin{centering} |
| 15 |
% Assignment 3 - PAC003: Software Metrics, 5p\\ |
| 16 |
% Jonas Petersson \& Mathias Börjeson\\ |
| 17 |
% \emph{jopd01@student.bth.se \& tb00mbo@student.bth.se}\\ |
| 18 |
% \end{centering} |
| 19 |
\newpage |
| 20 |
\tableofcontents |
| 21 |
\newpage |
| 22 |
\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} |
| 58 |
\label{goals} |
| 59 |
The goals of this metric program are: %(Expand these) |
| 60 |
\begin{itemize} |
| 61 |
\item To be able to make better estimates (more accurate) |
| 62 |
for the customer and the management. |
| 63 |
\item Track project progress (project planning, project |
| 64 |
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} |
| 76 |
\section{Achieving the goals} |
| 77 |
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} |
| 100 |
While it is of little importance for the CMM level 2, this |
| 101 |
has some importance. For the CMM it would be sufficient to |
| 102 |
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} |
| 268 |
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} |
| 283 |
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} |
| 292 |
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} |
| 306 |
Common problems that could make an metrics implementation to |
| 307 |
fail includes (and ways to overcome them): |
| 308 |
|
| 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} |
Parent Directory
| 
Revision Log