-Nofiya Shaik -Sugandhi Madiraju

1. COSMIC Full Function Pointsand Software Testing and Reliability Early Warning (STREW) for Software Quality Assurance. -Nofiya Shaik -Sugandhi Madiraju

2. Overview • Software Quality Assurance (SQA). • Why is it so important? • Metrics for Software Quality. • COSMIC Full Function Points( CFFP). • CFFP Summary. • Software Testing and Reliability Early Warning (STREW). • Comparison. • Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). • Conclusion. • References.

3. Software Quality Assurance (SQA) • SQA is a planned and systematic pattern of actions that are required to ensure quality in software. • Quality (a subjective term-Is there any way to measure it?) -Reasonably bug-free. - Delivered on time and within budget. - Meets requirements and/or expectations. - Maintainable. • Makes sure that any agreed upon standards and procedures are followed. • Ensures that problems are found and dealt with. • Oriented to 'prevention‘.

4. Software Quality Assurance (SQA)…….. • Involves the entire software development PROCESS. • Common problems in the software development process: - Poor requirements. - Unrealistic Schedule. - Inadequate Testing. - Switch to new features. - Miscommunication. • Solutions: - Solid Requirements. - Realistic Schedules. - Adequate Testing. - Communication.

5. Why is it so important? • Some recent major computer system failures caused by software bugs -Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day. - A May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.

6. Quality Metrics • Answer is “YES”. • Direct and Indirect measures. • Internal and External Metrics. • A new Quantitative measurement technique - COSMIC Full Function Points (CFFP). - Based on External metrics. -The metrics in this method totally depend on the data available only at the architectural level. - Metrics then applied to measure Quality attributes like Maintainability, Usability, and Reliability based on ISO 1926 Quality standards.

7. COSMIC Full Function Points • Software Architecture: A set of components, connectors and configurations. • Components are computational elements. • Connectors are interactions between components. • Configurations are the resulting structure of topology of the architecture. • Applies a set of rules and procedures to software • Result - numerical "value of quantity”, represents the functional size of the software.

8. COSMIC Full Function Points…

9. COSMIC Full Function Points… • All measures are based on four data movement types: Entry, Exit, Read and Write. • Coupling or inter-layer connectivity : Indicates the degree of connectivity between functional processes in one layer with that of the other. • Cohesion or intra-layer connectivity : The degree of connectivity between functional processes in a layer. • System Complexity at the architectural level can be defined as the complexity of the structures that make up the entire architecture and their interfaces.

10. COSMIC Full Function Points…

11. CFFP Summary • From this quality attributes are defined. • These attributes in addition to coupling, cohesion and complexity alone do not determine a better architecture. Other important quality attributes are to be considered and quantified to obtain more accuracy.

12. Software Testing and Reliability Early Warning (STREW). • It is a metric suited for OO languages. • It is an early indicator of software reliability and provides feedback to the developer on the quality of the testing effort. • Follows extreme programming (XP) software development methodology. • early warning can be built from a collection of internal metrics. • The set of internal project metrics that comprise STREW-OO are: • 1. Number of test cases/source lines of code (R1); • 2. Number of test cases/number of requirements (R2); • 3. Test lines of code/source lines of code (R3); • 4. Number of asserts/source lines of code (R4);and • 5. Code coverage (C) based on statement-level coverage.

13. Comparison. • From CFFP external quality attributes maintainability, reliability and usability are quantified. These attributes in addition to coupling, cohesion and complexity alone do not determine a better architecture. To be more accurate other important quality attributes are also to be considered. • STREW methodology explains about the internal metrics, which enables early reliability warning. But this is developed only for XP software development methodology.

14. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). • Practices: • Iterative Software Development • Quality as an objective • Continuously verification of quality • Customer requirements • Architecture driven • Focus on teams • Pair programming • Tailoring with restrictions • Configuration and Change Management • Risk management

15. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Iterative Software Development • To establish higher SQA, SDP should be iterative and increment development approach. • Iterative software development is characterized by refining and improving artifacts in several iteration cycles • Incremental software development means to start with a draft version of an artifact in the initial iteration and to extend and refine it through the following iterations. • Iteration cycles include all development activities analysis, design, implementation, testing and finally deployment • Quality assurance can be applied more effectively during the overall process • By using an iterative approach, a process gains more flexibility in dealing with changing requirements or scope. • XP builds on a very strict iterative approach, demanding a daily build of all components. This limits the time needed to encounter errors and forces developers to fix a problem as soon as possible.

16. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Quality as an objective • A software development process needs to define quality as a major objective to improve overall software quality • Quality targets have to be defined and documented by involving the project team and the customer • The MSF defines the qualitative targets of the project at the beginning and stresses the fulfillment of these goals as a major part of the project

17. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Continuously verification of quality • A set of procedures that document every change during the project is required to finally ensure quality • Not only project status reports, but also assessments of the current activities and possible changes are needed to identify problems as soon as possible. • To support these procedures, every project needs a defined process to managed changes. • Continuously verifying quality includes extensive testing • Besides internal testing, external acceptance tests with the customer are needed too in order to verify that the product fulfils the needs and requirements of the customer • A software development process must therefore include a testing workflow throughout the complete process, including external tests with the end users to ensure high software quality.

18. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Customer requirements • The needs and wishes of the customer, who normally does not have a deep technical knowledge, have to be documented so that developers are able to build an application based on that information • The software development process has to ensure that not only the customer, but also the end users are involved in the requirements process • A software development process has to define procedures to train the end users to use the final product

19. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Architecture driven • Well designed architecture allows easy integration and reuse, so a software development process has to be architecture driven. • Focus on teams • A team has to be seen as a set of equal persons, who together are responsible for the quality and success of a project. • A software development process has to include a well-defined team structure, including an efficient task assignment and clear communication guidelines • The MSF “team of peers” assigns equal value on each role and team member

20. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Pair programming • XP demonstrates how two developers can complement each other rather than inhibiting each other • One developer implements the current method while the other is working on integration issues • This approach saves time, and minimizes the number of errors. Better solutions are more likely since two persons most likely have different perspectives of the same problem and therefore, complement each other in solving it.

21. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Tailoring with restrictions • A software development process has to be defined and formalized in way regarding its application to a wide set of projects. • A process that concentrates on a small or specialized set of projects ensures high quality in a particular environment. • Process should be adaptable to a variety of projects based on its core elements. • A high number of core elements do not necessarily improve the quality of the final product • A software development process should therefore rely on core elements

22. Rational Unified Process (RUP), Microsoft Solution Framework (MSF) and Extreme Programming (XP). (contd..) • Risk Management • A well-defined risk awareness and mitigation management form together an effective risk management and is a key factor in achieving high product quality • Risk management enables early risk mitigation and the possibility to act instead of to react to problems and risks • The MSF introduces its own model for risk management. It consequently emphasizes on discipline as an essential for keeping a project on track improving overall delivery quality • Risk management as a part of daily meetings and other disciplines implies that identifying and managing risks becomes less important since the project team is occupied with other issues. The project becomes susceptible to risk factors

23. Conclusion • Development of Software quality assurance techniques and other practices are described. • A software quality assurance strategy which defines both external metrics and internal metrics that are applicable to XP, MSF and RUP software development processes can be an area of further research.

24. References • Software Quality Assurance through COSMIC FFP G.Zayaraz, Dr. P. Thambidurai, Madhu Srinivasan, Dr. Paul Rodrigues ACM September 2005 • Toward a Software Testing and Reliability Early Warning Metric SuiteNachiappan Nagappan, Proceedings of the 26th International Conference on Software Engineering 2004 • Software quality development and assurance in RUP, MSF and XP: a comparative study, Wolfgang Zuser, Stefan Heil, Thomas Grechenig,Proceedings of the third workshop on Software quality,ACM 2005. • Alain Abran, Olga Ormandjieva, Manar Abu Talib (2004), “Information Theory –based Functional Complexity Measures and Functional Size with COSMIC-FFP”, IWSM, MetriKon 2004. • Zhao (2001), “Architectural-Level Metrics for Software Systems”, Proceedings of the 6th International Conference for Young Computer Scientists, pp.29-33, Hangzhou, China, October 2001

25. References • Reinder J.Bril, Andre Postma (2001), “An Architectural Connectivity Metric and Its Support for Incremental Re-architecting of Large Legacy Systems”, IEEE Transactions on Software. • G.Zayaraz, P.Thambidurai, Madhu Srinivasan, Paul Rodri-gues (2005), “Software Architectural Quality Assessment Through COSMIC FFP”, Proceedings of the National Conference on Prod-uct Development with Mechatronic Systems for Global Quality, • Stephen H. Kan (2003), “Mertrics and Models in Software Quality Engineering”, Pearson Education Publications, Low Price Edition, pp. 311-328. • ISO/IEC, DIS 14598-1 Information Technology – Software Product Evaluation. 1996. • Basili V., Briand, L., Melo, W., A Validation of Object Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering, 1996. Vol. 22: p. 751 - 761. • Early Estimation of software quality using In-Process Testing metrics : Acontroled case study, Nachiappan Nagappan, Laurie Williams, Mladen Vouk, Jason Osborne