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

Diff of /03/assignment3.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by eax, Thu Jan 8 12:18:58 2004 UTC revision 1.5 by jontas, Fri Jan 16 17:28:11 2004 UTC
# Line 20  Line 20 
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}

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.5

root@recompile.se
ViewVC Help
Powered by ViewVC 1.1.26