--- 02/assignment2.tex	2003/12/11 21:20:48	1.5
+++ 02/assignment2.tex	2003/12/13 21:04:39	1.11
@@ -142,41 +142,77 @@
     %vi skall använda templaten, och bifoga denna...
     \subsection{Measure the use case specifications shown in Design 1 using the
     chosen use case metrics suite from the lecture}
-        svar
+        See appendix b.
     \subsection{Measure the use case specifications shown in Design 2 using the
     chosen use case metrics suite from the lecture}
-        svar
+        See appendix c.
     \subsection{Write a short section (up to ½ page) with answers to the following
     questions:}
-        \subsubsection{Which of the two systems presented can be expected to be
-             more complex and why?}
-                svar
-        \subsubsection{Which of the two systems can be expected to require more
-            effort to be built? Why?}
-                svar
-  \textbf{Measuring designs}
+        \begin{itemize}
+            \item Which of the two systems presented can be expected to be
+            more complex and why?
+            \item Which of the two systems can be expected to require more
+            effort to be built? Why?
+        \end{itemize}
+            We expect design 2 to become more complex, both since
+            it has more use cases, but also since it has higher
+            values (in general) on the metrics suit.
+
+            We expect design 2 to require more effort to build
+            since it has more use cases and more actions (more
+            functionality). Also since we feel that design 2 has a
+            higher complexity. Also most of the values that we can
+            get out from our metrics suit are greater, both in
+            total and if we count them per use case.
+
+            We feel that it is hard to make good (accurate)
+            estimations based on this suit only and we also feel
+            that while good estimations on use case level can be
+            made using this suit, it is not a good thing to try to
+            make estimations of the system as a whole only based
+            on this information.
+  \\ \\ \textbf{Measuring designs}
   \subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the
     lecture.}
-          svar
+          See appendix b.
     \subsection{Measure the class diagram presented in Design 2 using
     the CK metrics suite presented on the lecture.}
-          svar
+          See appendix c.
     \subsection{Measure the code in the files .java from Design 1 with the CK metrics suite
     presented on the lecture.}
-          svar
+          See appendix b.
     \subsection{ Measure the code in the files .java
     from Design 2 with the CK metrics suite presented on the lecture.}
-          svar
+          See appendix c.
     \subsection{Write a short section (up to ½ page) with answers to the following
     questions:}
-        \subsubsection{Which of the metrics could not be computed based on the class
-        diagrams? Why?}
-            svar
+        \subsubsection{Which of the metrics could not be computed based on the class diagrams? Why?}
+              The LCOM (Lack of Cohesion in Methods) metric could
+              not be computed from the class diagram because LCOM metrics
+              are gathered through counting the number of
+              method-pairs that have no attributes in common and
+              then subtract the number of pairs that do have
+              common attributes. This can not be seen when looking
+              at the class diagram so you have to look at the
+              code to compute it. It would probably be quite handy
+              with a tool that computes this metric automatically
+              since it is very time consuming to do by hand.
         \subsubsection{Which of the two systems is more complex? Why?}
-            svar
+              Since Design2 has a lower total LCOM value (140 vs
+              93) it is therefore considered more complex.
+              We draw this conclusion from the lecture and slides about CK metrics, a class
+              with low cohesion is ``hard to comprehend, hard to
+              reuse, hard to maintain and constantly effected by
+              change''
         \subsubsection{Which method of gathering metrics - from UML designs or source
         code - is less time consuming?}
-            svar
+          You get a much better overview of the system when
+          looking at the UML design and it is much less
+          time consuming than searching through source code after source code to
+          find inheritance, number of children and so on. Some
+          metrics require going through source code though, so you
+          can not get everything from the UML designs, although it
+          would have been handy if it was possible.
   \section{External product attributes}
     \subsection{Describe how the external product attributes differ from the
     internal ones. Describe the connection between external and
@@ -229,6 +265,52 @@
     metrics. Present the assumptions that you will use while
     creating the quality model. Provide an explanatory text
     for your model.}
-%huh? - jag kollar på denna... men vill du ha den så;)
-        max 8 sidor (totalt; inte på denna;)
+        Assumptions: We are using an iterative development
+        process, we are using function points to measure progress,
+        we are using a good configuration management tool, we are
+        identifying risks before starting a project, we are, but
+        not always using uml for our projects.
+
+        Since we are working on web-based applications we also
+        assumed that we are selling those to a customer. This made
+        us make a value based quality view. This made us decide
+        that usability, lernability, reusability, maintainability, reliability,
+        is the most important external attributes. The internal
+        attributes are not considered as important, other than to
+        help up the external. Customer satisfaction does supersede
+        this thou. The external attributes has the following
+        impact on customer satisfaction: \\
+        \begin{tabular}{|l|l|l|}
+            \hline
+            Attribute       & Importance    & Role \\ \hline
+            Usability       & High          &
+                Decides if the customer fells that he may use\\
+            & & the product or not. The more usable the product\\
+            & &  becomes, the higher value it gets (and thereby\\
+            & &  higher quality).   \\ \hline
+%hmmm, borde finnas nått bättre sätt...
+            Learnability    & High          &
+                The quicker the end-user can learn to use the \\
+            & & program, the quicker he feels the value of the\\
+            & & program and does need it. This makes the \\
+            & & customer feels a gain from buying our product \\ \hline
+            Reusability     & Medium        &
+                This is only important if using agreements like\\
+            & & ``avtal 90'' or similar that gives us the freedom\\
+            & & of the developed artifacts, and may use them in\\
+            & & projects to come. If the customer has no demands\\
+            & & on this, and will own the artifacts then it is \\
+            & & not taken into consideration.\\ \hline
+            Maintainability & Medium    &
+                This is only important if we are using the \\
+            & to low &
+                reusability from above. And only to support that\\
+            & & purpose. Otherwise this would not have been a \\
+            & & issue at all. \\ \hline
+            Reliability     & High      &
+                This is important since a reliable program is \\
+            & & seen as having a higher value. \\ \hline
+        \end{tabular} \\ \\
+        Internal attributes are only important in order to gain
+        the external attributes.
 \end{document}
