/[cvs]/03/assignment3.tex
ViewVC logotype

Contents of /03/assignment3.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.5 - (show annotations)
Fri Jan 16 17:28:11 2004 UTC (20 years, 9 months ago) by jontas
Branch: MAIN
CVS Tags: HEAD
Changes since 1.4: +341 -14 lines
File MIME type: application/x-tex
*** empty log message ***

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}

root@recompile.se
ViewVC Help
Powered by ViewVC 1.1.26