Teams and the Tools of Their Trade

Team Organization
Most products are too large for one person to produce within the given time constraints.
Product must be assigned to a team.
Assigning more people does not necessarily reduce the amount of time required to do some tasks.
Some tasks can be shared; others must be done individually.
It is possible to share implementation tasks between members but the team members have to interact in a meaningful and effective way.

Team organization is a managerial issue; management must organize the programming teams so that each team is highly productive.
As members are added to a team, communication paths multiply.
"Brooks's Law"
after Fred Brooks, who observed it while managing the development of OS/360-1975)
Principle that adding personnel to a late software project makes it even later.
Because teams are most heavily used during the implementation phase, the problems of team organization are most acutely felt during implementation. Two extreme approaches to programming team organization:
Democratic Teams
Chief Programmer Teams
There are ways to incorporate the best features of the two extremes.

Democratic Team Approach
First described by Weinberg in 1971
Basic concept is "egoless programming"
If programmer sees program as an extension of his or her own ego, programmer will be less apt to find all the faults in his or her own code.
With "egoless programming" every programmer must encourage the finding of faults in his own code.
A group of up to 10 egoless programmers constitutes a democratic team.
What is important is team identity and mutual respect.
Analysis of the Democratic Team Approach
Major advantage = positive attitude toward the finding of faults.
Weinberg feels that egoless teams spring up spontaneously and cannot be imposed from outside.
Enormously productive.
Work best when the problem is difficult
should function well in a research environment
works well in an industrial setting when there is a hard problem to solve.


Classical Chief Programmer Team Approach
Multiplicity of Communication channels
With a 6-person team there are 15 two-person communication channels
The total number of 2, 3, 4, 5, and 6 person groups is 57.
For this reason, a 6 person team is unlikely to perform 36 person months of work in 6 months.
see Brooks's "The Mythical Man-Month"
Structure of classical chief programmer team:
6 programmers with 5 lines of communication:

Two key aspects of a chief programming team:
each member of the team carries out only those tasks for which he or she has been trained.
chief programmer directs the actions of all the other members of the team and is responsible for every aspect of the operation
Chief Programming team concept formalized by Mills (1972)
Chief Programmer
Both a successful manager and a highly skilled programmer who does the architectural design and any critical or complex sections of the code.
handles all interfacing issues
Back-Up Programmer
must be as competent as the chief programmer in every respect and must know as much about the project as the chief programmer.
does black-box test case planning.
work on the detailed design and the coding under the direction of the chief programmer
Programming Secretary (sometimes called librarian)
responsible for maintaining the project production library, the documentation of the project
includes source code listings, JCL, and test data.
responsible for conversion of source code to machine readable form, compilation, linking, loading, execution, and running test cases. One to three programmers
work on the detailed design and the coding under the direction of the chief programmer
hand their source code to the secretary
The New York Times Project
1971 - IBM first used the chief programmer team concept to automate the clipping file of the New York Times
Principal programmers averaged 1 detected fault and 10,000 LOC per person-year.
Possible Reasons:
A prestige project for IBM
first real trial for PL/I
strong technical backup;
PL/I compiler writers
JCL experts
Expertise of the chief programmer - F. Terry Baker
He is what is now called a superprogrammer
A superb manager and leader
If he chief programmer is competent, then the chief programmer team organization works well. Impracticality of the Classical Chief Programmer Team Approach
Chances of finding a chief programmer are small
qualities needed to be a highly skilled programmer are different from those needed to be a successful manager
backup programmer must have the same qualities and are just as rare
must also take a back seat to the chief programmer
programming secretary must be a programmer who does not mind lots of paperwork

Beyond Chief Programmer and Democratic Teams
Neither of the aforementioned techniques seems to be able to handle projects that require 20 or even 120 programmers for the implementation phase
Team organization is needed that uses the strengths of both democratic teams and chief programmer teams.
Modern Programming Teams:
Chief programmer is replaced by two individuals:
Team Leader
in charge of the technical aspects of the team's activities
participates in all code reviews - responsible for all aspects of the code
Team Manager
responsible for all non-technical managerial decisions
appraisal of team members
Problems can arise unless areas of responsibility are clearly delineated
Higher management should draw up a policy regarding areas that both the team manager and the team leader consider to be their joint responsibility.
Larger Projects:
Project Leader and several Team Leaders
Each team leader reports to the project leader
Team members report to the appropriate Team leaders
To draw of the best features of both the Democratic and Chief Programmer Teams, decentralize the decision-making process where appropriate. Conclusion: Optimal team organization depends on the product to be built, previous experiences with team structures, and management outlook.

Synchronize-and Stabilize-Teams
Used by Microsoft
Project example: Windows 95  = 11 million lines of code built by over 200 programmers and testers.
Project broken down into 3 to 4 sequential builds Each build is constructed by a number of small parallel teams led by a program manager. Team consists of 3 to 8 developers and 3 to 8 testers who work one-on-one. during the day team members have freedom to design and implement their portions of the task as they wish Synchronization step at end of day - members are then accountable Strength of structure is that creativity is encouraged and all are working toward a common goal Rules:
Programmers must adhere strictly to the time laid down to enter their code into the product database for that day's synchronization.
If a developer's code prevents the product from being compiled for that day's synchronization, the problem must be fixed immediately so the rest of the team can test and debug the day's work.
Much of the success of the team structure might be attributed to the fact that Microsoft, Inc. is an organization consisting of a highly talented set of managers and software developers with an evolved group identity.

