--- 03/assignment3.tex	2004/01/09 16:38:28	1.4
+++ 03/assignment3.tex	2004/01/16 17:28:11	1.5
@@ -20,29 +20,356 @@
   \tableofcontents
   \newpage
   \pagenumbering{arabic}
+  \section{Introduction}
+    It is far to common that companies working with software
+    development are drawing over the proposed budget (ether in
+    time and or resources). It is also to common that software
+    projects are being terminated since there is no result coming
+    from them.
+
+    The Company has decided that it should do something to make
+    itself not do those things, and also to be able to show
+    potential clients that they will be able to succeed. This is
+    why the Company has decided that it should meet level 2 of the
+    CMM (Capability Maturity Model) the so called repeatable
+    level. The aim of that is to be able to repeat successes from
+    before by reusing successful methods etc.
+
+    Also some customers can require that the companies they hire
+    have CMM gradings so that they can know that they will get
+    what they ordered, on time and target (the cost that would
+    be).
+  \section{The company so far (a.k.a. assumptions)}
+    \begin{itemize}
+      \item The company has been using CVS for the source-code for
+      some time now, mainly to be able to A) have a safe copy (the
+      CVS server is using raid system to make certain that even a
+      disk malfunction wont destroy the code that has been made so
+      far and B) to be able to go back to older code if there is a
+      need for that.
+      \item The company is currently developing in C/C++.
+      \item The company has had its requirements centered around
+      use cases so far.
+      \item The company has agreed to send all its project
+      managers to a course in software metrics so that they all
+      will speak the same language.
+    \end{itemize}
   \section{Goals of the metric program}
     \label{goals}
-    The goals of this metric program are: (Expand these)
+    The goals of this metric program are: %(Expand these)
     \begin{itemize}
-      \item Track project progress (project planning, project tracking)
-      \item Make project development less chaotic and more structured
-      \item Not to make the same mistakes twice
-      \item Do measurements so that they are reusable for estimations in the next project
+      \item To be able to make better estimates (more accurate)
+       for the customer and the management.
+      \item Track project progress (project planning, project
+      tracking).
+      \item Make project development less chaotic and more
+      structured.
+      \item Not to make the same mistakes twice and to be able to understand why certain projects are
+      successful, and be able to repeat the successes on other
+      projects.
+      \item Do measurements so that they are reusable for estimations in the next
+      project.
+      \item To be able to make high quality software.
+      \item To introduce Software Configuration Management in the
+      software development process.
     \end{itemize}
   \section{Achieving the goals}
-    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
+     come up with the following plans:
+    \subsection{To be able to make better (more accurate)
+    estimations for the customer and the management}
+      In order to get the confidence from the customer and the
+      management there it is important to make good and accurate
+      estimates on the project both before and during the phases
+      of the project. If we can get confidence in our estimates
+      from the customers they will choose us before a company that
+      often (or always) makes bad estimations.
+
+      The way to get the best numbers is to know the
+      exact time it took. Since the development of
+      time machines still have far to go we cannot know the time
+      for this project before it is finished, but we can look at
+      similar projects (or parts of) and se how long they took. If
+      we know how long time a similar project took, then we can
+      make an estimation that this will take about the same time
+      (or less of the time of the old project included training
+      and or innovations, given that the same persons work on
+      this, or have documented their solution). How to do this is
+      discussed in section \ref{reusable metrics}
     \subsection{Tracking project progress}
