1. Module Cohesion
1. examples from Operating systems : File systems -from app APIs (C and Java) down to DDs
2. Are modules logical collections of related functions
1. 7 levels of cohesion - P173
2. Module Coupling
1. How tightly integrated are the modules - are they separable
1. 5 levels of coupling - P183

The development view - UML packages

Identify the modules at different levels of abstraction

Associate the classes involved in each module

Identify the inter-dependencies - coupling and protocols

Identify the sequence of development

Identify the potential requirements for 'scaffolding'

Identify the skills needed to implement the modules

Identify the # of people needed for each part

Identify the potential for 3^rd party products - build vrs buy

Identify the 'rocket science'.

Identify the tools - development language, IDEs etc for each module

Identify the important data flows between the modules

Identify the frequently used critical paths -> concentrate on these

Identify potential bottlenecks for development, for runtime (i.e. performance)

Identify the possible integration points along the development path - ie the builds or Testable units TUs

Need to build end to end integration paths to be sure that the system is coming together.

 

3. Implementation
1. Language choices

Suited to environment - a Cobol Shop

Suited to application - AI, Defense, GUI, Web

Old vrs new

Which OO language - C++, Smalltalk, Java - Popularity of C++

Training, tool costs, experience

Availability of 3^rd party libraries and components

2. Marketshare data for languages

Data from Gartner/Dataquest:

Of the 6 million non-mainframe programmers, it is estimated that in 1999

• 50% are engaged in Visual Basic programming in one form or another. This includes VB for applications, VB Script and VB as used in the development of Active Server pages.
• 5% do Java
• 20% do C++
• 25% do other, including PowerBuilder (and other 4GL languages), Pascal, Delphi, Smalltalk etc

Projections for 2002 are:

• 50% Visual Basic
• 20% do Java
• 15% to C++
• 15% other

The numbers from Dataquest are old (from 1997) but they do show the trends.

Language IDE tools

Workgroup Tools (C/S environments)

Internet RAD (Java)

1. Forth Generation Languages

1. binary machine code - 1940
2. assemblers - symbolic notation - 1950
3. high level languages - 1960
4. Focus, Natural, Forte, PowerBuilder, DB2 other Sybase, Informix - Forms based DB IDEs,

1. Good Programming Practice

Programming styles

A Coding Convention for C++ Code

http://www.cs.rice.edu/~dwallach/CPlusPlusStyle.html

C Coding Guidelines

http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/kayvon/www/coding.html


Recommended C Style and Coding Standards - Barnes and Noble

 

code layout

Meaningful names - Hungarian notation

Comments -> JavaDoc

Module Reuse

2. Module testing

1. non execution based
2. execution-based testing

Testing to spec

Function testing - input/output testing - api testing

exhaustive testing is not feasible - combinatorial explosion

Testing to code

Follow each code branch - also not feasible

Boundary value analysis

At the edges(low, high), in the middle. - Equivalence classes

At the boundary and near the boundaries

Functional testing

Each function in the module tested - higher level modules calling lower level modules

Glass-box testing -look inside the code

• complexity metrics - test the modules that you think are risky - lines of code - other measures seem to yield about the same measure.
• structural testing - Code coverage

Walk through and Inspections

Clean room

Testing objects are harder - or rather they break some of the rules

Management issues with testing

How much, how often, how long - looking for the pattern in find, fix rates

When to rewrite rather than debug or fix

Testing - Chapter 5

Verification - Are we building the product right ?

Validation - are we building the right product ?

Is the software good enough ?

Unit testing

Function Verification testing

System testing

Performance testing

Software Quality Assurance SQA - Who does the testing - development or an autonomous group

Managerial independence - ship the product on time vrs Ship a quality product

Ratio of 1-1 to 2-1 development to testing staff

Allocation of time and people in at the right stage of development.

Non-execution based testing - walk through, inspections - formal steps - well !

Bug tracking, Feature reviews, Arch. Reviews, triage meetings

Code reviews

Early detection - huge benefits

Modular design can help in developing the testing required.

Metrics for testing

Fault density - per kloc ? fault detection rate, fault detection efficiency - # of test cases complete

Insight into capacity of the team, of the institution, of the individual

Execution based testing

Terminology "faults" vrs "bugs"

You can only test so much -> testing can not prove the absence of bugs

API testing, UI testing, usability tests, Stability testing, functional testing (external)

How do you create the right environment to support the realistic testing of the product ?

Simulator, load balancing tools -> flight systems or missile systems etc

Cut down the risks

P144 ->

Utility - are the users needs met, cost effective, functional, easy

Reliability - Meantime between failures, mean time to repair

Frequency and criticality of failures

Robustness - holds up under a range of different inputs - how well does it tolerate boundary conditions

Performance - Scalability, throughput

real-time -> hard real time vrs soft real time.

Correctness -> is the output correct

Garbage in Garbage out > bad specs give bad programs

Correctness is not sufficient -> the software may be wrong in parts but it may be good enough

e.g. of the good compiler with the spurious benign error messages

Correctness proofs - P152

Verification, Formal methods - ensuring a deep understanding vrs a practical tool

Are programmers trained in the mathematics ?

"A successful test is one that finds faults" goes against the grain for a programmer to do the testing

Test results must be recorded - PAR system, formal bug tracking systems are needed

Regression testing, systematic testing systems and organizations, test plans and automated scripts

Testing distributed software is hard !Timing problems, multi threading, multi processing, multi computer,

Heisenberg principle

History, event logs