Principles of Conventional Software Engineering
We know that there are many explanations and descriptions of engineering software “the old way”. After many years of experience regarding software development, the software industry has learned and understood many lessons and formulated or created many principles. Some of these principles are given below :
- Create or Make Quality –
Quality of software must be measured or quantified and mechanisms put into place to motivate towards achieving the goal.
- Large or high-quality software is possible –
There are several techniques that have been given a practical explanation to raise and increase and quality includes involving customer, prototyping, simplifying design, conducting inspections, and hiring good and best people.
- Give end-products to Customers early –
It doesn’t matter how hard we try to learn and know about needs of users during requirements stage, most important and effective to determine and identify their real and realistic needs is to give product to users and let them play with it.
- Determine problem or issue before writing and needs or requirements –
When engineers usually face with what they believe is a problem, they rush towards offering a solution. But we should keep in mind that before we try to solve any problem, be sure to explore all alternatives and just don’t get blinded by obvious solution.
- Evaluate all Design Alternatives –
When requirements or needs are agreed upon, we must examine and understand various architecture and algorithms. We usually don’t want to use “architecture” generally due to its usage in requirements specification.
- Use an appropriate and correct process model –
Each and every project must select an appropriate process that makes most sense for that project generally on basis of corporate culture, willingness to take risks, application area, volatility of requirements, and extent to which all requirements and needs are understood in a good manner.
- Use different languages for various phases –
Our industry generally gives simple solutions to large complex problems. Due to his, many declare that best development method is only one that makes use of notation throughout life cycle.
- Minimize or reduce intellectual distance –
The structure of software must be very close enough to a real-world structure to minimize intellectual distance.
- Before tools, put Techniques –
An undisciplined software engineer with a tool becomes very dangerous and harmful.
- Get it right just before we make it very faster –
It is very easy and simple to make a program that’s being working run very faster than it is to simply make a program work fast.
- Inspect Code –
Assessing or inspecting design with its details and code is most and better way of identifying errors other than testing.
- Rather than Good technology, Good management is more important –
Good management simply motivates other people also to do their work at best, but there are no universal “right” styles for management.
- Key to success is “PEOPLE” –
People with high and many skills, experience, talent, and training are key to success.
- Follow with Care and in a proper manner –
just because everyone is doing something doesn’t mean that it is right for us. It may or may not be right for us. So, we must inspect or assess its applicability to our environment very carefully.
- Take Responsibility –
When a bridge collapse we only ask one question, “What did engineers do wrong?” Even when software fails, we rarely ask this question. This is due to that in any engineering discipline, best and important methods can be used to produce or develop an awful design, and best and largely antiquated methods to develop an elegant design.
- Understanding priorities of customers –
It is simply possible that customer would tolerate 90 percent of performance that is delivered late only if they could have 10 percent of it on time.
- More they see, more they need –
More the functionality or performance we provide to user, more functionality or performance they will want. Their expectation increases by time to time.
- Plan to throw one away –
The most essential and critical factor is whether a product is entirely new or not. Brand-new applications, architectures, interfaces, or algorithms generally work rarely for first time.
- Design for update or change –
We should update or accommodate change architecture, components, and specification techniques that we generally use.
- Without documentation, design is not a design –
We have some engineers often saying that “I have finished and completed design and all things left is documentation”.
- Be realistic while using tools –
Tools that software used make their customers and users more efficient.
- Encapsulate –
Encapsulate simply means to hide information and it is easy, simply. It is a concept that simply results in software that is simpler and easier to test and very easy to maintain.
- Avoid tricks –
Some of programmers love to create and develop programs with some tricks constructs that perform a function in correct way but in a non-understandable manner. Rather just prove to world how smart we are by avoiding trick code.
- Don’t test-own software –
Software Developers should not test their own software. They should not be primary testers of their own software.
25. Coupling and Cohesion –
Using coupling and cohesion are best way to measure software’s inherent maintainability and adaptability.
- Except for excellence –
Our employees will work in a far better way if we have high expectations for them.