Software Requirements metrics Fairly primitive and predictive power limited Function Points Count number of inputs and output, user interactions, external interfaces files used Assess each for complexity and multiply by a weighting factor Used to predict size or cost and to assess project productivity Number of requirements errors found (to assess quality) Change request frequency To assess stability of requirements Frequency should decrease over time. If not, requirements analysis may not have been done properly
Software Requirements Metrics Fairly primitive and predictive power limited. Function Points Count number of inputs and output, user interactions, external interfaces, files used. Assess each for complexity and multiply by a weighting factor. Used to predict size or cost and to assess project productivity. Number of requirements errors found (to assess quality) Change request frequency To assess stability of requirements. Frequency should decrease over time. If not, requirements analysis may not have been done properly. �
rogrammer Productivity Metrics Because software intangible, not possible to measure directly If poor quality software produced quickly, may appear to be more productive than if produce reliable and easy to maintain software (measure only over software development phase More does not always mean better May ultimately involve increased system maintenance costs Common measures Lines of source code written per programmer month object instructions produced per programmer month Pages of documentation written per programmer month Test cases written and executed per programmer month
Programmer Productivity Metrics Because software intangible, not possible to measure directly. If poor quality software produced quickly, may appear to be more productive than if produce reliable and easy to maintain software (measure only over software development phase). More does not always mean better. May ultimately involve increased system maintenance costs. Common measures: Lines of source code written per programmer month. Object instructions produced per programmer month. Pages of documentation written per programmer month. Test cases written and executed per programmer month. �
rogrammer Productivity Metrics(2 Take total number of source code lines delivered and divide by total time required to complete project What is a source line of code?(declarations? comments? macros? How treat source lines containing more than a single statement? More productive when use assembly language?( the more expressive the language, the lower the apparent productivity) All tasks subsumed under coding task although coding time represents small part of time needed to complete a project Use number of object instructions generated More objective Difficult to estimate until code actually produced Amount of object code generated dependent on high-level language programming style
Programmer Productivity Metrics (2) Take total number of source code lines delivered and divide by total time required to complete project. What is a source line of code? (declarations? comments? macros?) How treat source lines containing more than a single statement? More productive when use assembly language? (the more expressive the language, the lower the apparent productivity) All tasks subsumed under coding task although coding time represents small part of time needed to complete a project. Use number of object instructions generated. More objective. Difficult to estimate until code actually produced. Amount of object code generated dependent on high-level language programming style. �
Programmer productivity Metrics (3 Using pages of documentation penalizes writers who take time to express themselves clearly and concisely So difficult to give average figure For large, embedded system may be as low as 30 lines/programmer-month Simple business systems may be 600 lines Studies show great variability in individual productivity. Best are twenty times more productive than worst
Programmer Productivity Metrics (3) Using pages of documentation penalizes writers who take time to express themselves clearly and concisely. So difficult to give average figure. For large, embedded system may be as low as 30 lines/programmer-month. Simple business systems may be 600 lines. Studies show great variability in individual productivity. Best are twenty times more productive than worst. �
Software design Metrics · Number of parameters Tries to capture coupling between modules Understanding modules with large number of parameters will require more time and effort (assumption) Modifying modules with large number of parameters likely to have side effects on other modules Number of modules Number of modules called (estimating complexity of maintenance) Fan-in: number of modules that call a particular module Fan-out: how many other modules it calls High fan-in means many modules depend on this module High fan-out means module depends on many other modules Makes understanding harder and maintenance more time-consuming
Software Design Metrics Number of parameters Tries to capture coupling between modules. Understanding modules with large number of parameters will require more time and effort (assumption). Modifying modules with large number of parameters likely to have side effects on other modules. Number of modules. Number of modules called (estimating complexity of maintenance). Fan-in: number of modules that call a particular module. Fan-out: how many other modules it calls. High fan-in means many modules depend on this module. High fan-out means module depends on many other modules. Makes understanding harder and maintenance more time-consuming. �