1. Principles of Software Development CS-300 Fall 2005 Supreeth Venkataraman

2. 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.

3. CS-300 Fall 2005 Supreeth Venkataraman 3 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?

4. CS-300 Fall 2005 Supreeth Venkataraman 4 Principle 1 – Intellectual Control 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.

5. CS-300 Fall 2005 Supreeth Venkataraman 5 Principle 1 – Intellectual Control Loss of intellectual control leads to waste of valuable resources. In order to gain intellectual control, what needs to be done?

6. CS-300 Fall 2005 Supreeth Venkataraman 6 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?

7. CS-300 Fall 2005 Supreeth Venkataraman 7 Principle 2 – Divide and Conquer 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.

8. CS-300 Fall 2005 Supreeth Venkataraman 8 Principle 2 – Divide and Conquer 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.

9. CS-300 Fall 2005 Supreeth Venkataraman 9 Principle 2 – Divide and Conquer 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.

10. CS-300 Fall 2005 Supreeth Venkataraman 10 Principle 2 – Divide and Conquer

11. CS-300 Fall 2005 Supreeth Venkataraman 11 Principle 2 – Divide and Conquer 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!!!

12. CS-300 Fall 2005 Supreeth Venkataraman 12 Principle 2 – Divide and Conquer 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.

13. CS-300 Fall 2005 Supreeth Venkataraman 13 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

14. CS-300 Fall 2005 Supreeth Venkataraman 14 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.

15. CS-300 Fall 2005 Supreeth Venkataraman 15 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!

16. CS-300 Fall 2005 Supreeth Venkataraman 16 Principle 5 – Document It! 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)

17. CS-300 Fall 2005 Supreeth Venkataraman 17 Principle 5 – Document It! 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)

18. CS-300 Fall 2005 Supreeth Venkataraman 18 Principle 5 – Document It! 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?

19. CS-300 Fall 2005 Supreeth Venkataraman 19 Principle 5 – Document It! 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.

20. CS-300 Fall 2005 Supreeth Venkataraman 20 Principle 5 – Document It! 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

21. CS-300 Fall 2005 Supreeth Venkataraman 21 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

22. CS-300 Fall 2005 Supreeth Venkataraman 22 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”

23. CS-300 Fall 2005 Supreeth Venkataraman 23 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.

24. CS-300 Fall 2005 Supreeth Venkataraman 24 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

25. CS-300 Fall 2005 Supreeth Venkataraman 25 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?

26. CS-300 Fall 2005 Supreeth Venkataraman 26 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”