Lecture Quality and Configuration Management What changed? Is it ready to ship?

1. CS 540 – Quantitative Software Engineering Lecture Quality and Configuration Management What changed? Is it ready to ship?

2. Kruchten’s “4 + 1”Model for Developing a Software Architecture + 1 Business Scenario View 1 View 2 Process -- System Integrators Logical -- End Users + 1 Business Scenario View 4 View 3 Development -- Programmers& Manufacturers Physical -- Engineers + 1 Business Scenario

3. Conceptual Transition TO Link Compile Test FROM Specify Design Code Test

4. Building Blocks • Components • Modules • Interfaces • Configurations • Source Code • Intermediate Language • Object code files • Executables

5. Benefits of modular programming • Potential reduced development time as separate groups work on each module with little need for communication: • Product flexibility- it should be possible to make drastic changes to one module without a need to change others. • Comprehensibility- it should be possible to study the system one module at a time. The whole system can therefore be better designed because it is better understood. “On the Criteria To Be Used in Decomposing Systems into Modules” D.L. Parnas, Carnegie-Mellon University Communications of the ACM Number 12, Volume 1, December 1972 pp 1053-1059

6. What Is modularization? • A “module” is considered programmerresponsibility assignment rather than a subprogram. • The modularizations include the design decisions which must be made before the work on independent modules can begin. • Quite different decisions may be included for each alternative, but in all cases the intention is to describe all “system level” decisions (i.e. decisions which affect more than one module). Op. cit Parnas

7. A KWIC Index Production System The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be “circularly shifted” by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order. • Module 1: Input • Module 2: Circular Shift. • Module 3: Alphabetizing. • Module 4: Output. • Module 5: Master Control. Op. cit. Parnas

8. Usual Modularization This is a modularization in the sense meant by all proponents of modular programming. The system is divided into a number of modules with well-defined interfaces; each one is small enough and simple enough to be thoroughly understood and well programmed. Experiments on a small scale indicate that this is approximately the decomposition which would be proposed by most programmers for the task specified. Op. Cit. Parnas

9. Information Hiding Modularization Module 1: Line Storage. CHAR(r,w,c) will have as value an integer representing the cth character in the rth line, wth word. SETCHAR(r,w,c,d)will cause the cth character in the wth word of the rth line to be the character represented by d or CHAR(r,w,c) = d WORDS(r)returns the number of words in line r. Knowledge of the exact way that the lines are stored is entirely hidden from all other modules so that any change in the manner of storage is confined to this module! Module 2: Input Module 3: Circular Shift Module 4: Alphabetizing Module 5: Output Module 6: Master Control Op. Cit. Parnas

10. Brooks Chpt 6:On the life of a spec • Baselines: The program manager (customer) and project manager (supplier) agreed to document • Analyze and prioritize changes • Control Source • Each specification section should have one author. • State what the specification covers, what it is does not cover and any constraints. • Test early and often

11. “When there are several standards, there is no standard!”

12. Configuration Management • Not a simple task! • Different versions of software usually is in the field during the life cycle • Different parts of the team are on different versions of the software and documents • The same release of a software product may have multiple versions consisting of different combinations of software components • Configuration management is both a development and production issue

13. Baseline • IEEE - “reviewed and agreed upon basis for further development which can be changed only through formal control procedures” • Contained in the baseline are configuration items: source, objects, requirements • Configuration management maintains integrity of these artifacts • Major error- retrace steps through code, design documents and requirements specification -TRACEABILITY

15. Workflow of CR (MR) Change Request rejected Investigate CR Notify CR owner Change approved Deferred Request info from CR owner Prepare & sched work package Prioritized work package Implement change Updated configuration items

16. Configuration Management Tools • Manage the workflow of CRs • If item is to be changed, developer checks it out and item is locked to other users • When item check back in revision history is stored • All versions are recoverable • Should be able to accommodate branching - necessary more times than you think! • Configuration management tools are very sophisticated, keeps only the changes, the deltas and the remarks, timestamps and who did what - essential for Buildmeister and testers • New tools are change oriented release configuration is identified by a baseline plus a set of changes.

17. Configuration Management Plan • Main parts: • Management: how project is organized and who has responsibilities related to configuration management. How are change requests handled? • Activities: • Who is on CCB, what are their responsibilities • What reports are required • What data is collected and archived - IMPORTANT

18. The Make commandhttp://www.eng.hawaii.edu/Tutor/Make/1.html • Manages large programs or groups of programs. As you begin to write larger programs, you will notice that re-compiling larger programs takes much longer than re-compiling short programs. Moreover, you notice that you usually only work on a small section of the program (such as a single function that you are debugging), and much of the rest of the program remains unchanged. • Tracks those portions of the entire program that change, compiling only the parts of the program that changed since the last compile.

19. A simple compilation

20. Compiling with several large files cc green.c blue.c

21. Separate compilation Use the -c option with cc to create the corresponding object (.o) file from a .c file. For example, typing the command: cc -c green.c will not produce an a.out file, but the compiler will stop after the assembler stage, leaving you with a green.o file.

22. Separate compilation steps • Three different tasks arerequired to produce the executable program: • Compile green.o: cc -c green.c • Compile blue.o: cc -c blue.c • Link the parts together: cc green.o blue.o • No two files can have functions with the same name (or the compiler will get confused.) • With global variables no two files may define the same global variables. • Only one file may define a global variable. Declare it in your .h as follows: extern int globalvar; • To use functions from another file, make a .h file with the function prototypes, and use #include to include those .h files within your .c files. • At least one file must have a main() function.