-      To track the projects progress we need to collect the metrics for ... and for ...
-  \section{Where and when?}
-    My place or yours?
+      While it is of little importance for the CMM level 2, this
+      has some importance. For the CMM it would be sufficient to
+      at the end of the project se what the real time of the
+      activities and the project (at the end of the project).
+
+      However if we do track the progress while working on the
+      project it is possible to se deviations as they appear and
+      to be able to act at soon as the deviation is found. Actions
+      could be to call in more/less people/resources, renegotiate
+      with the customer or other things. Also it is good to be
+      able to answer both the customer and the management
+      truthfully wether the project is on plan or not (if it looks
+      like it will be able to finish the project in time).
+    \subsection{Make project development less chaotic and more
+    structured}
+      Far to many companies in this industry have problems making
+      good (time) plans for their projects. If the plan gives to much
+      time to a team for a project that is not a big problem, but
+      if the situation is the opposite there is a problem. To be
+      able to deliver in time this project group must hire
+      additional resources (if possible), or work more and harder
+      to be ready on time - or they will not meat the deadline set
+      for the project. While this don't have a big impact on the
+      team if it happens only once - it will have a devastating
+      effect on the teams members if it is repeated. Far to many
+      people in this business has ``hit the wall'' due to massive
+      and repeated overwork.
+
+      The better the plans are, the less likely it is to fail.
+      Also with good followup on the plan errors in it can be
+      detected as soon as possible, (hopefully) giving more time
+      to correct the error.
+    \subsection{Not to make the same mistakes twice and to be
+    able to understand why certain projects are successful, and
+    be able to repeat the successes on other projects}
+      The CMM level 2 is also called the repeatable level, since
+      its primary goal is to be able to repeat successes. This
+      means that both the successful methods used (those that gave
+      a good result) needs to be documented so that these can be
+      used again - also one must document (and this might even be
+      more important) the methods that did not work and why so
+      that this mistake don't have to happen again. Also since
+      documents on successful and unsuccessful methods are
+      available it is important that these are studied before
+      choosing the method to use for a new project. This study
+      should be made before the project development planning is
+      even begun.
+
+      However to be able to use this data is must first be
+      collected. This should be done after the project is
+      completed (or the method is exchanged for a now one). Data
+      collected should include the name of the method (if it has
+      one), a description of it, if it was easy to learn and use,
+      if it was good or bad and a motivation why. Also the
+      document should include the project number, so that it is
+      possible to track down the document to a project. It is the
+      project manager that is responsible for that the data is
+      collected and stored in the correct repository (see the
+      document useful resources on the intranet), however the
+      project manager is encouraged to include as many as possible
+      from the project for this.
+    \subsection{Do measurements so that they are reusable for
+     estimations in the next project}
+     \label{reusable metrics}
+       As have been discussed earlier a real value is better than
+       an estimated - therefor it is important to after the
+       project is finished collect metrics (real values) for the
+       different parts of the project. All the metrics should
+       contain descriptions of what is measured, how and by whom.
+       Once that data has been collected it should be stored in the
+       correct repository (see the document useful resources on the
+       intranet) in order to be usable by others.
+
+       It is important that what is measured is relevant, and that
+       all the relevant data is collected. It is of no real
+       interest in how much caffeine was consumed while it is of
+       great interest to know how long it took to program and test
+       one use case. Also the project manager should take time to
+       think about what metrics he (or she) was missing at the
+       beginning of the project.
+
+       In section \ref{tools} there are a couple of tools that can
+       be used for this. The tool we suggest makes the measurements
+       on the code by it self.
+
+       Parts that had large deviations between estimated and real
+       values should be collected. Now it is important to show the
+       estimated value, the real, the task and the reason for the
+       deviation. This data is collected in order to understand
+       why estimations deviate from reality and to try and
+       understand how to minimize the deviations.
+     \subsection{To be able to make high quality software}
+        Software quality should not simply be seen as how well the
+        software conforms with the requirements, but also how
+        usable it is, how learnable it is and how well it has
+        found the requirements that were not in the requirements
+        specification (it is most unusual that the actual end-user
+        is making the requirements, it is more often someone
+        higher up in the hierarchy that makes the requirements).
+
+        This does imply it is hard to make high quality software,
+        something that could be true - thou there is help to be
+        found. The simplest way is to ask of the customer to be
+        allowed to talk to one or several of the real end-users
+        while in the phase of collecting requirements. If this is
+        not possible then the team gathering the requirements must
+        think of what is not in the requirements from the
+        customer. It might help to bring in someone that is close
+        to the real end-user in this phase (someone with similar
+        knowledge and work tasks as the end-user), and let he or
+        she think about the system and how it will be used.
+
+        Also in the testing phase it is important not only to make
+        certain that the requirements are fulfilled, but also that
+        the system is usable and that there is nothing that is
+        missing in the system. Also it is important to think about
+        human computer interaction questions when developing (and
+        testing) the system. A system that has all the
+        functionality is of no use if the end-user cannot use it.
+        Once again it is needed to bring in a end-user (or as
+        close as possible) to ensure that the system has all the
+        parts that is needed to operate it.
+     \subsection{To introduce Software Configuration Management in
+     the software development process}
+       Software Configuration Management (or SCM) is far more then simply
+       using a version control system for the source code, thou
+       that is a part of it. SCM can be divided into 4 main
+       elements. These are:
+       \begin{enumerate}
+         \item Version control
+         \item Build Management
+         \item Release Management
+         %\item Process Control
+       \end{enumerate}
+       \subsubsection {Version control}
+         The version control is to keep track of the changes in a
+         file over time. It should be able to see old versions of
+         files (and look at them), se who made the changes, when
+         and why. Fortunately CVS has all that is needed for this
+         element, so all that is needed is that it should be used
+         on the project.
+       \subsubsection {Build Management}
+         www.webopedia.com defines a build as \emph{``A version of
+         a software program. The term i usually used in reference
+         to a program that is still in development.''}
+
+         Builds can be made manually, or using tools (whatever
+         your team feels best with). A build is most often used to
+         test part of (or the whole) system. If the team is making
+         the builds by hand it is important to keep track of what
+         files are in the build (and the versions) and how the
+         build was created (compiler options etc). This can be
+         used later on to debug the build.
+       \subsubsection {Release Management}
+         A release is a build, only that the files in the release
+         has been tested before. A release is what is given to the
+         customer to evaluate (while development is still in
+         progress), or to be used (once the program is completed).
+       %\subsubsection {Process Control}
+  \section{Where and when in the software development process
+  should the measurements be conducted?}
+    The measurements should be conducted just after the project,
+    when there is no deadline left and yet all is still freshly in
+    the minds of all that were involved in the project. Also this
+    is a great time to have the team that has been making the
+    program ``talk off'' about it. To talk about what went well
+    and what went bad, why and how to avoid it in the future.
   \section{Who should measure and collect}
