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} |