cvs/02/assignment2.tex

%Assignment is conducted in pairs. Max. 8 pages.
\documentclass[12pt, a4paper]{article}
\usepackage[latin1]{inputenc}

\begin{document}
  \pagenumbering{roman}
  \thispagestyle{empty}
  \begin{centering}
    Assignment 1 - PAC003: Software Metrics, 5p\\
    Jonas Petersson \& Mathias Börjeson\\
    \emph{jopd01@student.bth.se \& tb00mbo@student.bth.se}\\
  \end{centering}
  \tableofcontents
  \newpage
  \pagenumbering{arabic}
  \section{Internal product attributes}
    \subsection{Explain how the three aspects of the software size (Length,
    Functionality and Complexity) are supplementing each other to describe
    the notion of software size.}
        %length        = is a physical size of the product
        %functionality = counts the functions supplied by the product
        %complexity    = measures the complexity od underlying problem, or a solution
%utan att ha en aning om hur notationen ser ut drar jag till med följande
        These three supplements each other adding references to
        each other. None of these is useful by itself, but by
        adding them up one can get a better perspective of the
        size of the software. The length itself don't tell
        anything of how large the completed software will be, but
        together with functions and complexity one can understand
        the size of the software. Once the size of the software is
        established one may come with effort estimations, and
        based on those make a budget for what resources the
        project will need. Given these three it is possible to get
        an idea of how productive a programmer is during a time
        unit. It will not be a perfect answer, but it will be
        something that could be used to measure deviations in work
        etc.
    \subsection{Give an example where code length measure can be useful and an
    example where source code length measure is not useful.}
        Code length is useful if it is not going to be used by
        itself. One example of this could be if we are interested
        in how much work is done in a week. Then we could look at
        loc, and also take into account the complexity and the functions provided
        (like loc * complexity / functions or something similar).
        Then loc could be useful.

        Code length is useless if it is used by itself. For
        example the statement I am a good programmer since I
        produce more then n loc per week useless.
    \subsection{Explain what are the main ideas behind Albrecht's Function Points.
    Discuss advantages and disadvantages of the measure. Motivate.}
        %denna var bra http://www.spr.com/products/function.htm
        The main idea behind FP's are to provide  language
        independent metric that can be used no matter what
        language are used. Albrech thought it was wrong that the
        only way to tell effort and cost per effort until he begun
        was in loc. A often used metric to tell productivity was
        cost/loc, and that don't tell anything since different
        languages require different number of loc's to solve the
        same problem. This cost could be lover if the language
        requires a lot of code, but the end cost could still get
        higher if the program takes longer time to complete.
        The main idea behind FP's is to give ways to
        tell cost and productivity in a way that is language
        independent. FP's does satisfy this idea. A easier
        language will get a lower cost/FP and a greater number of
        FP's/person\&month then a more complex language.

        The great advantage with this method is that it is (almost) truly
        language independent, while a disadvantage would be that
        if this is established in the beginning of a project and
        should be used to choose a appropriate language to use, if
        the language is unfamiliar, then these metrics can't be
        computed (like FP's/person\&month). Also this way of presenting
        the result does not take into account training and
        inexperience while showing the result. Also this should
        not be used to compare different projects or groups to se
        the difference between them since this does not take
        everything into account. Also one might be tempted to
        always use the language with the highest productivity,
        this is good in most cases, but sometimes there are other
        factors to sum in, like speed, security etc.
    \subsection{Describe structural measures presented by Fenton. (Control flow
    structure, Data flow structure, Data structure). Give an example
    where you explain how one could use the structural measures
    (specify which structural measure) to ensure the quality of the
    software product.}
        %http://sern.ucalgary.ca/~kliewerc/SENG/623/summaries.htm#sum02 var lite halvbra... det bästa jag kunde hitta dock, + F4...
        Control flow is a diagram with nodes, connected via the
        directed connections showing the possible routs the
        program (or actually the flow of data in the program) may
        take. This could be broken down to several diagrams if it
        gets to large and complex. This diagram can be used to
        decide how many test cases is needed to test the program
        completely.

        The data flow structure could be shown in a module-call
        graph. The module-call graph shows what modules calls what
        other modules, and thereby showing more the flow of
        information within the program. This may also be used to
        show coupling and cohesion in the program.

        The data structure can be measured both locally and
        globally. Locally it is interesting how much data
        structure each data item has, and globally it is the
        amount of data for the system. For the local data
        structures very little research has been done, but for the
        global there are more.
    \subsection{Draw the flow graph for the program, which
    based on the data provided by everyday measurements of the air
    temperature will calculate the maximum, minimum and the most
    commonly occurred temperature (the temperature that occurs twice
    or more) for a given month. Present program paths that has to be
    executed in order to satisfy the following testing strategies:}
        See appendix a for the diagram.
        \subsubsection{Statement coverage}
            a-b-c-d-e-f-g-h-i-j-k-l-m-n
        \subsubsection{Branch coverage}
            a-b-c-d-e-f-g-h-i-j-k-l-m-n \\
            a-b-c-b-c-d-e-g-i-j-k-m-n \\
            a-b-c-d-e-f-g-h-i-j-k-l-m-k-m-n \\
        \subsubsection{Visit each loop}
%osäker på om detta är rätt...jag har bara antagit att man skall göra ett test så att man kör alla looparna
            a-b-c-b-c-d-e-f-g-e-f-g-h-i-g-h-i-j-k-l-m-k-m-n
    \subsection{Calculate the cyclomatic complexity of your program. What does
    this figure tell you?}
        %Cyclomatic complexity (CC) = E - N + p
        %where E = the number of edges of the graph
        %N = the number of nodes of the graph
        %p = the number of connected components
        %http://www.sei.cmu.edu/str/descriptions/cyclomatic.html
        Hopefully you mean McCabe's cyclomatic complexity\\
        % e = no of arcs | n = no of nodes
        e-n+2 | 18 - 14 + 2 = 18 - 16 = 2 \\ %men vad säger nu detta
        This tells us the number of tests we have to do to cover
        each path in the program. It could also be used to give a
        estimation of how complex the final software will be. If
        higher then 20 it should be seen as a high risk project,
        and if higher then 50 as a very high risk project.  %nuffrorna kommer från http://www.sei.cmu.edu/str/descriptions/cyclomatic.html
  \section{OO metrics}
  \textbf{Measuring the use cases}
    %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}
        See appendix b.
    \subsection{Measure the use case specifications shown in Design 2 using the
    chosen use case metrics suite from the lecture}
        See appendix c.
    \subsection{Write a short section (up to ½ page) with answers to the following
    questions:}
        \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.}
          See appendix b.
    \subsection{Measure the class diagram presented in Design 2 using
    the CK metrics suite presented on the lecture.}
          See appendix c.
    \subsection{Measure the code in the files .java from Design 1 with the CK metrics suite
    presented on the lecture.}
          See appendix b.
    \subsection{ Measure the code in the files .java
    from Design 2 with the CK metrics suite presented on the lecture.}
          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?}
              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?}
              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?}
          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
    internal product attributes.}
          The internal attributes can be measured from within the
          system (like loc etc) while for the external attributes
          one must look at the finished product to se the external
          attributes. Also in general internal attributes are
          considered easier to measure (and then predict) then the
          external attributes.

          This is partly since the internal attributes can be
          measured more ``directly'' then the external. For
          instance loc is easy to count while usability is a lot
          harder to measure. For the internal attributes one can
          expect to be able to get absolute values while on the
          external attributes one can expect them to be less
          accurate.

          However several of the internal attributes (if not all)
          does affect the external attributes in a way that can
          (in most cases) be predicted. One can for instance say
          that in a specific solution if the loc is increased
          (both with comments) then one could expect to get a
          higher maintainability. Also most of the external
          attributes can be affected via the internal if the
          developers keep the external attributes in mind.

          In most cases (if not always) the customer of the product
          is more interested in the external attributes. Does this
          mean that the external attributes are of ``greater''
          value to the team developing the product?

          Not always but in many cases. Also one should keep in
          mind that just because the external attributes are more
          important that the internal could be forgotten.
    %\subsection{Assume that you are working at the company that
    %mainly specializes on developing of web-based applications.
    %Your manager gives you an assignment to develop a software
    %quality model for the company. The model should show external
    %quality attributes, corresponding internal attributes and
    %metrics. Present the assumptions that you will use while
    %creating of the quality model. Provide an explanatory text
    %for your model.} %Jag tyckte inte om att läsa den texten;)
    \subsection{Assume that you are working at a company that
    mainly specializes in development of web-based applications.
    Your manager gives you an assignment to develop a software
    quality model for the company. The model should show external
    quality attributes, corresponding internal attributes and
    metrics. Present the assumptions that you will use while
    creating the quality model. Provide an explanatory text
    for your model.}
        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}