-    Mom?
+    The project manager is the person that is responsible for that
+    the metrics that should be collected is collected. However it
+    is not necessary that it is the project manager that actually
+    collects the data. It is however important that the job of
+    collecting metrics has knowledge of metrics, how to collect,
+    what is needed to be collected etc (if there is a need to
+    train one or more on the metrics, consult the training manual
+    on the intranet).
+
+    Once the data has been collected it should
+    be handed over to the metric responsible according to the
+    document useful resources for instructions on both how to
+    contribute with the new data and how to find old data from
+    other projects.
   \section{How to store the data}
-    In a plastic cup
+    All the data should be stored in electronic documents in the
+    document repository. The ordinary standard for documents
+    should be used. Once a template has been completed for the
+    metrics gathering document, this will be on the intranet.
+
+    (The repository is accessible by all in the company via the
+    intranet. The document repository resides on the same server
+    as the CVS does.)
   \section{Feasibility analysis}
-    Feasiwho?
+    This program has been mainly based on things the company knows
+    of already, however some training in metrics will be necessary
+    for at least the project managers. Also document templates will
+    be needed to be made.
+
+    The templates are important here, and needs to be done as soon
+    as possible and since they are to be used a lot - it is
+    recommended to hire one or several metrics experts to make
+    them in a wa that all important data is in there (both for
+    this program and for instance for the economical people or
+    anybody else that could have fun with metrics). It is also
+    recommended that this (these) people make the training for the
+    personal that needs it.
   \section{Common problems}
-    Headache
+    Common problems that could make an metrics implementation to
+    fail includes (and ways to overcome them):
+
+    Inexperience. If the people making the metrics implementation
+    have little or non experience in how metrics work (real work
+    experience now, not only theoretical knowledge) then they can
+    not focus on the parts that are important. Also theory and
+    practice differs in many ways. Without experience it is to
+    hard to focus on the meaningful metrics and not get stuck in
+    those not important for this company (group whatever).
+    Also it is a lot easier to tell
+    people out of own experience why things are important, not
+    simply since it says so in a book. This is being helped by
+    getting real experience before making an implementation.
+
+    If the company doesn't make people understand that the metrics
+    implementation is to help the teams and the company make
+    better products, then if the workers beliefs that the metrics
+    implementation is being done ether to cut down the staff, or
+    because they are making bad results and want to be able to
+    find the person(s) responsible. If this is happening, then the
+    workers might feed faulty data to the metrics, or try to
+    sabotage it - then the metrics implementation will fail. This
+    is avoided by making certain that everybody understands that
+    this is being done to help them in there work, nothing else.
+
+    To have the implementation badly documented or not to back it
+    up with the proper training that will be needed. Solutio: make
+    good documentation and offer them education in the areas that
+    they will need.
+
+    No support from the management. If the management of the
+    company is not supporting the implementation then it is very
+    hard to make a implementation. The management must have
+    understanding of the implementation. Also they must support
+    the implementation every way they can once it has begun. It is
+    also important that management shows a interest in the
+    implementation once it is on the way.
   \section{Useful tools and applications}
-    Hammer and crowbar
+    \label{tools}
+    Normal spread sheet applications (like excel) can be used to
+    gather and present the metrics that are needed for this
+    program.
+
+    CodeCheck is a tool that is programmable (ie it has to be
+    programmed, but on the other hand it can get any metrics as
+    long as it has the correct algorithm). It can also be set up
+    to interpret the values it gets out. CodeCheck is made by
+    Abraxas Software Inc. CodeCheck is called to be usable towards
+    C/C++ programs, and has most of the common metrics already
+    programmed to it.
+
+    The Object-Oriented Tool is developed by the University of
+    Magdeburg. The tool uses a predefined metrics set (defined
+    according to breu, F. B.; Carapuca, R.: Object-Oriented
+    Software Engineering: Controlling the Software Development
+    Process. Proceedings of the 4th International Conference on
+    Software Quality. 1993). Also this tool may be used to make
+    empirical evaluation of programs. Then it is possible to store
+    data from old projects and compare with the one being
+    measured.
+
+    While the Object-Oriented Tool is freeware, and excel a
+    program that is likely to already be in use at the Company,
+    our suggestion is the CodeCheck tool. Mainly since it is
+    flexible enough to support any metrics that we could want to
+    measure (both today and tomorrow). Also the tool is not bound
+    towards C/C++ as we understand it, but could be reprogrammed
+    to support any language.
 \end{document}