| 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 |
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 |
\subsection{Give an example where code length measure can be useful and an |
| 39 |
example where source code length measure is not useful.} |
| 40 |
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 |
\subsection{Explain what are the main ideas behind Albrecht's Function Points. |
| 51 |
Discuss advantages and disadvantages of the measure. Motivate.} |
| 52 |
%denna var bra http://www.spr.com/products/function.htm |
| 53 |
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 |
\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 |
%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 |
\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 |
See appendix a for the diagram. |
| 116 |
\subsubsection{Statement coverage} |
| 117 |
a-b-c-d-e-f-g-h-i-j-k-l-m-n |
| 118 |
\subsubsection{Branch coverage} |
| 119 |
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 |
\subsubsection{Visit each loop} |
| 123 |
%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 |
\subsection{Calculate the cyclomatic complexity of your program. What does |
| 126 |
this figure tell you?} |
| 127 |
%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 |
\section{OO metrics} |
| 141 |
\textbf{Measuring the use cases} |
| 142 |
%vi skall använda templaten, och bifoga denna... |
| 143 |
\subsection{Measure the use case specifications shown in Design 1 using the |
| 144 |
chosen use case metrics suite from the lecture} |
| 145 |
See appendix b. |
| 146 |
\subsection{Measure the use case specifications shown in Design 2 using the |
| 147 |
chosen use case metrics suite from the lecture} |
| 148 |
See appendix c. |
| 149 |
\subsection{Write a short section (up to ½ page) with answers to the following |
| 150 |
questions:} |
| 151 |
\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 |
svar |
| 158 |
\\ \\ \textbf{Measuring designs} |
| 159 |
\subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the |
| 160 |
lecture.} |
| 161 |
See appendix b. |
| 162 |
\subsection{Measure the class diagram presented in Design 2 using |
| 163 |
the CK metrics suite presented on the lecture.} |
| 164 |
See appendix c. |
| 165 |
\subsection{Measure the code in the files .java from Design 1 with the CK metrics suite |
| 166 |
presented on the lecture.} |
| 167 |
See appendix b. |
| 168 |
\subsection{ Measure the code in the files .java |
| 169 |
from Design 2 with the CK metrics suite presented on the lecture.} |
| 170 |
See appendix c. |
| 171 |
\subsection{Write a short section (up to ½ page) with answers to the following |
| 172 |
questions:} |
| 173 |
\begin{itemize} |
| 174 |
\item Which of the metrics could not be computed based on the class |
| 175 |
diagrams? Why? |
| 176 |
\item Which of the two systems is more complex? Why? |
| 177 |
\end{itemize} |
| 178 |
Svar |
| 179 |
\subsubsection{Which method of gathering metrics - from UML designs or source |
| 180 |
code - is less time consuming?} |
| 181 |
svar |
| 182 |
\section{External product attributes} |
| 183 |
\subsection{Describe how the external product attributes differ from the |
| 184 |
internal ones. Describe the connection between external and |
| 185 |
internal product attributes.} |
| 186 |
The internal attributes can be measured from within the |
| 187 |
system (like loc etc) while for the external attributes |
| 188 |
one must look at the finished product to se the external |
| 189 |
attributes. Also in general internal attributes are |
| 190 |
considered easier to measure (and then predict) then the |
| 191 |
external attributes. |
| 192 |
|
| 193 |
This is partly since the internal attributes can be |
| 194 |
measured more ``directly'' then the external. For |
| 195 |
instance loc is easy to count while usability is a lot |
| 196 |
harder to measure. For the internal attributes one can |
| 197 |
expect to be able to get absolute values while on the |
| 198 |
external attributes one can expect them to be less |
| 199 |
accurate. |
| 200 |
|
| 201 |
However several of the internal attributes (if not all) |
| 202 |
does affect the external attributes in a way that can |
| 203 |
(in most cases) be predicted. One can for instance say |
| 204 |
that in a specific solution if the loc is increased |
| 205 |
(both with comments) then one could expect to get a |
| 206 |
higher maintainability. Also most of the external |
| 207 |
attributes can be affected via the internal if the |
| 208 |
developers keep the external attributes in mind. |
| 209 |
|
| 210 |
In most cases (if not always) the customer of the product |
| 211 |
is more interested in the external attributes. Does this |
| 212 |
mean that the external attributes are of ``greater'' |
| 213 |
value to the team developing the product? |
| 214 |
|
| 215 |
Not always but in many cases. Also one should keep in |
| 216 |
mind that just because the external attributes are more |
| 217 |
important that the internal could be forgotten. |
| 218 |
%\subsection{Assume that you are working at the company that |
| 219 |
%mainly specializes on developing of web-based applications. |
| 220 |
%Your manager gives you an assignment to develop a software |
| 221 |
%quality model for the company. The model should show external |
| 222 |
%quality attributes, corresponding internal attributes and |
| 223 |
%metrics. Present the assumptions that you will use while |
| 224 |
%creating of the quality model. Provide an explanatory text |
| 225 |
%for your model.} %Jag tyckte inte om att läsa den texten;) |
| 226 |
\subsection{Assume that you are working at a company that |
| 227 |
mainly specializes in development of web-based applications. |
| 228 |
Your manager gives you an assignment to develop a software |
| 229 |
quality model for the company. The model should show external |
| 230 |
quality attributes, corresponding internal attributes and |
| 231 |
metrics. Present the assumptions that you will use while |
| 232 |
creating the quality model. Provide an explanatory text |
| 233 |
for your model.} |
| 234 |
Assumptions: We are using an iterative development |
| 235 |
process, we are using function points to measure progress, |
| 236 |
we are using a good configuration management tool, we are |
| 237 |
identifying risks before starting a project, we are, but |
| 238 |
not always using uml for our projects. |
| 239 |
|
| 240 |
Since we are working on web-based applications we also |
| 241 |
assumed that we are selling those to a customer. This made |
| 242 |
us make a value based quality view. This made us decide |
| 243 |
that usability, lernability, reusability, maintainability, reliability, |
| 244 |
is the most important external attributes. The internal |
| 245 |
attributes are not considered as important, other than to |
| 246 |
help up the external. Customer satisfaction does supersede |
| 247 |
this thou. The external attributes has the following |
| 248 |
impact on customer satisfaction: \\ |
| 249 |
\begin{tabular}{|l|l|l|} |
| 250 |
\hline |
| 251 |
Attribute & Importance & Role \\ \hline |
| 252 |
Usability & High & |
| 253 |
Decides if the customer fells that he may use\\ |
| 254 |
& & the product or not. The more usable the product\\ |
| 255 |
& & becomes, the higher value it gets (and thereby\\ |
| 256 |
& & higher quality). \\ \hline |
| 257 |
%hmmm, borde finnas nått bättre sätt... |
| 258 |
Learnability & High & |
| 259 |
The quicker the end-user can learn to use the \\ |
| 260 |
& & program, the quicker he feels the value of the\\ |
| 261 |
& & program and does need it. This makes the \\ |
| 262 |
& & customer feels a gain from buying our product \\ \hline |
| 263 |
Reusability & Medium & |
| 264 |
This is only important if using agreements like\\ |
| 265 |
& & ``avtal 90'' or similar that gives us the freedom\\ |
| 266 |
& & of the developed artifacts, and may use them in\\ |
| 267 |
& & projects to come. If the customer has no demands\\ |
| 268 |
& & on this, and will own the artifacts then it is \\ |
| 269 |
& & not taken into consideration.\\ \hline |
| 270 |
Maintainability & Medium & |
| 271 |
This is only important if we are using the \\ |
| 272 |
& to low & |
| 273 |
reusability from above. And only to support that\\ |
| 274 |
& & purpose. Otherwise this would not have been a \\ |
| 275 |
& & issue at all. \\ \hline |
| 276 |
Reliability & High & |
| 277 |
This is important since a reliable program is \\ |
| 278 |
& & seen as having a higher value. \\ \hline |
| 279 |
\end{tabular} \\ \\ |
| 280 |
Internal attributes are only important in order to gain |
| 281 |
the external attributes. |
| 282 |
\end{document} |
Parent Directory
| 
Revision Log