good oo heuristics

: " Heuristics Summary

The following heuristics are taken from Object-Oriented Design Heuristics by
Arthur J. Riel. This book is available from Addison-Wesley May 1996 (ISBN
#0-201-63385-X). The chapter and number designations are derived from the
text.

Chapter 2
Classes and Objects: The Building Blocks of the Object-Oriented Paradigm
Heuristic #2.1
All data should be hidden within its class.

Heuristic #2.2
Users of a class must be dependent on its public interface, but a class should
not be dependent on its users.

Heuristic #2.3
Minimize the number of messages in the protocol of a class.

Heuristic #2.4
Implement a minimal public interface which all classes understand (e.g.
operations such as copy (deep versus shallow), equality testing, pretty
printing, parsing from a ASCII description, etc.).

Heuristic #2.5
Do not put implementation details such as common-code private functions into
the public interface of a class.

Heuristic #2.6
Do not clutter the public interface of a class with things that users of that
class are not able to use or are not interested in using..

Heuristic #2.7
Classes should only exhibit nil or export coupling with other classes, i.e. a
class should only use operations in the public interface of another class or
have nothing to do with that class.

Heuristic #2.8
A class should capture one and only one key abstraction.

Heuristic #2.9
Keep related data and behavior in one place.

Heuristic #2.10
Spin off non-related information into another class (i.e. non-communicating
behavior).

Heuristic #2.11
Be sure the abstraction that you model are classes and not "

outsource software project

here is a summary of ideas for managing an outsource project.

In McConnell's Rapid Development he states that managing an outsource project is more difficult than an inhouse development because you have reduced control

an idea from Keith Braithwaite is that if you increase the visibility you have of the code by handing over code at the end of the day you also increase the control you have over the project.

list of stuff to consider

have you agreed a coding standard with the vendor. this should include metrics on code issues and test coverage

agree a list of tools to be used.. eg JUnit

have you defined the scope of the project and agreed a set of deliverables. Also identify if the deliverables are internal or the responsibiity of the outsource

agree a schedule with the vendor early in the project with regular milestones. this should be tracked rigorously and annotations made for changes

ensure internal resource are allocated to the following roles and ensure the roles are well defined : Tester, Project manager, Analyst, tech lead

get regular code drops (dayly is best), inspect the code with tools, and have a daily build and smoke test.

have a regular meeting with the vendor reviewing the risk and issues log along with the schedule

agree a communication plan with the vendor

keep a project log of events and key conversations

have a plan B

define the tests with the requirements as early as possible