Scribd
Upload
30 views3 pages

Principles of Conventional Software Model

The document outlines 30 principles of conventional software engineering based on decades of experience in the software industry. Some key principles include making quality the top priority, giving early products to customers for feedback, evaluating design alternatives, using appropriate processes and languages for different phases, and designing for change and encapsulation to accommodate future changes. Good management, skilled people, and understanding customer priorities are also emphasized as critical success factors.

Uploaded by

csed 1819
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
30 views3 pages

Principles of Conventional Software Model

The document outlines 30 principles of conventional software engineering based on decades of experience in the software industry. Some key principles include making quality the top priority, giving early products to customers for feedback, evaluating design alternatives, using appropriate processes and languages for different phases, and designing for change and encapsulation to accommodate future changes. Good management, skilled people, and understanding customer priorities are also emphasized as critical success factors.

Uploaded by

csed 1819
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Principles of conventional Software Engineering

Description:-Based on many years of software development experience,


the software industry proposed so many principles (nearly 201 by –
Davis’s). Of which Davis’s top 30 principles are:

1) Make quality #1: Quality must be quantified and mechanisms put into
place to motivate its achievement.

2) High-quality software is possible: In order to improve the quality of the


product we need to involving the customer, select the prototyping,
simplifying design, conducting inspections, and hiring the best people.

3) Give products to customers early: No matter how hard you try to learn
user’s needs during the requirements phase, the most effective way to
determine real needs is to give users a product and let them play with it.

4) Determine the problem before writing the requirements: Whenever a


problem is raised most engineers provide a solution. Before we try to solve
a problem, be sure to explore all the alternatives and don’t be blinded by
the understandable solution.

5) Evaluate design alternatives: After the requirements are greed upon, we


must examine a variety of architectures and algorithms and choose the one
which is not used earlier.

6) Use an appropriate process model: For every project, there are so many
prototypes (process models). So select the best one that is exactly suitable
to our project.

7) Use different languages for different phases: Our industry’s main aim is
to provide simple solutions to complex problems. In order to accomplish
this goal choose different languages for different modules/phases if
required.

8) Minimize intellectual distance: We have to design the structure of a


software is as close as possible to the real-world structure.

9) Put techniques before tools: An un disciplined software engineer with a


tool becomes a dangerous, undisciplined software engineer.
10) Get it right before you make it faster: It is very easy to make a working
program run faster than it is to make a fast program work. Don’t worry
about optimization during initial coding.

11) Inspect the code: Examine the detailed design and code is a much
better way to find the errors than testing.

12) Good management is more important than good technology

13) People are the key to success: Highly skilled people with appropriate
experience, talent, and training are key. The right people with insufficient
tools, languages, and process will succeed.

14) Follow with care: Everybody is doing something but does not make it
right for you. It may be right, but you must carefully assess its applicability
to your environment.

15) Take responsibility: When a bridge collapses we ask “what did the
engineer do wrong?”. Similarly if the software fails, we ask the same. So
the fact is in every engineering discipline, the best methods can be used to
produce poor results and the most out of date methods to produce stylish
design.

16) Understand the customer’s priorities. It is possible the customer would


tolerate 90% of the functionality delivered late if they could have 10% of it
on time.

17) The more they see, the more they need. The more functionality (or
performance) you provide a user, the more functionality (or performance)
the user wants.

 18) Plan to throw one away .One of the most important critical success
factors is whether or not a product is entirely new. Such brand-new
applications, architectures, interfaces, or algorithms rarely work the first
time.

19) Design for change. The architectures, components, and specification


techniques you use must accommodate change.
20) Design without documentation is not design. I have often heard
software engineers say, “I have finished the design. All that is left is the
documentation.”

21. Use tools, but be realistic. Software tools make their users more
efficient.

22. Avoid tricks. Many programmers love to create programs with tricks
constructs that perform a function correctly, but in an obscure way. Show
the world how smart you are by avoiding tricky code.

23. Encapsulate. Information-hiding is a simple, proven concept that results


in software that is easier to test and much easier to maintain.

24. Use coupling and cohesion. Coupling and cohesion are the best ways
to measure software’s inherent maintainability and adaptability.

25. Use the McCabe complexity measure. Although there are many metrics
available to report the inherent complexity of software, none is as intuitive
and easy to use as Tom McCabe’s.

26. Don’t test your own software. Software developers should never be the
primary testers of their own software.

27. Analyze causes for errors. It is far more cost-effective to reduce the
effect of an error by preventing it than it is to find and fix it. One way to do
this is to analyze the causes of errors as they are detected.

28. Realize that software’s entropy increases. Any software system that
undergoes continuous change will grow in complexity and become more
and more disorganized.

29. People and time are not interchangeable. Measuring a project solely by
person-months makes little sense.

30) Expert excellence. Your employees will do much better if you have high
expectations for them.

You might also like