OT96 Workshop: C++ in Large Projects

This is a quick dump of the posters from the workshop. Enjoy!

How to enforce maintainability

Select coding standards
Organise code reviews
Organise design reviews
Assicn the role of a 'class librarian
Keep design up to date
Use a methodology (e.g. OMT)
Move people around in the team
Introduce a common architecture

Maintainability learning points

You definitely need experience
It's worth doing brainstorming
From a maintainability point of view, there are not many differences between oo and 'procedural'
Team Selection Learning Points
Need focus from understanding the business constraints
Have to wrok with less skilled people than we would like
Easier if you've done it before!
Define roles independently of people first.

Issues to be resolved

Need more accurate profiles
Is it possible to build a non-real test environment
Who are the key individual users
Do any of the team already know/like/hate each other

Assigning Roles

Iterative process...

Identified the tasks
Created outline plan ("perfect people")
Mapped people to the task ("imperfect" ...!)
Adapted tasks and plan to fit

OO allows...

Made it easier to breakdown more and smaller work tasks to run in parallel

However...

Potentially hides efforts behind simple interfaces

Organisation...

All the good old stuff still applies!

Assigning people to teams

OO makes no difference
Personality counts more than oo skill for team leaders (but they must have both).
Never enough information about people at start

Avoiding inter-dependencies

Well defined interfaces based on abstract classes
Implement stubs for testing
Behaviour of a service should not depend on that of its client.

Mission 1

Identify roles based on the tasks not the staff available
Do not attempt to pre-define roles too rigidly

Mission 2

Who will we separate domains and avoid inter-domain dependencies?
Establish inter-domain interfaces
Follow an iterative approach - each iteration providing more functionality
Keep time between iterations short, especially the early iterations.

Mission 1

Dividing the project into work packages and development by iterations will help allocation of resources.
OO helps in dividing the project into sub-projects.
Milestones for delivering work packages should show progress to help keep the project on schedule.

Mission 2

(Configuration Management)
Encapsulation will limit the number of conflicts
Conflict will still occur
The code in which the conflicts will occur can be identified in advance (so effort can be concentrated there).

Personal Management

1. Define a process before assigning roles and plan
2. People influence the process
3. Training must be incorporated in the process: training on the job and training for testing!
4. Define tools to support the process. Tools require training.

Testing

OO testing relies more on reasoning
OO clear contracts implies more incremental testing
OO Today's customer requirements are still functional oriented.
OO Customer and designer will use same business model!

General

1. Best technical, communcation and experience in 'core' team
- One leader of this team, who is senior technical person overall
- Experience of failure better than no experience at all.
2. More people does not imply better.
3. Use complementary skill sets. Also manage risk of personality clash.
4. Contain dependencies by putting them all in one team.
Testing is best distributed!

OO-Specific

1. Training is vital, since new technology
2. OO helps us to separate interfaces with confidence.
Surprising how few OO-specific factors...

Testing

RISK .... Mitigation

Test team distributed but ?

Communication problems but Testers also work as a 'virtual team'

Consistence of testing but Use central strategy developed by one person

Consistency of code but Inter, and intra, reviews

OO encourages...

Late changes and ambiguous interfaces but Firming interfaces earliest priority of the 'core' team.

Last updated: 11 April 1996 Apr 96-4