142 |
%vi skall använda templaten, och bifoga denna... |
%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 |
265 |
metrics. Present the assumptions that you will use while |
metrics. Present the assumptions that you will use while |
266 |
creating the quality model. Provide an explanatory text |
creating the quality model. Provide an explanatory text |
267 |
for your model.} |
for your model.} |
268 |
%huh? - jag kollar på denna... men vill du ha den så;) |
Assumptions: We are using an iterative development |
269 |
max 8 sidor (totalt; inte på denna;) |
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} |