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 |
jontas |
1.11 |
with low cohesion is ``hard to comprehend, hard to |
205 |
eax |
1.10 |
reuse, hard to maintain and constantly effected by |
206 |
jontas |
1.11 |
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} |