1 |
eax |
1.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 |
jontas |
1.5 |
\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 |
eax |
1.1 |
\section{Goals of the metric program} |
58 |
eax |
1.2 |
\label{goals} |
59 |
jontas |
1.5 |
The goals of this metric program are: %(Expand these) |
60 |
eax |
1.1 |
\begin{itemize} |
61 |
jontas |
1.5 |
\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 |
eax |
1.1 |
\end{itemize} |
76 |
|
|
\section{Achieving the goals} |
77 |
jontas |
1.5 |
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 |
eax |
1.2 |
\subsection{Tracking project progress} |
100 |
jontas |
1.5 |
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 |
eax |
1.1 |
\section{Who should measure and collect} |
268 |
jontas |
1.5 |
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 |
eax |
1.1 |
\section{How to store the data} |
283 |
jontas |
1.5 |
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 |
eax |
1.1 |
\section{Feasibility analysis} |
292 |
jontas |
1.5 |
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 |
eax |
1.2 |
\section{Common problems} |
306 |
jontas |
1.5 |
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 |
eax |
1.4 |
\section{Useful tools and applications} |
345 |
jontas |
1.5 |
\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 |
eax |
1.1 |
\end{document} |