Software Engineering Principles

Home   »   Software Engineering Principles

# Software Engineering Principles #
You often hear people say that software development
knowledge has a 3-year half-life: half of what you need to
know today will be obsolete within 3 years. In the domain
of technology-related knowledge, that’s probably about
right. But there is another kind of software development
knowledge—a kind that I think of as "software
engineering principles"—that does not have a three-year
half-life. These software engineering principles are likely
to serve a professional programmer throughout his or her
career.


## Designing Software ##
Build software that exhibits effective
modularity. Separation of concerns (Principle #1) establishes a
philosophy for software. Modularity provides a mechanism for
realizing the philosophy (Well-defined components).!


Component-level design should be
functionally independent. Focus on one and only one
function. !


Look for patterns. Brad Appleton [App00]
suggests that: “The goal of patterns within the software
community is to create a body of literature to help software
developers resolve recurring problems encountered
throughout all of software development.


Strive for consistency. A familiar context
makes software easier to use. Stick with same notation.!


The design should be developed iteratively.
With each iteration, the designer should strive for greater
simplicity. Like all activities for refinement.
Focus on the transfer of information. Pay
special attention to the analysis, design, construction, and
testing of interfaces which make the transfer of information.


Manage change. The approach may be either
formal or informal, but mechanisms must be established to
manage the way changes are requested, assessed, approved
and implemented.!


A complete delivery package should be assembled
and tested. A CD or other media containing all software,
documentation should be assembled. !


## Collaboration and Communication ##
Build an effective team. Software engineering
process and practice are important, but the bottom line is
people. Build a self-organizing team that has mutual trust
and respect.!


Stay focused, modularize your discussion. The more
people involved in any communication, the more likely that discussion
will bounce from one topic to the next (facilitator’s role).


Strive for collaboration. Collaboration and consensus
occur when the collective knowledge of members of the team is
combined to describe product.!


Take notes and document decisions. Someone
participating in the communication should serve as a “recorder” and
write down all important points and decisions.


(a) Once you agree to something, move on; (b) If you
can’t agree to something, move on; (c) If a feature or function is unclear
and cannot be clarified at the moment, move on. !


## Planning ##
Requirements models (also called analysis models)
represent the customer requirements by depicting
the software in three different domains: the
information domain, the functional domain, and the
behavioral domain. !


Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.!


Design of data is as important as design of
processing functions. The way the data objects are realized.!


Leave a Reply

Your email address will not be published. Required fields are marked *