| 112 |
commonly occurred temperature (the temperature that occurs twice |
commonly occurred temperature (the temperature that occurs twice |
| 113 |
or more) for a given month. Present program paths that has to be |
or more) for a given month. Present program paths that has to be |
| 114 |
executed in order to satisfy the following testing strategies:} |
executed in order to satisfy the following testing strategies:} |
| 115 |
|
See appendix a for the diagram. |
| 116 |
\subsubsection{Statement coverage} |
\subsubsection{Statement coverage} |
| 117 |
svar |
a-b-c-d-e-f-g-h-i-j-k-l-m-n |
| 118 |
\subsubsection{Branch coverage} |
\subsubsection{Branch coverage} |
| 119 |
svar |
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} |
\subsubsection{Visit each loop} |
| 123 |
svar |
%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 |
\subsection{Calculate the cyclomatic complexity of your program. What does |
| 126 |
this figure tell you?} |
this figure tell you?} |
| 127 |
svar |
%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} |
\section{OO metrics} |
| 141 |
\textbf{Measuring the use cases} |
\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 |
\subsection{Measure the use case specifications shown in Design 1 using the |
| 144 |
chosen use case metrics suite from the lecture} |
chosen use case metrics suite from the lecture} |
| 145 |
svar |
See appendix b. |
| 146 |
\subsection{Measure the use case specifications shown in Design 2 using the |
\subsection{Measure the use case specifications shown in Design 2 using the |
| 147 |
chosen use case metrics suite from the lecture} |
chosen use case metrics suite from the lecture} |
| 148 |
svar |
See appendix c. |
| 149 |
\subsection{Write a short section (up to ½ page) with answers to the following |
\subsection{Write a short section (up to ½ page) with answers to the following |
| 150 |
questions:} |
questions:} |
| 151 |
\subsubsection{Which of the two systems presented can be expected to be |
\begin{itemize} |
| 152 |
more complex and why?} |
\item Which of the two systems presented can be expected to be |
| 153 |
svar |
more complex and why? |
| 154 |
\subsubsection{Which of the two systems can be expected to require more |
\item Which of the two systems can be expected to require more |
| 155 |
effort to be built? Why?} |
effort to be built? Why? |
| 156 |
svar |
\end{itemize} |
| 157 |
\textbf{Measuring designs} |
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 |
|
on this information. |
| 174 |
|
\\ \\ \textbf{Measuring designs} |
| 175 |
\subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the |
\subsection{Measure the class diagram presented in Design 1 using the CK metrics suite presented on the |
| 176 |
lecture.} |
lecture.} |
| 177 |
svar |
See appendix b. |
| 178 |
\subsection{Measure the class diagram presented in Design 2 using |
\subsection{Measure the class diagram presented in Design 2 using |
| 179 |
the CK metrics suite presented on the lecture.} |
the CK metrics suite presented on the lecture.} |
| 180 |
svar |
See appendix c. |
| 181 |
\subsection{Measure the code in the files .java from Design 1 with the CK metrics suite |
\subsection{Measure the code in the files .java from Design 1 with the CK metrics suite |
| 182 |
presented on the lecture.} |
presented on the lecture.} |
| 183 |
svar |
See appendix b. |
| 184 |
\subsection{ Measure the code in the files .java |
\subsection{ Measure the code in the files .java |
| 185 |
from Design 2 with the CK metrics suite presented on the lecture.} |
from Design 2 with the CK metrics suite presented on the lecture.} |
| 186 |
svar |
See appendix c. |
| 187 |
\subsection{Write a short section (up to ½ page) with answers to the following |
\subsection{Write a short section (up to ½ page) with answers to the following |
| 188 |
questions:} |
questions:} |
| 189 |
\subsubsection{Which of the metrics could not be computed based on the class |
\subsubsection{Which of the metrics could not be computed based on the class diagrams? Why?} |
| 190 |
diagrams? Why?} |
The LCOM (Lack of Cohesion in Methods) metric could |
| 191 |
svar |
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?} |
\subsubsection{Which of the two systems is more complex? Why?} |
| 201 |
svar |
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 |
\subsubsection{Which method of gathering metrics - from UML designs or source |
\subsubsection{Which method of gathering metrics - from UML designs or source |
| 208 |
code - is less time consuming?} |
code - is less time consuming?} |
| 209 |
svar |
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 |
\section{External product attributes} |
\section{External product attributes} |
| 217 |
\subsection{Describe how the external product attributes differ from the |
\subsection{Describe how the external product attributes differ from the |
| 218 |
internal ones. Describe the connection between external and |
internal ones. Describe the connection between external and |
| 219 |
internal product attributes.} |
internal product attributes.} |
| 220 |
svar |
The internal attributes can be measured from within the |
| 221 |
\subsection{Assume that you are |
system (like loc etc) while for the external attributes |
| 222 |
working at the company that mainly specializes on developing of |
one must look at the finished product to se the external |
| 223 |
web-based applications. Your manager gives you an assignment to |
attributes. Also in general internal attributes are |
| 224 |
develop a software quality model for the company. The model should |
considered easier to measure (and then predict) then the |
| 225 |
show external quality attributes, corresponding internal |
external attributes. |
| 226 |
attributes and metrics. Present the assumptions that you will use |
|
| 227 |
while creating of the quality model. Provide an explanatory text |
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 |
for your model.} |
for your model.} |
| 268 |
max 8 sidor |
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 |
\end{document} |
\end{document} |
Parent Directory
| 
Revision Log
| 
Patch