--- 02/assignment2.tex 2003/12/11 16:55:42 1.3 +++ 02/assignment2.tex 2003/12/13 21:04:39 1.11 @@ -85,73 +85,232 @@ where you explain how one could use the structural measures (specify which structural measure) to ensure the quality of the software product.} - svar + %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} - svar + a-b-c-d-e-f-g-h-i-j-k-l-m-n \subsubsection{Branch coverage} - svar + 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} - 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 + 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?} - svar + %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} - svar + See appendix b. \subsection{Measure the use case specifications shown in Design 2 using the chosen use case metrics suite from the lecture} - svar + See appendix c. \subsection{Write a short section (up to ½ page) with answers to the following questions:} - \subsubsection{Which of the two systems presented can be expected to be - more complex and why?} - svar - \subsubsection{Which of the two systems can be expected to require more - effort to be built? Why?} - svar - \textbf{Measuring designs} + \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.} - svar + See appendix b. \subsection{Measure the class diagram presented in Design 2 using the CK metrics suite presented on the lecture.} - svar + See appendix c. \subsection{Measure the code in the files .java from Design 1 with the CK metrics suite presented on the lecture.} - svar + See appendix b. \subsection{ Measure the code in the files .java from Design 2 with the CK metrics suite presented on the lecture.} - svar + 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?} - svar + \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?} - svar + 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?} - svar + 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.} - svar - \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 + 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.} - max 8 sidor + 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}