Lecture 10 Implementation and Configuration Management

CS 540 – Quantitative Software Engineering

SWEBOK Knowledge Areas: Software Construction Fundamentals

Measuring Complexity: use to predict effort and time to build, maintainability, etc.• Type of Application (Real-time, online transaction, report

generation, etc.)

• Nature of computations

• Components size (in function points)

• Cohesion

• Coupling (external references)

• Testability

• Program control Flow

Measuring Complexity

Measuring Complexity: Wideband Delphi ratings

• Problem Domain

• Architectural complexity

• Data structure design

• Code Design

McCabe’s Cyclomatic Complexity

Based on a directed graph showing control flow of program thereby showing the number of independent paths in the program

Cyclomatic Complexity, CV= e - n + p + 1 where:• e = # of edges• n = # of nodes• p = # of connected modules or code segments (1 for

main program and 1 for each procedure) ’10’ is the upper limit of McCabe complexity

McCabe use

Great for testing because it uncovers all linearly independent paths

Does not add more complexity to nested loops and in general does not consider context

Unlike Halstead does take into account control flow complexity, but not data flow

Useful for individual developer feedback and during maintenance

Halstead -”software science”

Stresses syntactic units rather than LOC Model components:

• Operators - actions: +, -, *, /, if-then-else,…• Operands - data: variables and constants• 4 basic entities (used in a bunch of equations)

» n1 - # of different operators

» n2 - # of different operands

» N1 - total occurrences of operators

» N2 - total occurrences of operands

• Length of Program for Halstead: N = N1 + N2

Halstead use

Simple to calculate, no in-depth examination of structure Measure of overall quality of modules Helpful to program designers and to maintainers Substantial literature Requires coding of modules Automatic feedback to program developers Does not account for complexity of interfaces

SWEBOK Knowledge Areas: Software Construction Fundamentals

Minimizing Complexity Anticipating Change

• Generalize,

Construction for Verification• Code reviews, unit test, automated testing, restrict language

features

Standards in Construction• Communication methods (document format), tools (flow

notations), platform calls

SWEBOK Knowledge Areas: Managing Construction

Construction Models (process models like waterfall, Extreme programming, prototyping, Agile, etc.)

Construction Planning Construction Measurement

• Code developed, modified, reused

• Code inspections completed

• Unit testing fault and fix rates

SWEBOK Knowledge Areas: Practical Considerations

Construction Design Construction Languages: configuration

languages, toolkit languages, programming languages

Coding: control structures, error handling, security, organization, documentation

Unit Testing Reuse

Kruchten’s “4 + 1”Model for Developing a Software Architecture

+ 1 Business Scenario

+ 1 BusinessScenario

+ 1 Business Scenario

View 1

Logical--

End Users

View 2

Process--

System Integrators

View 3

Physical--

Engineers

View 4

Development--

Programmers& Manufacturers

Conceptual Transition

FROM

Specify

Design

Code

Test

TO

Link

Compile

Test

Building Blocks

Components Modules Interfaces Configurations Source Code Intermediate Language Object code files Executables

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

What Is modularization?

A “module” is considered programmer responsibility 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

Usual Modularization

This is a modularization in the sense meant by allproponents of modular programming. The system isdivided into a number of modules with well-definedinterfaces; each one is small enough and simple enoughto be thoroughly understood and well programmed.Experiments on a small scale indicate that this isapproximately the decomposition which would beproposed by most programmers for the task specified.

Op. Cit. Parnas

Brooks Chapter 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

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

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

Workflow of CR (MR)

Investigate CR

Prepare & sched work package

Implement change

Updated configuration items

Prioritized work package

Change approved

Change Request

rejected

Notify CR owner

Request info fromCR owner

Deferred

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.

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

The Make command http://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.

A simple compilation

Compiling with several large files

cc green.c blue.c

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.

Separate compilation steps

Three different tasks are required to produce the executable program: 1. Compile green.o: cc -c green.c 2. Compile blue.o: cc -c blue.c 3. 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.

Software manufacturing system

TURNOVERDEVELOPMENT

MANUFACTURING

MASTER SLIST

SOFTWARE MANUFACTURING

SYSTEM

REPORTSSYSTEM

CVSARCHIVESSLIST

INFO

SOURCEFILES

SCHEDULES

MAKE

MAKEFILE

FILE 1

FILE 2

. .

PROCESS

SLIST

Development of the release planLIBRARIES

PROCESSES

FUNCTIONS

REQUIREMENT

ARCHITECTUREDEFINERELEASE PLAN

FUNCTIONS R1 R2 R3--- x--- X--- X--- X--- X

FUNCTIONALRELEASEDEFINITION

INTEGRATION PLAN

LIBRARIES EXD IND R1 R2 R3

PROCESS EXD IND R1 R2 R3------------ ---- --- -- ------------ ---- --- -- -------------- ---- --- -- -------------- ---- --- -- -------------- ---- --- -- -------------- ---- --- -- --

SCHEDULE PROCESS AND LIBRARIES (DEVELOPMENT)

(SYSTEM TEST)

RELEASE PLAN

ALL OF THIS DONE WITH THE SYSTEM GLOSSARY

RELEASE PLAN DRIVES SCHEDULING, SYSTEM AND INTEGRATION TEST PLANNING

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

The Project Workbook

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.

Software Configuration Management: Tools

the SCM Library the software change request (SCR) and approval procedures code (and related work products) and change management tasks reporting software configuration status and collecting SCM

measurements software configuration auditing (version control) managing and tracking software documentation performing software builds managing and tracking software releases and their delivery

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

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

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.

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

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

“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

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

ISO 9126 Characteristics

Functionality (suitability, security) Reliability (fault tolerance) Usability (understandability) Efficiency (resource use) Maintainability (changeability) Portability (replaceability)

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

IEEE 730

Purpose Reference documents Management Documentation Standards, practices,

conventions and metrics Reviews and audits Test

Problem reporting and corrective action

Tools, techniques and methodologies

Code control Media control Supplier control Records collection,

maintenance and retention Training Risk management

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 dEetermination

Approaches to Quality

Conform Improve

Product ISO 9126 Best Practices

Process ISO 9001 CMM