The General Principles of Software Engineering
The Role of Software Engineers
The developments in
the field of Software engineering have given rise to a well-defined role for a
software engineer with requisite experience and qualification. A software
engineer is a professional is a professional engineer, who is well versed in
the application of engineering discipline to the creation of software. A software
engineer must be a good programmer, well versed in data structures and
algorithms and be fluent in one or more programming languages. However, there
is a confusion about the role of a programmer and a software engineer. A
programmer writes codes that a program run while a software run while a
software engineer creates designs for the programmer to implement them.
A software must have
knowledge of several design approaches, and have the ability to translate vague
requirements and devices into precise specifications and be able to converse
with the user of a system in terms of its application. He must be flexible and
open to grasp and become conversant with the essentials of different application
areas. He must have the ability to navigate among several levels of abstraction
at different stages of the project, from specific application procedures and
requirements, to abstractions for the software system, to a specific design for
the system, and finally, to the detailed coding level.
The skills of a
software engineer are needed to build a variety of models and analyze these
models to determine the best of them. Different models
are used in the requirements phase, in the design of the software architecture,
and in the implementation phase. Models may also answer the behavior of the
system of the system and its performance.
Software engineers
often work in large software projects within a team. Hence, they need
communication skills and interpersonal skills. They have their deadline to
complete the projects of their clients and hence scheduling time and work is
one of their top-most priorities. A software engineer is responsible for a
number of things. There are many specialist who own a particular
responsibility. For instance, an analyst is responsible for analyzing the
application area, while a performance analyst is responsible for analyzing the
performance of the system. Sometimes, a software engineer has to take up
multiple tasks at different stages of the project development.
{tocify} $title= {Table
of Contents}
General Principles
The dictionary defines
the word principle “an important underlying law or assumption required in a
system of thought.” Throughout this book we’ll discuss principles at many
different levels of abstraction. Some focus on software engineering as a whole,
others consider a specific generic framework activity (e.g., communication), and still others focus
on software engineering actions (e.g., architectural design) or technical tasks
(e.g., write a usage scenario). Regardless of their level of focus, principles
help you establish a mind-set for solid software engineering practice. They are
important for that reason.
David Hooker [Hoo96]
has proposed seven principles that focus on software engineering practice as a
whole. They are reproduced in the following paragraphs.
Note:
Before beginning a
software project, be sure the software has a business purpose and that users
perceive value in it.
The First Principles: The Reason it All Exists
A software system
exits for one reason: to provide value to its users. All decisions should be
made this mind. Before specifying a system requirement, before noting a piece
of system functionality, before determine the hardware platforms or development
processes, ask yourself questions such as:” Does this add real value to the
system?” If the answer is no, don’t do it. All other principle supports this
one.
Note:
“There is certain
majesty in simplicity which is far above all the quaintness of wit”.
-Alexander Pape
(1688-1744).
The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not
a haphazard process. There are many Factors to consider in any design effort.
All design should be as simple as possible, But no simpler. This facilitates
having a more easily understood and easily maintained system. This is not to
say that features, even internal features, should be discarded in the name of
simplicity. Indeed, the more elegant designs are usually the more simple ones.
Simple also does not mean “quick and dirty”. In fact, it often takes a lot of thought and
work over multiple iterations to simplify. The payoff is software that is more
maintainable and less error- prone.
The Third Principle: Main the Vision
A clear vision is
essential to the success of a software project. Without one a project almost
unfailingly ends up being “of two [or more] minds” about itself. Without
conceptual integrity, a system threatens to become a patchwork of incompatible
designs, held together by the wrong kind of screws… Compromising the
architectural ignored of a software system weakens and will eventually break
event the well-design systems. Having an empower architecture who can hold the
vi-sion and force compliance helps ensure a very successful software project.
Note:
If software less
values, it will change over its useful life. For that reason, software must be
left to be maintainable
The Fourth Principle: What You Produce, Others Will Consume
Seldom is an
industrial-strength software system constructed and used in a vacuum. In some
way or other, someone else will use, maintain, document, or otherwise depend on
being able to understand your system. So, always specify, design, and implement
knowing someone else will have to understand what you are doing. The audience
for any product of software development is potentially large. Specify with an
eye to the users. Design, keeping the implementers in mind. Code with concern
for those that must maintain and extend the system. Someone may have to debug
the code you write, and that makes them a user of your code. Making their job
easier adds value to the system.
The Fifth Principle: Be Open to the Future
A system with a long
lifetime has more value. In today's computing environments, where specifications change on a moment’s notice
and hardware platforms are obsolete just a few months old, software lifetimes
are typically measured in months instead of years. However, true
“industrial-strength” software systems must endure far longer. To do this successfully,
these systems must be ready to adapt to these and other changes. Systems that
do this successfully are those that have been designed this way from the start.
Never design yourself into a corner. Always ask “what if,” and prepare for all
possible answers by creating systems that solve the general problem, not just
the specific one.6 This could very possibly lead to the reuse of an entire
system.
The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and
effort. Achieving a high level of reuse is arguably the hardest goal to
accomplish in developing software system. The reuse of code and design has been
proclaimed as a major benefit of using object-oriented technologies. However,
the return on this investment is not automatic. To leverage the reuse
possibilities that object-oriented [or conventional] programming provides
requires forethought and planning. There are many techniques to realize reuse
at every level of the system development process . . . Planning ahead for reuse
reduces the cost and increases the value of both the reusable components and
the systems into which they are incorporated.
The Seventh Principle: Think!
This last Principle is
probably the most overlooked. Placing clear, complete thought before action
almost always produces better results. When you think about something, you are
more likely to do it right. You also gain knowledge about how to do it right
again. If you do think about something and still do it wrong, it becomes a
valuable experience. A side effect of thinking is learning to recognize when
you don’t know something, at which point you can research the answer. When
clear thought has gone into a system, value comes out. Applying the first six
principles requires intense thought, for which the potential rewards are
enormous. If every software engineer and every software team simply followed
Hooker’s seven principles, many of the difficulties we experience in building
complex computer-based systems would be eliminated.