Teams_Tools2

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:

specialization

each member of the team carries out only those tasks for which he or she has been trained.

hierarchy

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

Examples:

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

Programming-in-the-small

coding a single module

Programming-in-the-large

software development involving several modules

includes architectural design and integration

Programming-in-the-many

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.

Revisions

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.

Variations

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.

	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.

	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.

	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"

	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

	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

	work on the detailed design and the coding under the direction of the chief programmer
	hand their source code to the secretary

	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;

	He is what is now called a superprogrammer
	A superb manager and leader

	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

	in charge of the technical aspects of the team's activities
	participates in all code reviews - responsible for all aspects of the code

	responsible for all non-technical managerial decisions
	appraisal of team members

	Each team leader reports to the project leader
	Team members report to the appropriate Team leaders

	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.

	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

	Definition: Comparison of estimated future benefits against projected future costs.
	Tangibles vs. Intangibles:

	i.e., salaries, cash flow
	can be determined, for example, by accountants and software engineering consultants

	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)

	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.

	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.

	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

	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.

	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.
	Revisions

	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.

	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

	many operating systems support version control, but many do not.
	If the operating system does not, some techniques are:

	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.

	SCCS - source code control system [Rochkind, 1975]
	rcs - revision control system [Tichy, 1985]
	cvs - concurrent versions system [Loukides and Oram, 1997]