Software diagnosis (also: software diagnostics) refers to concepts, techniques, and tools that allow for obtaining findings, conclusions, and evaluations about software systems and their implementation, composition, behaviour, and evolution. It serves as means to monitor, steer, observe and optimize software development, software maintenance, and software re-engineering in the sense of a business intelligence approach specific to software systems. It is generally based on the automatic extraction, analysis, and visualization of corresponding information sources of the software system. It can also be manually done and not automatic.

Applications

Software diagnosis supports all branches of software engineering, in particular project management, quality management, risk management as well as implementation and test. Its main strength is to support all stakeholders of software projects (in particular during software maintenance and for software re-engineering tasks[1]) and to provide effective communication means for software development projects. For example, software diagnosis facilitates "bridging an essential information gap between management and development, improve awareness, and serve as early risk detection instrument".[2] Software diagnosis includes assessment methods for "perfective maintenance" that, for example, apply "visual analysis techniques to combine multiple indicators for low maintainability, including code complexity and entanglement with other parts of the system, and recent changes applied to the code".[3]

Characteristics

In contrast to manifold approaches and techniques in software engineering, software diagnosis does not depend on programming languages, modeling techniques, software development processes or the specific techniques used in the various stages of the software development process. Instead, software diagnosis aims at analyzing and evaluating the software system in its as-is state and based on system-generated information to bypass any subjective or potentially outdated information sources (e.g., initial software models). For it, software diagnosis combines and relates sources of information that are typically not directly linked. Examples:

  • Source-code metrics are related with software developer activity to gain insight into developer-specific effects on software code quality.[4]
  • System structure and run-time execution traces are correlated to facilitate program comprehension through dynamic analysis in software maintenance tasks.[5]

Principles

The core principle of software diagnosis is to automatically extract information from all available information sources of a given software projects such as source code base, project repository, code metrics, execution traces,[6] test results, etc. To combine information, software-specific data mining, analysis, and visualization techniques are applied. Its strength results, among various reasons, from integrating decoupled information spaces in the scope of a typical software project, for example development and developer activities (recorded by the repository) and code and quality metrics (derived by analyzing source code) or key performance indicators (KPIs).

Examples

Examples of software diagnosis tools include software maps and software metrics.

Critics

Software diagnosis—in contrast to many approaches in software engineering—does not assume that developer capabilities, development methods, programming or modeling languages are right or wrong (or better or worse compared to each other): Software diagnosis aims at giving insight into a given software system and its status regardless of the methods, languages, or models used to create and maintain the system.

References

  1. ↑ Beck, M.; Trümper, J.; Döllner, J. (2011). "A visual analysis and design tool for planning software reengineerings". 2011 6th International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT). IEEE Computer Society. pp. 1–8. doi:10.1109/VISSOF.2011.6069458. ISBN 978-1-4577-0822-0. S2CID 16326080.
  2. ↑ Bohnet, J.; Döllner, J. (2011). "Monitoring Code Quality and Development Activity by Software Maps". Proceedings of the IEEE ACM ICSE Workshop on Managing Technical Debt. Association for Computing Machinery. pp. 9–16. doi:10.1145/1985362.1985365. ISBN 9781450305860. S2CID 17258620.
  3. ↑ Trümper, J.; Beck, M.; Döllner, J. (2012). "A Visual Analysis Approach to Support Perfective Software Maintenance". 2012 16th International Conference on Information Visualisation. IEEE Computer Society. pp. 308–315. doi:10.1109/IV.2012.59. ISBN 978-1-4673-2260-7. S2CID 5988716.
  4. ↑ Limberger, D.; Wasty, B.; Trümper, J.; Döllner, J. (2013). "Interactive software maps for web-based source code analysis". Proceedings of the 18th International Conference on 3D Web Technology. pp. 91–98. doi:10.1145/2466533.2466550. ISBN 9781450321334. S2CID 3040005.
  5. ↑ Trümper, Jonas; Telea, Alexandru; Döllner, Jürgen (2012). "ViewFusion: Correlating Structure and Activity Views for Execution Traces". Theory and Practice of Computer Graphics. The Eurographics Association. pp. 45–52. doi:10.2312/LocalChapterEvents/TPCG/TPCG12/045-052. ISBN 978-3-905673-93-7.
  6. ↑ Bohnet, J. (2010). Visualization of Execution Traces and its Application to Software Maintenance (PhD). Hasso-Plattner-Institut, University of Potsdam.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.