Stepwise Refinement
Tools needed by software engineers:
Analytical Tools
stepwise refinement
cost-benefit analysis
CASE Tools Stepwise Refinement:
Term coined by Wirth (1971) (Wirth applied the technique to pseudocode)
General Technique that can be used in every phase of software development
Allows developer to prioritize problems within each phase
postpone decisions on details until as late as possible in order to concentrate on the important issues.
Important because of Miller's Law:
At any one time, a human being can concentrate on at most 7 + or - 2 chunks of information.
When using stepwise refinement, it is necessary to desk check each successive refinement before proceeding to the next.

Cost-Benefit Analysis
Definition: Comparison of estimated future benefits against projected future costs.
Tangibles vs. Intangibles:
Experts can easily estimate tangibles:
i.e., salaries, cash flow
can be determined, for example, by accountants and software engineering consultants
Intangible require assumptions:
i.e., customer adjustment
Cost-benefit analysis is a fundamental technique in deciding whether a client should computerize his or her business, and if so, in what way.

Software Metrics
There are five essential, fundamental, metrics that a software organization should measure:
Size (in LOC - lines of code - or some other measurement)
Cost (in dollars)
Duration (in months)
Effort (in person-months)
Quality (number of faults detected)
Wide variety of other metrics:
Number of Defects (faults) per 1000 lines of code is a measure of software quality.
Mean time between failures is a measure of reliability in operations mode.
an example of product metrics
Staff turnover Efficiency of fault detection during development
an example of process metrics
Many metrics are specific to a given phase There is a cost involved in gathering the data needed to compute the values of metrics. Other than the five fundamental metrics, more detailed data gathering and analysis should be performed only toward a specific objective.

CASE Tools
CASE -acronym stands for computer-aided (or computer-assisted) software engineering
involves all aspects of computer support for software engineering
Taxonomy of Case
Software Tool - product that assists in a single aspect of software production
e.g. graphical representation of flowcharts
CASE Workbench - collection of tools that support one or two activities
Note: An activity is a collection of related tasks, NOT the same as a phase of the life-cycle.
Activities may even span across phases.
CASE  Environment - supports entire software process (or a large portion) Advantage of CASE Tools:
Simplify version control
Provide on-line documentation
easier to use
usually more accurate
Assist in communication among team members
e-mail: provides a record of decisions (store in single mailbox)
Simplify programming tasks Simplify document creation Terminology and Example Tools
Front-end or UpperCase Tools
Tools for requirements, specification, planning, design stages
Back-end or LowerCASE Tools
Tools for implementation, integration, and maintenance
Data dictionary: computerized list of all data defined within the product
Consistency Checker - tool for checking that data items of specification appear in the design
Report Generator
Screen Generator
Tools combining all four of the above support rapid prototyping
Programming Tools
Structure Editor - text editor with syntax checking editor is specific to implementation language
Some structure editors support online interface checking
Some structure editors include an operating system front end.
In UNIX, use the MAKE command or invoke shell script.
source Level Debugger - produces Trace output
UNIX - dbx
Effective Programming Workbench:
FLOW (1980) incorporated all these features.
More Definitions
coding a single module
software development involving several modules
includes architectural design and integration
software development by a team
involves both programming-in-the-small and programming-in-the-large


Software Versions
When a product is maintained, there will be at least two versions of the product, the new version and the old version. There will also be two or more versions of each of the component modules that have been changed.
If a product is in operations mode and a fault is found in a module and fixed, then the new version of the module and the product is the revision.
It is necessary to retain a copy of every revision of each module.
Issues arise not just during the maintenance phase but from the implementation phase onwards.
There must be some sort of control to ensure that every member of the development team always knows which version is the current version of the given module.
Unlike revisions, each of which is specifically written to replace its predecessor, variations are designed to coexist.
Different variations of many modules may have to be produced for each operating system/hardware combination.


Configuration Control
Code for every module exists in three forms:
source code (i.e. high level language)
object code (produced by compiling the source code)
executable load image - combination of object code and run time routines
Version control tools:
many operating systems support version control, but many do not.
If the operating system does not, some techniques are:
Have each fine name consist of two pieces, the name itself and a revision number
ex. filename/1 and filename/2
With regard to multiple variations, have a basic file name followed by a variation name
ex. printerDriver(inkJet) printerDriver(laser)
For multiple revisions of each variation:
ex. printerDriver(laser)/12 printerDriver(laser)/13
Once a version control tool is in place, a detailed record, or derivation of every version of the product must be kept. Some mechanism is needed that allows only one user at a time to change a module.
The maintenance manager must set up a baseline, a configuration (set of versions) of all the modules in the product.
When trying to find a fault, a maintenance programmer puts copies of any needed modules into his or her own private workspace.
The baseline version is left untouched.
Programmer freezes the current version of the module - no one else can change it.
After the changes have been tested, the baseline is modified, and the new version becomes the baseline.
Configuration control during product development:
As soon as a module has been passed by the SQA group, it is ready to be integrated into the product. From then on it should be subject to the same configuration control procedures as those of the maintenance phase.
The three major UNIX version control tools are:
SCCS - source code control system [Rochkind, 1975]
rcs - revision control system [Tichy, 1985]
cvs - concurrent versions system [Loukides and Oram, 1997]
Microsoft Source Safe is a configuration control tool for personal computers.

Build Tools
Build tool - a tool that assists in selecting the correct version of each object-code module to be linked to form a specific version of the product.
UNIX - Makefile and make command.
If the date and time stamp on the source file is later than that on the object file, then make calls the appropriate compiler or assembler to create a version of the object file that will correspond to the current version of the source file.
make checks whether the load image incorporates the current version of every module.