A case study on Best Practices of Software Engineering

Software Engineering vs. Cleaning of the Basement in the Dark:

Developing software always reminds of trying to clean up the basement in the dark. We crash around, running into each other and into unidentified obstacles, grunting and swearing. Each one of us encounter something and decide to move it; as soon as we set it down someone else finds it and moves it elsewhere. Adding more people to a process like this probably won’t help.

Suppose somebody tells us what we need is better tools. Should we hand out Swiss Army Knives to everybody? Well, they’re irrelevant or worse. A bulldozer would be great for cleaning up, but we wouldn’t give everybody bulldozers either, as long as we are operating in the dark.

Hence, we need a theory of how to develop software that would be like turning on the lights. But the light switch for this software development basement is probably upstairs somewhere; the kind of theory we need won’t be found while we are trying to get releases out.

“Best Practices” vs. the various steps followed to clean “the Basement in the Dark”

So, if we were trying to clean up the basement in the dark, we should organize the team before we go down the stairs. We should form a chain across the basement and hold hands, and pass things to the left as we found them, and so on. In other words, organization and cooperation are more valuable to this kind of process than individual productivity.

Best Practices followed in Software Engineering Development:

Think first. This is the idea behind all successful software engineering methods

Create a Plan. Create an estimate for all the phases.

Proceed as systematically as possible, without making that an end in itself.

Write designs down; write clearly; don’t write too much.

Discover, document, and keep improving a systematic collection of development practices.

Build tools, use them, keep improving them.

Describe the architecture. Find organizing concepts and abstractions that describe what we are building and guide us in design choices.

Do an intermediate check by using a Bi-Directional Traceability Matrix.

Check everything – call for Inspection/Reviews. Use the whole team to review plans, designs, and source programs.

Inspection:

Code Review:

Always use a Formal Change Request Process

Follow a formal Defect Management Process

Blogger : Prasad