Principles of Software Development CS-300 Fall 2005 Supreeth Venkataraman

Principles of Software Development

CS-300 Fall 2005

Supreeth Venkataraman

CS-300 Fall 2005 Supreeth Venkataraman 2

Introduction

These are general guiding principles for the development of software.

These principles are extremely powerful in the real world.

These principles were not formulated in a day, but through years of experience.

These principles find applications in almost all facets of computer science.


Principle 1 – Intellectual Control

Simple problems can usually be solved directly by programming as they are easy to keep track of in one’s mind.

Think about a very complex software system like the guidance system of an aircraft.

Can such a system be coded directly?



If direct coding is used for such a system, the resulting product will most likely be wrong as the developer cannot visualize the entire system in mind.

Intellectual control is the ability to be in control of all aspects of a problem.

Intellectual control is hard because of the inherent complexity of software systems.



Loss of intellectual control leads to waste of valuable resources.

In order to gain intellectual control, what needs to be done?


Principle 2 – Divide and Conquer

To gain control of a very large and complex problem, break it up into manageable size chunks.

Solve each small problem to the best extent.

Combine the small solutions to make the final global solution.

What can go wrong here?



Independent Parts• Each of the decomposed parts must be able

to be solvable by itself without having to worry about the other parts.

• Thus each part must be self contained.



The 7 “plus or minus” 2 rule• It has been observed that humans can

achieve intellectual control when dealing with five to nine different parts.

• Thus the decomposition of the original problem should not give rise to more than 9 independent parts.

• Of course, each sub-problem can be further divided into 5 – 9 parts.



Hierarchies• Many times, the initial decomposition of a

problem will lead to sub-problems that themselves are extremely complex.

• These sub-problems have to be decomposed into smaller sub-sub-problems as well.

• In fact, all sub-problems have to be decomposed till we’re left with manageable pieces of the problem. This forms a hierarchical structure.



Original Problem

Sub-problem 1 Sub-problem 2 Sub-problem 3

Sub-problem 2-1 Sub-problem 2-2

Sub-problem 2-1-1 Sub-problem 2-1-2 Sub-problem 2-1-3



Know when to stop• It is easy to get carried away while

decomposing a system.

• Too much decomposition leads to an unmanageable amount of small problems.

• Ultimately, the entire hierarchy must be manageable.

• Determining when to stop is a hard problem!!!



The good thing about hierarchies is that they are extremely simple even though they may contain a large number of parts.

The beauty of divide and conquer is that the human mind can be made to manage an extremely complicated problem through the process of careful decomposition.


Principle 3 – Identify the “Customers” The customer is the person who talked with

the developers to make the requirements, and is the end-user of the system

It is also a good practice to think that the customer for a particular phase is the subsequent phase.

Think about the milestones we talked about. The design document is used by the coding

phase, and thus the design document must be detailed enough so that working code can be “mechanically” written from it


Principle 4 – Fuzzy into Focus

Abstraction is a good way to look at a problem at a high level.

As the development progresses, we need to start adding more details to each sub-problem.

Adding more details in a sensible way moves the project from the realm of fuzziness to a well focused detailed system.

We can also say that software development transforms an abstraction into a concrete solution.


Principle 5 – Document It!

The importance of this principle cannot be stressed enough!

It is important to maintain detailed documentation of the systems being built in order to keep track of what has been accomplished.

In other words, documentation is essential in order to attain intellectual control!



Record it or it’s lost• People have good ideas all the time.

• If these ideas are not recorded, they are lost.

• A classic example here is recording test cases during the initial phases to use on the program after coding.

• If such test cases are not recorded during development, how to determine good test cases during testing time? (Mostly we cant)



Know what you’ve assumed• Assumptions are used to limit a problem to a solvable

domain (For example, it is assumed that there will be a maximum of 100 users using the local library system)

• Documenting assumptions helps in correcting any incorrect assumptions during reviews

• It also serves as a guide to removing confusion (Why doesn’t it work for 101 users? Got it! it is assumed that there are only 100 users)



Traceability• This concept relates phases of the

development lifecycle.

• For example, if each test case in a test plan is labeled with a number from the requirements document, it is easy to see which requirements we are testing (especially if the test case came from the design document)

• What if we’re not able to trace back to the requirements?



A (Document) place for everything and everything in its place• How many times have we been told this while growing

up? • If there is a consensus about where

information/documents will be stored, it becomes easier to locate them in case updates are needed.

• We don’t need people putting information wherever they please.

• The documents must be easily accessible for reading/writing/appending.



Documentation Isn't a novel• “The great novels are those that are just

slightly obscure so that readers cannot exactly be sure what they mean” – Hamlet p. 41

• The documentation should be• Simple

• Unambiguous

• Non-redundant


Principle 6 – Input/Output is the essence of software

Software transforms a set of inputs into a set of outputs

All inputs and outputs must be identified early in the lifecycle

Identify valid and invalid ranges of inputs Identify boundary values of inputs Identify important combinations of inputs

and outputs


Principle 7 – Too much engineering is not a good thing

Don’t try to be too smart If it ain’t broke don’t fix it The “creeping feature creature”

• Adding “surprise” features to delight the end user

• Don’t add anything more than absolutely necessary

• “It is not good engineering to deliver a luxury car when the end user wanted a basic truck”


Principle 8 – Expect to deal with change

Change is inherent in software development Each time a defect is detected changes need

to be made to the software Learning to deal with change (change

management) is extremely important The most unpleasant change is when

customers change their minds at a late stage of development

Don’t slack off on making the change required.


Principle 9 – Reuse past work

The beauty of software development is that components can be reused. For example, standard libraries and classes in most programming languages can be reused.

Past work done well is golden• One can even use components built in one

project for another.

• Never throw away well done past work


Principle 9 – Reuse past work

Create software so that reuse is possible Don’t reinvent the wheel

• If there exists a ready-made solution for your needs, don’t build it from scratch. Purchase the solution if it is really good. It will save you the trouble of developing it.

• You don’t want to (in general) develop your own operating system just because you don’t like windows do you?


Principle 10 –Take responsibility

If a mistake has been made, don’t brush it under the carpet and hope that the problem will go away.

Take responsibility and deal with the difficulties “Flaws in all software have their source in the

development process. To have seen the process going wrong and done nothing is irresponsible”

Documents

Principles of Software Development CS-300 Fall 2005 Supreeth Venkataraman