DOC PREVIEW
Toronto ECE 450 - Lecture 6 - Software Quality Measurements

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Spring 2005 ECE450H1S Software Engineering IILecture 6Software QualityMeasurementsSome materials are based on Fenton’s bookCopyright © Yijun Yu, 2005Spring 2005 ECE450H1S Software Engineering IILast lecture and tutorial …Software Refactoring• We showed the use of refactoringtechniques on understanding software,improving its maintainability• We explained the relationship betweenrefactoring, tuning and restructuring• Any questions related to design patternsand refactoring so far?• ……• The result of such improvements can bemeasured quantitativelySpring 2005 ECE450H1S Software Engineering IIToday …On Software QualityMeasurements1. What are measurements?2. Quality attributes and their metrics– Performance metrics– Complexity metrics3. How do you use these numbers?– Statistic Analysis to gain understanding on projects– Management: Monitoring the evolution of softwaredevelopment4. SummaryReferencesN. Fenton and S. L. Pfleeger. “Software Metrics – A rigorous and practical approach”.International Thompson Computer Press. 1996Spring 2005 ECE450H1S Software Engineering II1. What are measurements?• A relation of the real world is “reflected” inthat of the math world– If A is taller than B, B is taller than C, then A istaller than C• Preserve the relations in your metrics• Software measurements– Software size?LOCLOC – commentsLOC in Python vs. LOC in Fortran?Spring 2005 ECE450H1S Software Engineering II2. Quality that matters• Company A beats company B, because of which reasondo you think?(1) A deliver more features than B(2) A has larger market share(3) A deliver software with fewer bugs(4) A is cheaper• Killer applications– Browser– Chips– Desktop– Operating System– Database Systems• Andy Grove’s story in his book “Only paranoid cansurvive”Spring 2005 ECE450H1S Software Engineering IIA few more remarks• Producing quality products has beenidentified as a key factor in the long termsuccess (i.e. profitability) of organizations• Quality doesn't happen by chance• Quality control must be embedded into theprocess.• The quality movementSpring 2005 ECE450H1S Software Engineering IIWhat is software quality?• Software quality is defined as– Conformance to explicitly stated functional[correctness] and non-functional requirements[performance, security, maintanability, usability, etc.]i.e. Build the software described in the systemRequirements and Specifications– Conformance to explicitly documented developmentstandards, i.e. Build the software the right way– Conformance to implicit characteristics that areexpected of all professionally developed software, i.e.Build software that meets the expectations of areasonable person: in law this is called the principle ofmerchantabilitySpring 2005 ECE450H1S Software Engineering IIManaging Software Quality1. Define what quality means for large softwaresystems2. Measure Quality of a complete or partialsystem3. Devise actions to improve quality of thesoftware– Process improvements• Process Performance improvements => ProductProductivity improvements– Product improvements4. Monitor Quality during development– Software Quality Assurance - a team devoted toencouraging and enforcing quality standardsSpring 2005 ECE450H1S Software Engineering IISome quality attributes and metrics• Performance• Reliability• Correctness• Maintainability• Security• Interoperability• Usability• Extensibility• Reusability• -illities …• Time, Space• MTBF• # Bugs / Size• Size, Structureness• Counter analysis• Integration• …• …• …• …Spring 2005 ECE450H1S Software Engineering II2.1 PerformanceIt is h/w bound, but can be improved by s/w• Moore’s Law = 2x speedup every 18 months• Software improvement for most cases are alsopossible (algorithms, optimizing compiler)• It is sometimes more expensive to applyhardware improvements, sometimes moreexpensive to apply software improvements• Advice: study the bottlenecks in your programusing a profiler– parallelism– localitySpring 2005 ECE450H1S Software Engineering II2.1.1 Moore’s law (Intel)Itanium 2 processor 410,000,000Cell processor 234,000,000http://www.intel.com/research/silicon/mooreslaw.htmSpring 2005 ECE450H1S Software Engineering II2.1.2 Performance metrics• Time, in relation to the input size– CPU cycles, in relation to the input size– Cache misses, in relation to the input size– Network delay, system perf.– Network throughput, system perf.• Space, in relation to the input size– Workload (memory footprint size), in relationto the input size– Network traffic, in relation to the input sizeSpring 2005 ECE450H1S Software Engineering II2.2 Software Complexity• Software code base has increasingcomplexity – Lehman’s Law #2.• As a result, the code is harder to maintain• This is the central theme of SoftwareEngineering• Well-understood complexity metrics– McCabe complexity– Halstead complexity• Advices: refactoring or restructuringSpring 2005 ECE450H1S Software Engineering II2.2.1 Lehman’s law onsoftware complexitySpring 2005 ECE450H1S Software Engineering II2.2.2 Complexity metrics• Source size or compiled size– Lines of code (LOC)– McCabe's complexity|V| + |E| - 2for a control flow graph G=(V, E).– Halstead's Software Science metrics(N1+ N2) log (n1+ n2)N1= operands, N2= operatorsn1= unique operands, n2= unique operators• OO Software Metrics– Cohesion metrics in Packages, Classes, Methods– Coupling metrics in Packages, Classes, MethodsSpring 2005 ECE450H1S Software Engineering II3. How to use them in softwaredevelopment process?1. Modeling2. Satisfiable?3. Selection4. Refactoring5. ReleasingClaim soft-goal:prioritization(bottleneck),metrics,constraints,rationaleClaim soft-goal:refactoringsteps + labelpropagation+++---+++Spring 2005 ECE450H1S Software Engineering IIA toy example• Matrix Multiplicationreal*8 A(512,512),B(512,512),C(512,512)do i = 1 , Mdo j = 1, Ldo k = 1, NC(i,k) = C(i,k) + A(i,j) * B(j,k)• Quality goal: "speedup the program 20xwithout sacrificing the code complexity 4x“Spring 2005 ECE450H1S Software Engineering IISome restructuring examplesLoop unrollingreal*8 A(512,512),B(512,512),C(512,512)do i = 1 , Mdo j = 1, Ldo k = 1, N, 4C(i,k) = C(i,k) + A(i,j) * B(j,k)C(i,k+1) = C(i,k+1) + A(i,j) * B(j,k+1)C(i,k+2) = C(i,k+2) + A(i,j) * B(j,k+2)C(i,k+3) = C(i,k+3) + A(i,j) * B(j,k+3)Spring 2005 ECE450H1S Software Engineering


View Full Document
Download Lecture 6 - Software Quality Measurements
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 6 - Software Quality Measurements and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 6 - Software Quality Measurements 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?