23. MAKEFILE PROCESS MAKE FILE 1 SLIST FILE 2 . DEVELOPMENT . TURNOVER MANUFACTURING CVS ARCHIVES SOURCE FILES SCHEDULES SLIST INFO SOFTWARE MANUFACTURING SYSTEM MASTER SLIST REPORTS SYSTEM Software manufacturing system

24. Development of the release plan LIBRARIES PROCESSES FUNCTIONS LIBRARIES EXD IND R1 R2 R3 FUNCTIONS R1 R2 R3 --- x --- X --- X --- X --- X PROCESS EXD IND R1 R2 R3 ------------ ---- --- -- ------------ ---- --- -- -- ------------ ---- --- -- -- ------------ ---- --- -- -- ------------ ---- --- -- -- ------------ ---- --- -- -- ALL OF THIS DONE WITH THE SYSTEM GLOSSARY REQUIREMENT DEFINE RELEASE PLAN ARCHITECTURE (SYSTEM TEST) RELEASE PLAN FUNCTIONAL RELEASE DEFINITION INTEGRATION PLAN SCHEDULE PROCESS AND LIBRARIES RELEASE PLAN DRIVES SCHEDULING, SYSTEM AND INTEGRATION TEST PLANNING (DEVELOPMENT)

26. Periodic Project Meetings . • Attendees: Project Manager, managers of users, requirements engineers, architects, developers, manufacturers and testers. • Same people, same food, same place and same time for every meeting. • Everyone has stake - no advisers or observers. • Agenda is fixed and any additions are distributed ahead of time. • Agenda is followed. • Meetings start and finish punctually. • Open time is planned- Farmers Market Culture • Project Manager makes decisions that are fully discussed and explained. These are the project’s checkup and direction setting meetings

28. The Project Workbook • See http://www.wiki.org • Structure is imposed on all documents • Control material and identify and make it available to the entire team • Use change summaries and newsletters to highlight what is new.

29. TQM- Total Quality Management • Stresses improvement rather than conformance, • Principles: • Customer value strategy - benefits of the project • Cascade MOV to every development task • Organizational system aims at eliminating complexity not people, • Continuous improvement - proactively based rather than reactively based. • Plan, do check, act • Invest in process improvements

30. ISO Quality System • ISO set up a series of standards for quality management • ISO 9001 most suited for software - model for quality assurance in design, development, production, installation and servicing • ISO 9004-1 contains guidelines for individual elements of various standards • ISO 9000 process includes third party auditor, with audits every 6 months and reregistration every 3 years - expensive • Necessary for some customers

31. On Quality • The cost of low quality ranges from dissatisfied customers to costing lives. • Premise is that the quality of a product is largely based on the Quality of the process that leads to the product. • We should strive to numerically describe quality - the other Q - Quantitative, “from response time is very fast to an average response time of < 1 second with no response taking over 3 seconds.” • What Quality is differs by audience - each (tester, end user, administrator) has their own perspective.

32. Quality Cascade • Start with MOV, decompose activities. • Define more detailed linked goals • Set metrics based on goals • Check Metrics for product and process • Create action items for problems • Invest in problem solution activities • Manage Changes

33. Quality Technology • TQM, Total Quality Management, emphasizes the eclectic view, the pursuit of excellence in everything • SQA - sees to it that the work is done the way it should be done • CMMI improves the development process Project wheel of existence: Plan, Do, Check, Act

34. “I know it when I see it” • Hard to measure; easy to recognize and there is agreement based on inter-rater reliability) • IEEE defines it as “the degree to which a system, computation or process meets customer or user needs and expectations” • Quality in the eyes of beholder • End User: degree to which requirements are met, correctness, reliability, usability, performance, training, documentation • Customer: factors relating to the cost, schedule, structure maintainability, testability, portability, economic benefit • System Administrator: Ease of installation, tuning, upgrading, customization, understanding

35. ISO 9126 • Another attempt to define Quality characteristics and subcharacteristics • Addresses product not process • Only subcharacteristics visible to user • Provides metrics for each subcharacteristic • The current answer - develop your own based on these and relevant to your needs. Remember that quality processes that cannot be measured cannot be controlled

36. ISO 9126 Characteristics • Functionality (suitability, security) • Reliability (fault tolerance) • Usability (understandability) • Efficiency (resource use) • Maintainability (changeability) • Portability (replaceability)

37. Garvin’s 5 quality perspectives • Transcendent, innate excellence, obvious, thoughtful. (ICED-T) • User based, fitness for use, addresses needs (acceptance test) • Product based quality (ISO 9126) • Manufacturing based - conformance to specs • Value based (MOV)- show me the money

38. Problem reporting and corrective action Tools, techniques and methodologies Code control Media control Supplier control Records collection, maintenance and retention Training Risk management IEEE 730 • Purpose • Reference documents • Management • Documentation • Standards, practices, conventions and metrics • Reviews and audits • Test

39. CMM and others • CMM - been there done that • BOOTSTRAP - separate maturity rating for each of its practices • SPICE (ISO/IEC 15504) - international initiative Software Process Improvement and Capability dEtermination

40. Approaches to Quality