1	jontas	1.1	%Assignment is conducted in pairs. Max. 8 pages.
2			\documentclass[12pt, a4paper]{article}
3			\usepackage[latin1]{inputenc}
4
5			\begin{document}
6			\pagenumbering{roman}
7			\thispagestyle{empty}
8			\begin{centering}
9			Assignment 1 - PAC003: Software Metrics, 5p\\
10			Jonas Petersson \& Mathias Börjeson\\
11			\emph{jopd01@student.bth.se \& tb00mbo@student.bth.se}\\
12			\end{centering}
13			\tableofcontents
14			\newpage
15			\pagenumbering{arabic}
16			\section{Internal product attributes}
17			\subsection{Explain how the three aspects of the software size (Length,
18			Functionality and Complexity) are supplementing each other to describe
19			the notion of software size.}
20			%length = is a physical size of the product
21			%functionality = counts the functions supplied by the product
22			%complexity = measures the complexity od underlying problem, or a solution
23			%utan att ha en aning om hur notationen ser ut drar jag till med följande
24			These three supplements each other adding references to
25			each other. None of these is useful by itself, but by
26			adding them up one can get a better perspective of the
27	jontas	1.2	size of the software. The length itself don't tell
28			anything of how large the completed software will be, but
29			together with functions and complexity one can understand
30			the size of the software. Once the size of the software is
31			established one may come with effort estimations, and
32			based on those make a budget for what resources the
33			project will need. Given these three it is possible to get
34			an idea of how productive a programmer is during a time
35			unit. It will not be a perfect answer, but it will be
36			something that could be used to measure deviations in work
37			etc.
38	jontas	1.1	\subsection{Give an example where code length measure can be useful and an
39			example where source code length measure is not useful.}
40	jontas	1.2	Code length is useful if it is not going to be used by
41			itself. One example of this could be if we are interested
42			in how much work is done in a week. Then we could look at
43			loc, and also take into account the complexity and the functions provided
44			(like loc * complexity / functions or something similar).
45			Then loc could be useful.
46
47			Code length is useless if it is used by itself. For
48			example the statement I am a good programmer since I
49			produce more then n loc per week useless.
50	jontas	1.1	\subsection{Explain what are the main ideas behind Albrecht's Function Points.
51			Discuss advantages and disadvantages of the measure. Motivate.}
52	jontas	1.3	%denna var bra http://www.spr.com/products/function.htm
53	jontas	1.2	The main idea behind FP's are to provide language
54			independent metric that can be used no matter what
55			language are used. Albrech thought it was wrong that the
56			only way to tell effort and cost per effort until he begun
57			was in loc. A often used metric to tell productivity was
58			cost/loc, and that don't tell anything since different
59			languages require different number of loc's to solve the
60			same problem. This cost could be lover if the language
61			requires a lot of code, but the end cost could still get
62			higher if the program takes longer time to complete.
63			The main idea behind FP's is to give ways to
64			tell cost and productivity in a way that is language
65			independent. FP's does satisfy this idea. A easier
66			language will get a lower cost/FP and a greater number of
67			FP's/person\&month then a more complex language.
68
69			The great advantage with this method is that it is (almost) truly
70			language independent, while a disadvantage would be that
71			if this is established in the beginning of a project and
72			should be used to choose a appropriate language to use, if
73			the language is unfamiliar, then these metrics can't be
74			computed (like FP's/person\&month). Also this way of presenting
75			the result does not take into account training and
76			inexperience while showing the result. Also this should
77			not be used to compare different projects or groups to se
78			the difference between them since this does not take
79			everything into account. Also one might be tempted to
80			always use the language with the highest productivity,
81			this is good in most cases, but sometimes there are other
82			factors to sum in, like speed, security etc.
83	jontas	1.1	\subsection{Describe structural measures presented by Fenton. (Control flow
84			structure, Data flow structure, Data structure). Give an example
85			where you explain how one could use the structural measures
86			(specify which structural measure) to ensure the quality of the
87			software product.}
88	jontas	1.4	%http://sern.ucalgary.ca/~kliewerc/SENG/623/summaries.htm#sum02 var lite halvbra... det bästa jag kunde hitta dock, + F4...
89			Control flow is a diagram with nodes, connected via the
90			directed connections showing the possible routs the
91			program (or actually the flow of data in the program) may
92			take. This could be broken down to several diagrams if it
93			gets to large and complex. This diagram can be used to
94			decide how many test cases is needed to test the program
95			completely.
96
97			The data flow structure could be shown in a module-call
98			graph. The module-call graph shows what modules calls what
99			other modules, and thereby showing more the flow of
100			information within the program. This may also be used to
101			show coupling and cohesion in the program.
102
103			The data structure can be measured both locally and
104			globally. Locally it is interesting how much data
105			structure each data item has, and globally it is the
106			amount of data for the system. For the local data
107			structures very little research has been done, but for the
108			global there are more.
109	jontas	1.1	\subsection{Draw the flow graph for the program, which
110			based on the data provided by everyday measurements of the air
111			temperature will calculate the maximum, minimum and the most
112			commonly occurred temperature (the temperature that occurs twice
113			or more) for a given month. Present program paths that has to be
114			executed in order to satisfy the following testing strategies:}
115	jontas	1.5	See appendix a for the diagram.
116	jontas	1.1	\subsubsection{Statement coverage}
117	jontas	1.5	a-b-c-d-e-f-g-h-i-j-k-l-m-n
118	jontas	1.1	\subsubsection{Branch coverage}
119	jontas	1.5	a-b-c-d-e-f-g-h-i-j-k-l-m-n \\
120			a-b-c-b-c-d-e-g-i-j-k-m-n \\
121			a-b-c-d-e-f-g-h-i-j-k-l-m-k-m-n \\
122	jontas	1.1	\subsubsection{Visit each loop}
123	jontas	1.5	%osäker på om detta är rätt...jag har bara antagit att man skall göra ett test så att man kör alla looparna
124			a-b-c-b-c-d-e-f-g-e-f-g-h-i-g-h-i-j-k-l-m-k-m-n
125	jontas	1.1	\subsection{Calculate the cyclomatic complexity of your program. What does
126			this figure tell you?}
127	jontas	1.5	%Cyclomatic complexity (CC) = E - N + p
128			%where E = the number of edges of the graph
129			%N = the number of nodes of the graph
130			%p = the number of connected components
131			%http://www.sei.cmu.edu/str/descriptions/cyclomatic.html
132			Hopefully you mean McCabe's cyclomatic complexity\\
133			% e = no of arcs \| n = no of nodes
134			e-n+2 \| 18 - 14 + 2 = 18 - 16 = 2 \\ %men vad säger nu detta
135			This tells us the number of tests we have to do to cover
136			each path in the program. It could also be used to give a
137			estimation of how complex the final software will be. If
138			higher then 20 it should be seen as a high risk project,
139			and if higher then 50 as a very high risk project. %nuffrorna kommer från http://www.sei.cmu.edu/str/descriptions/cyclomatic.html
140	jontas	1.1	\section{OO metrics}
141			\textbf{Measuring the use cases}
142	jontas	1.5	%vi skall använda templaten, och bifoga denna...
143	jontas	1.1	\subsection{Measure the use case specifications shown in Design 1 using the
144			chosen use case metrics suite from the lecture}
145	jontas	1.7	See appendix b.
146	jontas	1.1	\subsection{Measure the use case specifications shown in Design 2 using the
147			chosen use case metrics suite from the lecture}
148	jontas	1.7	See appendix c.
149	jontas	1.1	\subsection{Write a short section (up to ½ page) with answers to the following
150			questions:}
151	jontas	1.7	\begin{itemize}
152			\item Which of the two systems presented can be expected to be
153			more complex and why?
154			\item Which of the two systems can be expected to require more
155			effort to be built? Why?
156			\end{itemize}
157	jontas	1.8	We expect design 2 to become more complex, both since
158			it has more use cases, but also since it has higher
159			values (in general) on the metrics suit.
160
161			We expect design 2 to require more effort to build
162			since it has more use cases and more actions (more
163			functionality). Also since we feel that design 2 has a
164			higher complexity. Also most of the values that we can
165			get out from our metrics suit are greater, both in
166			total and if we count them per use case.
167
168			We feel that it is hard to make good (accurate)
169			estimations based on this suit only and we also feel
170			that while good estimations on use case level can be
171			made using this suit, it is not a good thing to try to
172			make estimations of the system as a whole only based
173	jontas	1.9	on this information.
174	jontas	1.6	\\ \\ \textbf{Measuring designs}
175	jontas	1.1	\subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the
176			lecture.}
177	jontas	1.7	See appendix b.
178	jontas	1.1	\subsection{Measure the class diagram presented in Design 2 using
179			the CK metrics suite presented on the lecture.}
180	jontas	1.7	See appendix c.
181	jontas	1.1	\subsection{Measure the code in the files .java from Design 1 with the CK metrics suite
182			presented on the lecture.}
183	jontas	1.7	See appendix b.
184	jontas	1.1	\subsection{ Measure the code in the files .java
185			from Design 2 with the CK metrics suite presented on the lecture.}
186	jontas	1.7	See appendix c.
187	jontas	1.1	\subsection{Write a short section (up to ½ page) with answers to the following
188			questions:}
189	eax	1.10	\subsubsection{Which of the metrics could not be computed based on the class diagrams? Why?}
190			The LCOM (Lack of Cohesion in Methods) metric could
191			not be computed from the class diagram because LCOM metrics
192			are gathered through counting the number of
193			method-pairs that have no attributes in common and
194			then subtract the number of pairs that do have
195			common attributes. This can not be seen when looking
196			at the class diagram so you have to look at the
197			code to compute it. It would probably be quite handy
198			with a tool that computes this metric automatically
199			since it is very time consuming to do by hand.
200			\subsubsection{Which of the two systems is more complex? Why?}
201			Since Design2 has a lower total LCOM value (140 vs
202			93) it is therefore considered more complex.
203			We draw this conclusion from the lecture and slides about CK metrics, a class
204			with low cohesion is ''hard to comprehend, hard to
205			reuse, hard to maintain and constantly effected by
206			change´´
207	jontas	1.1	\subsubsection{Which method of gathering metrics - from UML designs or source
208			code - is less time consuming?}
209	eax	1.10	You get a much better overview of the system when
210			looking at the UML design and it is much less
211			time consuming than searching through source code after source code to
212			find inheritance, number of children and so on. Some
213			metrics require going through source code though, so you
214			can not get everything from the UML designs, although it
215			would have been handy if it was possible.
216	jontas	1.1	\section{External product attributes}
217			\subsection{Describe how the external product attributes differ from the
218			internal ones. Describe the connection between external and
219			internal product attributes.}
220	jontas	1.5	The internal attributes can be measured from within the
221			system (like loc etc) while for the external attributes
222			one must look at the finished product to se the external
223			attributes. Also in general internal attributes are
224			considered easier to measure (and then predict) then the
225			external attributes.
226
227			This is partly since the internal attributes can be
228			measured more ``directly'' then the external. For
229			instance loc is easy to count while usability is a lot
230			harder to measure. For the internal attributes one can
231			expect to be able to get absolute values while on the
232			external attributes one can expect them to be less
233			accurate.
234
235			However several of the internal attributes (if not all)
236			does affect the external attributes in a way that can
237			(in most cases) be predicted. One can for instance say
238			that in a specific solution if the loc is increased
239			(both with comments) then one could expect to get a
240			higher maintainability. Also most of the external
241			attributes can be affected via the internal if the
242			developers keep the external attributes in mind.
243
244			In most cases (if not always) the customer of the product
245			is more interested in the external attributes. Does this
246			mean that the external attributes are of ``greater''
247			value to the team developing the product?
248
249			Not always but in many cases. Also one should keep in
250			mind that just because the external attributes are more
251			important that the internal could be forgotten.
252			%\subsection{Assume that you are working at the company that
253			%mainly specializes on developing of web-based applications.
254			%Your manager gives you an assignment to develop a software
255			%quality model for the company. The model should show external
256			%quality attributes, corresponding internal attributes and
257			%metrics. Present the assumptions that you will use while
258			%creating of the quality model. Provide an explanatory text
259			%for your model.} %Jag tyckte inte om att läsa den texten;)
260			\subsection{Assume that you are working at a company that
261			mainly specializes in development of web-based applications.
262			Your manager gives you an assignment to develop a software
263			quality model for the company. The model should show external
264			quality attributes, corresponding internal attributes and
265			metrics. Present the assumptions that you will use while
266			creating the quality model. Provide an explanatory text
267	jontas	1.1	for your model.}
268	jontas	1.6	Assumptions: We are using an iterative development
269			process, we are using function points to measure progress,
270			we are using a good configuration management tool, we are
271			identifying risks before starting a project, we are, but
272			not always using uml for our projects.
273
274			Since we are working on web-based applications we also
275			assumed that we are selling those to a customer. This made
276			us make a value based quality view. This made us decide
277			that usability, lernability, reusability, maintainability, reliability,
278			is the most important external attributes. The internal
279			attributes are not considered as important, other than to
280			help up the external. Customer satisfaction does supersede
281			this thou. The external attributes has the following
282			impact on customer satisfaction: \\
283			\begin{tabular}{\|l\|l\|l\|}
284			\hline
285			Attribute & Importance & Role \\ \hline
286			Usability & High &
287			Decides if the customer fells that he may use\\
288			& & the product or not. The more usable the product\\
289			& & becomes, the higher value it gets (and thereby\\
290			& & higher quality). \\ \hline
291			%hmmm, borde finnas nått bättre sätt...
292			Learnability & High &
293			The quicker the end-user can learn to use the \\
294			& & program, the quicker he feels the value of the\\
295			& & program and does need it. This makes the \\
296			& & customer feels a gain from buying our product \\ \hline
297			Reusability & Medium &
298			This is only important if using agreements like\\
299			& & ``avtal 90'' or similar that gives us the freedom\\
300			& & of the developed artifacts, and may use them in\\
301			& & projects to come. If the customer has no demands\\
302			& & on this, and will own the artifacts then it is \\
303			& & not taken into consideration.\\ \hline
304			Maintainability & Medium &
305			This is only important if we are using the \\
306			& to low &
307			reusability from above. And only to support that\\
308			& & purpose. Otherwise this would not have been a \\
309			& & issue at all. \\ \hline
310			Reliability & High &
311			This is important since a reliable program is \\
312			& & seen as having a higher value. \\ \hline
313			\end{tabular} \\ \\
314			Internal attributes are only important in order to gain
315			the external attributes.
316	jontas	1.1	\end{document}