Larry Bernstein

Regression testing cuts test intervals in half.

It takes three times the effort to find and fix bugs in system test than when done by the developer. It takes ten times the effort to find and fix bugs in the field than when done in system test. Therefore, insist on unit tests by the developer.

Good customer relations double productivity.

Prototyping will reduce development time & cost by 40%.

You must be a world-class customer before you can be a world-class supplier.

Don’t automate an undisciplined workflow. The computer won’t solve what the customer’s management can’t.

Only 40-60% of the system requirements are known at the state of the project. The rest emerge from system use. Barry Boehm coined the phrase ‘emergent requirements' to describe them.

In dealing with customers, you must understand that there are things they want and things they need. A successful project manager distills the needs from the wants and satisfies them while delivering the system at reasonable cost.

The system engineer comes up with a solution; the developer comes up with the solution.

Software manufacturing is a systematic approach to system building, deliverable documentation production, configuration identification, change control, and packaging for delivery.

The project is in serious trouble when the project manager says:
1. The load is twice what we expected and we need a bigger machine.
2. The customer is late with the requirements.
3. Yes we have schedules and we must have specific development intervals. No, we don’t have a definition of what the system is to do.
4. Our economics are somewhat worse than we projected.
5. I’ve been in software for ten years. I manage it without really understanding it.

There are four kinds of problems that arise when one fails to do adequate requirements analysis:
1. Top-down design is impossible
2. Testing is impossible
3. The user is frozen out
4. Management is not in control

Trustworthy means that a software product or component is safe, reliable and secure.
Checklist for Software Design for Reliability
1. Simplify
2. Use fault tolerant libraries and transfers for recovery.
3. Rejuvenate the executing system from time-to-time.
4. Hire good people and keep them!
5. Limit programming features.
6. Limit module size initialize memory.
7. Check design stability.
8. Bound the execution domain.
9. Engineer to performance budgets.
10. Reduce algorithm complexity.
11. Factor and Re-factor.
12. Improve maintainability [with 20% of staff].

If it ain’t broke, fix it anyway. You must invest least 20% of your maintenance budget in refreshing your architecture to prevent good software from becoming spaghetti code.

Software architecture is the body of instructions, written in a specific coding language, which controls the structure and interactions of the system modules. The properties of capacity, throughput, consistency and module compatibility are fixed at the architectural level.
The processing architecture is code that governs how the processing modules work together to do the system functions. The communication architecture is code that governs the interactions of the processing modules with the data and with other systems. The data architecture is code that controls how the data files are structured, filled with data and accessed. Once the architecture is established, functions may be assigned to processing modules and the system may be built. Processing modules can vary greatly in size, scope, depending on the function each performs, and the same module may differ across installations. In every case, however, the processing architecture, communication architecture and data architecture constitute the software architecture that is the system’s unique and unchanging “fingerprint.” Therefore, when systems share a common architecture, they are the same, regardless of superficial differences in various installations.
When several sites use software systems with a common architecture, they are considered to be using the same software system even though they may do somewhat different things. No two iterations of a software system are exactly the same, despite their shared architecture. When a system is installed at two or more sites, localization is always required. Tables are populated with data to configure the software to meet the needs of specific customer sites. The customer may have special needs that require more than minor table adjustments. Customization of some modules may be required. New modules may be added.
Alternatively, two systems with differing architectures can perform the same function in alternative ways. These would be different systems. Function and output do not define a system. Only its architecture can describe and identify a system.