Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Main points of this lecture are: Metrics, Transaction Versus Transform Flow, Dominance, Choosing Modules, Example of Cohesion, Principles of Top-Level Design, Module Decomposition, Kinds of Information Flow, Concept of Project Metric, Software Product
Typology: Study notes
1 / 37
This page cannot be seen from the preview
Don't miss anything!
Transaction versus transform flow Wednesday, September 19, 2012 4:32 PM Docsity.com
Dominance: B, e.g., describes the whole operation. A is preparation, C is postprocessing. Lack of dominance: A, B, C are just steps in a process. In choosing modules and submodules, look for cohesion Dominance Wednesday, September 19, 2012 4:34 PM Docsity.com
From last time: transaction flow data flow inheritance (condition flow) Segregate the kinds of information flow transaction center transform center root class overarching goal (control module) Seek one or more "centers" from which to decompose modules (with some judgement calls as to which centers dominate the design) Build a basic module decomposition outward from the "centers" Refine that decomposition by creating submodules for the centers. General principles of module decomposition Assign modules to workgroups in a manner that achieves balance between workloads. How does one do that? Finally, General principles of top-level design Tuesday, October 13, 2009 2:35 PM Docsity.com
How does one know a project is reasonable? Monday, September 28, 2009 12:11 PM Docsity.com
a function μ() satisfying μ(P)>=0 for all products P. When μ(P)<μ(Q), product P is "less complex than" product Q.
cost(P) = cost of developing P. LOC(P) = lines of code in some version of P in some language.
Function_points(P) = complexity factors in P's description.
Branch_complexity(P) = # if statements + 1 Common examples: A product metric is a measure of the complexity of a software product. It is Metrics Monday, September 28, 2009 12:22 PM Docsity.com
Some simple claims about metrics Wednesday, September 19, 2012 10:30 AM Docsity.com
Another characterization of metrics Wednesday, September 19, 2012 10:26 AM Docsity.com
Hard and soft metrics often vary together. If something is more usable, then it may take more lines of code. There is thus a naive "covariance" relationship between hard and soft concepts. A key idea in metrics: "covariance". Covariance Monday, September 28, 2009 12:31 PM Docsity.com
LOC: only meaningful after program is written. "Function points": a way of estimating complexity from requirements.
Metrics apply to different phases of the engineering process: Kinds of metrics cont'd Monday, September 28, 2009 12:33 PM Docsity.com
Requirements metrics Monday, September 28, 2009 12:35 PM Docsity.com
lines of code (LOC): how many lines of code were necessary to implement the project?
cyclomatic complexity : how many branches were taken in the code? (plus one, see below!)
time spent implementing : person-hours spent actually implementing the project.
Metrics that measure implementations Implementation metrics Monday, September 28, 2009 12:37 PM Docsity.com
While people like to think of project complexity in terms of the number of hours to implement it
Project implementation time is very sensitive to how the project is managed.
"Adding people to a late project makes it later." Brooks Chapter 2: the Mythical Man-Month The "Mythical Man-Month" Monday, September 28, 2009 12:42 PM Docsity.com
branches in the requirements must lead to branches in the design , which lead to branches in the implementation.
data exchanges in the requirements must be in the design, and thus in the implementation.
Thus there is an imprecise relationship between the metrics applicable to various stages of the project.
There is a complex relationship between requirements metrics and the Jackson duality principle. Understanding metrics Monday, September 28, 2009 12:34 PM Docsity.com
The metrics "game" Monday, September 28, 2009 12:45 PM Docsity.com
