Software Engineering Practices and Software Modeling

Practices topics:
» SOFTWARE ENGINEERING PRACTICE
» CORE PRINCIPLES
» COMMUNICATION PRACTICES
» PLANNING PRACTICES
» MODELING PRACTICE
» CONSTRUCTION PRACTICE
SOFTWARE ENGINEERING PRACTICE
In this part of “software engineering; a practitioner’s approach” you’ll learn about the
principles, concepts, and methods that comprise software engineering practice. These
questions are addressed in the chapters that follows:

• What concepts and principles guide software engineering practice?

• How does system engineering lead to effective engineering?
• What is requirements engineering, and what are the underlying concepts that lead to
good requirements analysis?
• How is thee analysis model created, and are its elements?
• What is design engineering, and what are the underlying concepts that lead to good
design?
• What concepts, models and methods are used to create architectural, interface, and
component level designs?
• What strategies are applicable to software testing?
• What methods are used to design effective test cases?
• What measures and metrics can be used to assess the quality of analysis and design
models, source code and test cases?

Once these questions are answered you’ll be better prepared to apply software
engineering practice.

In a book that explores the lives and thoughts of software engineers, Ellen Ullman
depicts a slice of life as she relates the thoughts of practitioner under pressure.

I have no idea what time it is. There are no windows in this office and no clock, only
the blinking red LED display of a microwave, which flashes 12.00, 12.00, 12.00,
12.00. Joel and I have been programming for days. We have a bug, a stubborn demon
of a bug, so the red pulse no-time feels right, like a read-out of our brains, which have
somehow synchronized themselves at the same blink rate…..

What are we working on?..... The details escape me just now. We may be helping
poor sick people or tuning a set of low- level routines to verify bits on a distributed
database protocol- I don’t care. I should care very much why and for whom and for
what purpose I am writing software. But just now: no. I have passed through a
membrane where that real world and its uses no longer matter. I am a software
engineer…..

A dark image of software engineering practice to be sure, but upon reflection, many of
the readers of this book will be able to relate to it.

People who create computer software practice the art of craft or discipline that is
software engineering. But what it software engineering “practice”? In a generic sense,
practice is a collection of concepts, principles, methods, and tools that a software
engineer calls upon on a daily basis. Practice allows managers to manage software
projects and software engineers to build computer programs. Practice populates a
software process model with the necessary technical and management how-to get the
job done. Practice transforms a haphazard unfocused approach into something that is
more organized, more effective and more likely to achieve success. Some writers
argue for one of these terms to the exclusion of the others. In reality, software
engineering is all three.

What is it? Practice is a broad array of concepts, principles, methods, and tools that
you must consider as software planned and developed. It represents the details-the
technical considerations and how to—that are below the surface of the software
process: the things that you’ll need to actually build high-quality computer software.

Who does it? The practice of software engineering is applied by software engineers

and their managers.

Why is it important? The software process provides everyone involved in the

creation of a computer-based system or product with a road map for getting to a
destination successfully. Practice provides you with the detail you’ll need to drive
along the road. It tells you where the bridges, the roadblocks, and the forks are
located. It helps you understand the concepts and principles that must be understood
and followed to drive safely and rapidly. It instructs you on how to drive, where to
slow down, and where to speed up. In the context of software engineering, practice is
what you do day in and day out as software evolves from an idea to a reality.
What are the steps? Three elements of practice apply regardless of the process
models that is chosen. They are: concepts, principles, and methods. A fourth element
of practice—tools—supports the application of methods.

What is the work product? Practice encompasses the technical activities that

produce all work products that are defined by the software process model that has
been chosen.

We introduced a generic software process model composed of a set of activities that

establish a framework for software engineering practice. Generic framework activities
—communication, planning, modeling,, construction, and deployment—and umbrella
activities establish a skeleton architecture for software engineering work, But how
does the practice of software engineering fit in? In the sections that follow, we
consider the generic concepts and principles that apply to framework activities. The
reader is encouraged to revisit relevant sections within this chapter as specific
software engineering methods and umbrella activities are discussed later in this book.

The essence Practice

In a classic book, How to Solve It, written before modern computes existed, gorge
Polya outlined the essence of problem solving, and consequently, the essence of
software engineering practice:

1. Understand the problem (communication and analysis).

2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

In the context of software engineering, these common sense steps lead to a series of
essential questions.

Understand the problem:

• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, features, and behavior are required to
properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems
that may be easier to understand?

Can the problem be represented graphically? Can an analysis model be created?

Plan the solution:
• Have you seen similar problems before? Are there patterns that are recognizable in a
potential solution? Is there existing software that implements the data, functions,
features, and behavior that are required?
• Has a similar problem been solved? If so, are solutions readily apparent for the sub-
problems?
• Can you represent a solution in a manner that leads to effective implementation?
Can a design model be created?

Carry out the plan:

• Does the solution confirm to the plan? IS source code traceable to the design model?
• Is each component part of the solution probably correct? Have the design and code
been received, or better, has correctness proof been applied to the algorithm?

Examine the result:

• Is it possible to test each component part of the solution? Has a reasonable testing
strategy been implemented?
• Does the solution produce results that confirm to the data? Functions, features and
behavior that are required? Has the software been validated against all stakeholder
requirements?

CORE PRINCIPLES
The dictionary defines the word principle as “an important underlying law or
assumption required in a system of thought.” Throughout this book we 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., customer
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 us establish a mind set for software engineering
practice. They are important for that reason.

David Hooker has proposed seven core principles that focus on software engineering
practice as a whole. They are reproduced below.

The First Principle: The Reason It All Exists

A software system exists for one reason: to value to its users. All decisions should be
made with this in mind. Before specifying a system requirement, before noting a piece
of system functionality, before determining 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 principles support this one.

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
facilities 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 simple ones. Simple also
does not mean “quick and dirty.” In fact, it often, it often takes a lot of thought and
works over multiple iterations to simplify. The pay-off is software that is more
maintainable and less error-prone.

Alexander Pop (1688-1744): “There is certain majesty in simplicity which is far

above all the quaintness of wit.”

The Third Principle: Maintain 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 vision of a software system weakens and will

eventually break even a well-designed the system. Having an empowered architect
who can hold the vision and enforce compliance helps ensure a very successful
software project.

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 who must maintain and extend the system. Someone may have to debug the
code you writ, and that makes them a user of your code. Making their job easier adds
value to the system.

The fifth principles: 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 after just a few months, 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 on. Author’s note: This advice can be dangerous if it is taken to
extremes. Designing for the “general problem” sometimes requires performance
compromises and can require more project effort. This could very possibly lead to the
reuse of an entire system.

The Sixth Principle: plan Ahead for Reuse

Reuse saves time and effort. Author’s not: Although this is true for those who reuse
the software on future projects, reuse can be expensive for those who must design and
build reusable components. Studies indicate that designing and building reusable
components can cost between 25to 200 percent more than targeted software. In some
cases, the cost difference cannot be justified. Achieving a high level of reuse is
arguably the hardest goal to accomplish in developing a 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. Those at the detailed design and code level
are well known and documented. New literature is addressing the reuse of design in
the form of software patterns. However, this just part of the battle. Communicating
opportunities for ruse to others in the organization is paramount. How can you reuse
something that, you don’t know, exists? 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 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 tam simply followed hooker’s seven
principles, many of the difficulties we experience in building complex computer based
systems would be eliminated.
COMMUNICATION PRACTICES
Before customer requirements can be analyzed, modeled, or specified they must be
gathered through a communication (also called requirements elicitation) activity. A
customer has a problem that may be amenable to a computer- based solution. A
developer responds to the customer’s request for help. Communication has begun. But
the road from communication to understanding is often full of potholes.

Effective communication (among technical peers, with the customer and other
stakeholders, and with project managers) is among the most challenging activities that
confront software engineer. In this context, we discuss communication principles that
apply equally to all forms of communication that occur within a software project.

Principle #1: Listen.

Try to focus on the speaker’s words, rather than formulating your response to those
words. Ask for clarification if something is unclear, but avoid constant interruptions.
Never become contentions in your words or actions 9 e.g., rolling your eyes or
shaking your head) as a person is talking.

Principle #2: Prepare before you communicate.

Spend the time to understand the problem before you meet with others. If necessary,
do some research to understand business domain jargon. If you have responsibility for
conducting a meeting, prepare an agenda in advance of the meeting.

Principle #3: Someone should facilitate the activity.

Every communication meeting should have a leader (facilitator) to keep the
conversation moving in a productive direction: (2) to mediate any conflict that does
occur; (3) to ensure that other principles are followed.

Principle #4: Face–to-face communication is best.

But it usually works better when some other representation of the relevant information
is present. For example, a participant may create a drawing or a “strawman” document
that serves as a focus for discussion.

Mark Twain: “shortest road to most perplexities,”

plain questions and plain answers make the shortest road to most perplexities.”

Principle #5: Take notes and documentation decisions:

Things have a way of falling into the cracks. Someone participating in the
communication should serves to build trust among team members and creates a
common goal for the team.

Principle #6: Stay focused, modularize your discussion.

The more the people involved in any communication, the more likely that discussion
will bounce from one topic to the next. The facilitator should keep the conversation
modular, leaving one topic to the next. The facilitator should keep the conversation
modular, leaving one topic only after it has been resolved (however, see principle #9).

Principle #7: If something is unclear, draw a picture.

Verbal communication goes only so far. A sketch or drawing can often provide clarity
when words fail to do the job.

Principle #8: (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. Communication, like any software engineering activity,
takes time. Rather than iterating endlessly, the people who participate should
recognize that many topics require discussion (see principle #2) and that “moving on”
is sometimes the best way to achieve communication agility.

Principle #9: Negotiation is not a contest or a game. It works best when both
parties win.
There are many instances in which the software engineer and the customer must
negotiate functions and features, priorities, and delivery dates. If the team has
collaborated well, all parties have a common goal. Therefore, negotiation will demand
compromise from all parties.

Generic task set for Communication

1. Identify primary customer and other stakeholders.

2. Meet with primary customer to address “context free questions” that define.
• Business need and business values.
• End-users’ characteristics / needs.
• Required user- visible outputs.
• Business constraints.

3. Develop a one- page written statement of project scope that is subject to revision.

4. Review statement of scope with stakeholders and amend as required.

5. Collaborate with customer/end- users to define:
• Resulting outputs and inputs.
• Important software features, functions, and behavior.
• Customer-defined business risks.

6. Develop a brief written description (e.g., a set of lists) of scenarios, output/ inputs,
features/ functions and risks.

7. Iterate with customer- defined priorities to each user scenario, feature, function, and
behavior.

8. Assign customer- defined priorities to each user scenario, feature, function, and
behavior.

9. Review all information gathered during the communication activity with the
customer and other stakeholder and armed as required.

10. Prepare for planning activity.

The Different Between Customers and End-users

Software engineers communicate with many different stakeholders, but customers and
end-users have the most significant impact on the technical work that follows. In some
cases the customer and the end-user are one and the same, but for many projects, the
customer and the end-user different people, working for different managers in
different business organizations.

A customer is the person or group who: (1) originally requested the software to be
built; (2) defines overall business objectives for the software; (3) provides basic
product requirements; and (4) coordinates funding for the project. In a product or
system business, the customer is often the marketing department. In an IT
environment, the customer might be a business component or department.

And end-user is the person or group who: (1) will actually use software that is built to
achieve some business purpose, and (2) will define operational details of the software
so that the business purpose can be achieved.
PLANNING PRACTICES
The communication activity helps a software team to define its overall goals and
objectives (subject, of course, to change as time passes). However, understanding
these goals and objectives is not the same as defining a plan for getting there. The
planning activity encompasses a set of management and technical practices that
enable the software tam to define a road map as it travels towards its strategic goal
and technical objectives.

Dwight D. Eisenhower: “In preparing for battle I have always found that plants are
useless, but planning is indispensable.”

There are many different planning philosophies. Some people are “minimalists,
“arguing that change often obviates the need for a detailed plan. Others are
“traditionalists,” arguing that the plan provides an effective road map, and the more
detail it has, the less likely the team will become lost. Still others are “agilists,”
arguing that quick “planning game” may be necessary, but that the road map will
emerge as “real work” on the software begins.

What to do? On many projects, over planning is time consuming and fruitless (too
many things change), but under planning is a recipe for chaos. Like most things in
life, planning should be conducted in moderation, enough to provide useful guidance
for the team- no more, no less.

Regardless of the rigor with which planning is conducted, the following principles
always apply.

Principle #1: Understand the scope of the project. It’s impossible to use a road map
if you don’t know where you’re going. Scope provides the software.

Principle #2: Involve the customer in planning activity. The customer defines

priorities and establishes the project constraints.

Principle #3: Recognize that planning is iterative. As work begins, it is very likely
that things will change. As a consequence, the plan must be adjusted to accommodate
these changes. In addition, iterative and incremental process models dictate re-
planning based on feedback received from users.

Principle #4: Estimate based on what you know. The intent of estimation is to

provide an indication of effort, cost, and task duration, based on the team’s current
understanding of the work to be done.

Principle #5: Consider risk as you define the plan. If the team has defined risks that
have high impact and high probability, contingency planning is necessary.
Principle #6: Be realistic. People don’t work 100 percent every day. Noise always
enters into any human communication. Omission and ambiguity are facts of life.
Change will occur. Even the best software engineers make mistakes. These and other
realities should be considered as a project plan is established.

Principle #7: Adjust granularity as you define the plan. Granularity refers to the
level of detail that is introduced as a project plan is developed. A “fine granularity”
plan provides significant work detail that is planned over relatively short time
increments.

Principle #8: Define how you intend to ensure quality. The plan should identify
how the software team intends to ensure quality. If formal technical reviews are to be
conducted, they should be scheduled.

Principle #9: Describe how you intend to accommodate change. Even the best
planning can be obviated by uncontrolled change. The software team should identify
how changes are to be accommodated as software engineering work proceeds.

Principle #10: Track the plan frequently and make adjustments are
required. Software project falls behind schedule one day at a time. Therefore, it
makes sense to track progress on a daily basis, looking for a problem areas and
situation in which scheduled work does not confirm to actual work conducted. When
slippage is encountered, the plan is adjusted accordingly.

Why is the system being developed? All parties should assess the validity of
business reasons for the software work. Stated in another way, does the business
purpose justify the expenditure of people, time, and money?

What will be done? Identify the functionality to be built, and by implication, the task
required to get the job done.

When will it be accomplished? Establish a workflow and timeline for key project

tasks and identify the milestones required by the customer.

Who is responsible for a function? The role and responsibility of each member of

the software tam must be defined.

Where they are organizationally located? Not all roles and responsibilities reside
within the software tam itself. The customer, users, and other stakeholders also have
responsibilities.
How will the job be done technically and managerially? Once product scope is
established, a management and technical strategy for the project must be defined.

How much of each resource is needed? The answer to this question is derived by

developing estimates based on answers to earlier questions.

The answers to the above questions are important regardless of the size of complexity
of a software project. But how does the planning process begin?

Tom De Marco: “we think that software developers are missing a vital truth: most
organizations don’t know what they do. They think they know, but they don’t know.”

Generic task set for Planning:

1. Reevaluate project scope.

2. Assess risks.
3. Develop and/or refine user scenarios.
4. Extract functions and features from the scenarios.
5. Define technical functions and features that enable software infrastructure.
6. Group functions and features (scenarios) by customer priority.
7. Create a coarse granularity project plan.
• Define the number of projected software increments.
• Establish an overall project schedule.
• Establish projected delivery dates for each increment.
8. Create a fine granularity plan for the current iteration.
• Define work tasks for each functional feature.
• Estimate effort for each work task.
• Assign responsibility for each work task.
• Define work products to be produced.
• Identify quality assurance methods to be used.
• Describe methods for managing change.
9. Track progress regularly.
• Not progress areas(e.g., schedule slippage).
• Make adjustments as required.
MODELING PRACTICE
The models are created to gain better understanding of actual entity to be built. When
the entity is a physical thing, we can build a model that is identical in form of shape
but smaller in scale. However, when the entity is software, our model must take a
different form. It must be capable of representing the information that software
transforms, the architecture and functions that enable the transformation to occur, the
features that user’s desire, and the behavior of the system as the transformation is
taking place.

Two classes of models are crated: Analysis models and design models. 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.

Analysis Modeling Principles

A large number of analysis modeling methods have been developed. Each analysis
methods has unique point of view. However, all analysis methods are related by a set
of operational principles.

Principle #1: The information domain of a problem must be represented and

understood. The information domain compasses the data that flow into the system
and the data stores that collect and organize persistent data objects.

Principle #2: The functions that the software performs must be defined. Software
functions provide direct benefit to visible end-user. Some functions transform data
that flow into the system; in other cases, functions effect some level of control over
internal software processing or external system elements.

Principle #3: The behavior of the software must be represented. The behavior of

computer software is driven by its interaction with the external environment. Input
provided by end-users, control data provided by an external system, or monitoring
data collected over a network all cause the software to behave in a specific way.

Principle #4: The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered fashion. Analysis
modeling is the first step in software engineering problem solving. It allows the
practitioner to understand the problem better and establishes a basis for the solution
(design). Complex problems are difficult to solve in their entirety. For this reason, we
use a divide and conquer strategy. A large, complex problem is divided into sub-
problems until each sub- problem is relatively easy to understand. This concept is
called partitioning, and it is a key strategy in analysis modeling.

Principle #5: The analysis task should move from essential information toward
implementation detail. Analysis modeling begins by describing the problem from the
end-user’s perspective. The “essence” of a problem is described without any
consideration of how a solution will be implemented.

Design Modeling Principles

The design model created for software provides a variety of different views of system.
There is no shortage of methods for deriving various elements of a software design.
Some methods are data-driven, allowing the data structure to dictate the program
architecture and the resultant processing component. Others are pattern-driven, using
information about the problem domain (the analysis model) to develop architectural
styles and processing patterns- a set of design principles that can be applied regardless
of the method that is used.

Principle #1: Design should be traceable to the analysis model. The analysis model
describes the information domain of the problem, uses visible functions, system
behavior, and a set of analysis classes that package business objects with the methods
that service them. The design model translates this information into an architecture, a
set of subsystems that implement major functions, and a set of component- level
designs that realize analysis classes.

Principle #2: Always consider the architecture of the system to be built. Software

architecture is the skeleton of the system to be built. It affects interfaces, data
structures, program control flow behavior, the manner in which testing can be
conducted and the maintainability of resultant system.

Principle #3: Design of data is as important as design of processing

functions. Data design is an essential element of architectural design. The manner in
which data objects are realized within the design cannot be left to chance. A well-
structured data design helps to simplify program flow, makes design and
implementation of software components easier, and makes overall processing more
efficient.

Principle #4: Interfaces (both internal and external) must be designed with
care. The manner in which data flow between the components of a system has much
to do with processing efficiency, error propagation, and design simplicity, A well
designed interface integration easier and assists the tester in validating components
functions.

Principle #5: User interface design should be tuned the needs of the end-
user. However, in every case, it should be stress free and easy to use. The user
interface is the visible manifestation of the software. A poor interface design often
leads to the perception that the software is “bad”.

Principle #6: Components should be functionally independent. Functional

independence is a measure of the “single- mindedness” of a software component. The
functionally that is delivered by a component should be cohesive- that is, it should
focus on one and only on function or sub-function.

Principle #7: Components should be loosely coupled to one another and to the
external environment. Coupling is achieved in many ways-via component inter-face,
by messaging and through global data. As the level of coupling increases, the
likelihood of error propagation also increases and the overall maintainability of the
software decreases. Therefore, component coupling should be kept as low as is
reasonably possible.

Principle #8: Design representation(model) should be easily understandable. The

purpose of design is to communicate information to practitioners who will generate
code, to those who will test the software, and others who may maintain the software in
the future. If the design is difficult to understand, it will not serve as an effective
communication medium.

Principle #9: The design should be developed iteratively. With each iteration, the
designer should strive for greater simplicity. Like most of the creative activities,
design occurs iteratively. The first iteration works to refine the design and correct
errors, but later iterations should strive to make the design as simple as is possible.

CONSTRUCTION PRACTICE
The construction activity encompasses a set of coding and testing task that lead
operational software that is ready for delivery to the customer or end-user. In modern
software engineering work, coding may be: (1) the direct creation of programming
language source code; (2) the automatic generation of source code using an
intermediate design-like representation of the component to be built; (3) the automatic
generation of executable code using a fourth generation programming language.

Coding Principle and Concepts

The principles and concepts that guide the coding task are closely aligned
programming style, programming languages, and programming methods. However,
there are a number of fundamental principles that can be stated:
Preparation principles: Before you write one line of code, be sure you:
1. Understand the problem you’re trying to solve.
2. Understand basic design principles and concepts.
3. Pick a programming language that meets the needs of the software to the hilt and
the environment in which it will operate.
4. Select a programming environment that provides tools that will make your work
easier.
5. Create a set of unit tests that will be applied once the component you code is
completed.

Coding principles: As you begin writing code, be sure you:

1. Constraint your algorithm by following structured programming practice.
2. Select data structure that will meet the needs of the design.
3. Understand the software architecture and create interfaces that are consistent.
4. Keep conditional statement as simple as possible.
5. Create nested loops in a way that makes them easily testable.
6. Select meaningful variable names and follow other local coding standards.
7. Write code that is self-documenting.
8. Create a visual layout that aids understanding.

Validation principles: After you’ve completed your first coding pass, be sure you:
1. Build architectural infrastructure,
Review the architectural design.
Code and test the components that enable architectural infrastructure.
Acquire reusable architectural patterns.
Test the infrastructure to ensure interface integrity.

2. Build a software component.

Review the component- level design.
Create a set of unit tests for the component.
Code components data structures and interface.
Code internal algorithms and related processing functions.
Review code as it is written.
Look for correctness.
Ensure that coding standards have been maintained.
Ensure that the cod is self- documenting.

3. Unit test the components.

Conduct all unit tests.
Correct errors uncovered.
Reapply unit tests.

4. Integrate completed components into the architectural infrastructure.

Testing Principles:

In a classic book on software testing, Glen Myers states a number of rules that can
serve well as testing objectives:

• Testing in a process of executing with the intent of finding an error.

• A good test case is one that has a high probability of finding as as-yet undiscovered
error.
• A successful test is one that uncovers an as- yet –undiscovered error.

These objectives imply a dramatic change in viewpoint for some software developers.
They move counts to the commonly held view that a successful test is one in which no
errors are found. Our objective is to design tests that systematically uncover different
classes of errors and to do with a minimum amount of time and effort. These errors
can be corrected subsequently.

Davis suggests a set of testing principles that have been adapted for use in this book:

Principle #1: All tests should be traceable to customer requirements. The

objective of software testing is to uncover errors. It follows that thee most server
defects (from the customer’s point of view) are those that cause the program to fail to
meet its requirements/goals.

Principle #2: Tests should be planned long before testing begins. Test planning
can began as soon as the analysis model is complete. Detailed definition of test cases
can begin as soon as the design model has been solidified. Therefore, all tests can be
planned and designed before any code has been generated.

Principle #3: The pare to principle applies to software testing. Stated simply, the
Pareto principle implies that 80 percent of all errors uncovered during testing will
likely be traceable to 20 percent of all program components. The problem, of course,
is to isolate these suspect components and to thoroughly test them.

Principle #4: Testing should begin “in the small” and progress toward testing “in
the large”. The first tests planned and executed generally focus on individual
components. As testing progresses, focus shifts in an attempt to find error in
integrated clusters of components and ultimately in the entire system.
Principle #5: Exhaustive testing is not possible. The number of path permutations
for even a moderately sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing. It is possible,
however, to adequately cover program logic and to ensure that all conditions in the
component- level design have been exercised.

Deployment
The deployment activity encompasses three actions delivery, support, and feedback.
Because modern software process models are evolutionary in nature, deployment
happens not once, but a number of times as software moves towards completion. Each
delivery cycle provides the customer and end-users with an operational software
increment that provides usable functions and features. The delivery of a software
increment represents an important milestone for any software project. A number of
key principles should be followed as the team prepares to deliver an increment:

Principle #1: Customer expectations for the software must be managed. The

customer expects more than the team has promised to deliver and disappointment
occurs immediately. This results in feedback that is not productive and which ruins
team morale.

Principle #2: A complete delivery package should be assembled and tested. A

CD_ ROM or other media containing all executable software, support data files,
support document, and other relevant information must be assembled and thoroughly
beta- tested with actual users.

Principle #3: A support regime must be established before the software is

delivered. An end-user expects responsiveness and accurate information when a
question or problem arises. Support should be planned, support material should be
prepared, and appropriate record keeping mechanism should be established so that the
software team can conduct a categorical assessment of the kinds of support requested
required.

Principle #4. Appropriate instructional materials must be provided to end-

users. The software team delivers more than the software itself. Appropriate training
aids should be developed, trouble-shooting guidelines should be provided and a
“what’s- different about- this-software-increment” description should be published.

Principle #5: Buggy software should be fixed first, delivered later. Under time
pressure, some software organizations deliver low-quality increments with a warning
to the customer that bugs “will be fixed in the next release”. This is a mistake. There’s
a saying in the software business: “Customer will forget you delivered a high- quality
product a few days late, but they will never the problems that a low-quality product
caused them. The software reminds them everyday.”

Summary
1. The various principles that are discussed in this chapter are the guidelines for a
better software engineering practices.

2. If every software engineering and software team follows the Hooker’s seven
principles, then many of the difficulties in building the complex system can be solved.

3. The planning activity encompasses a set of management and technical practices that
enable the software team to define a road map as it travels towards its strategic goal
and tactical objectives.

4. Coding and testing principles lead to a better construction practice.

5. Delivery, support and feedback are combined to form a deployment activity.

SOFTWARE ENGINEERING CODE OF ETHICS AND PROFESSIONAL PRACTICE

Computers have a central and growing role in commerce, industry, government,

medicine, education, entertainment and society at large. Software engineers are those

who contribute by direct participation or by teaching, to the analysis, specification,

design, development, certification, maintenance and testing of software systems.

Because of their roles in developing software systems, software engineers have

significant opportunities to do good or cause harm, to enable others to do good or cause

harm, or to influence others to do good or cause harm. To ensure, as much as possible,

that their efforts will be used for good, software engineers must commit themselves to

making software engineering a beneficial and respected profession. In accordance with

that commitment, software engineers shall adhere to the following Code of Ethics and

Professional Practice.

The Code contains eight Principles related to the behavior of and decisions made by

professional software engineers, including practitioners, educators, managers,

supervisors and policy makers, as well as trainees and students of the profession. The

Principles identify the ethically responsible relationships in which individuals, groups,

and organizations participate and the primary obligations within these relationships.

The Clauses of each Principle are illustrations of some of the obligations included in

these relationships. These obligations are founded in the software engineer’s humanity,

in special care owed to people affected by the work of software engineers, and the

unique elements of the practice of software engineering. The Code prescribes these as

obligations of anyone claiming to be or aspiring to be a software engineer.

It is not intended that the individual parts of the Code be used in isolation to justify

errors of omission or commission. The list of Principles and Clauses is not exhaustive.

The Clauses should not be read as separating the acceptable from the unacceptable in

professional conduct in all practical situations. The Code is not a simple ethical

algorithm that generates ethical decisions. In some situations standards may be in

tension with each other or with standards from other sources. These situations require
the software engineer to use ethical judgment to act in a manner, which is most

consistent with the spirit of the Code of Ethics and Professional Practice, given the

circumstances.

Ethical tensions can best be addressed by thoughtful consideration of fundamental

principles, rather than blind reliance on detailed regulations. These Principles should

influence software engineers to consider broadly who is affected by their work; to

examine if they and their colleagues are treating other human beings with due respect;

41

to consider how the public, if reasonably well informed, would view their decisions; to

analyze how the least empowered will be affected by their decisions; and to consider

whether their acts would be judged worthy of the ideal professional working as a

software engineer. In all these judgments concern for the health, safety and welfare of

the public is primary; that is, the "Public Interest" is central to this Code.

The dynamic and demanding context of software engineering requires a code that is

adaptable and relevant to new situations as they occur. However, even in this

generality, the Code provides support for software engineers and managers of software

engineers who need to take positive action in a specific case by documenting the ethical

stance of the profession. The Code provides an ethical foundation to which individuals

within teams and the team as a whole can appeal. The Code helps to define those actions

that are ethically improper to request of a software engineer or teams of software

engineers.

The Code is not simply for adjudicating the nature of questionable acts; it also has an

important educational function. As this Code expresses the consensus of the profession

on ethical issues, it is a means to educate both the public and aspiring professionals

about the ethical obligations of all software engineers.

PRINCIPLES

Principle 1: PUBLIC

Software engineers shall act consistently with the public interest. In particular, software

engineers shall, as appropriate:

1.01. Accept full responsibility for their own work.

1.02. Moderate the interests of the software engineer, the employer, the client and the

users with the public good.

1.03. Approve software only if they have a well-founded belief that it is safe, meets

specifications, passes appropriate tests, and does not diminish quality of life, diminish

privacy or harm the environment. The ultimate effect of the work should be to the

public good.

1.04. Disclose to appropriate persons or authorities any actual or potential danger to the

user, the public, or the environment, that they reasonably believe to be associated with

software or related documents.

1.05. Cooperate in efforts to address matters of grave public concern caused by software,

its installation, maintenance, support or documentation.

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning

software or related documents, methods and tools.

42

1.07. Consider issues of physical disabilities, allocation of resources, economic

disadvantage and other factors that can diminish access to the benefits of software.

1.08. Be encouraged to volunteer professional skills to good causes and contribute to

public education concerning the discipline.

Principle 2: CLIENT AND EMPLOYER

Software engineers shall act in a manner that is in the best interests of their client and

employer, consistent with the public interest. In particular, software engineers shall, as

appropriate:

2.01. Provide service in their areas of competence, being honest and forthright about

any limitations of their experience and education.

2.02. Not knowingly use software that is obtained or retained either illegally or

unethically.

2.03. Use the property of a client or employer only in ways properly authorized, and

with the client's or employer's knowledge and consent.

2.04. Ensure that any document upon which they rely has been approved, when

required, by someone authorized to approve it.

2.05. Keep private any confidential information gained in their professional work, where

such confidentiality is consistent with the public interest and consistent with the law.

2.06. Identify, document, collect evidence and report to the client or the employer

promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate

intellectual property law, or otherwise to be problematic.

2.07. Identify, document, and report significant issues of social concern, of which they

are aware, in software or related documents, to the employer or the client.

2.08. Accept no outside work detrimental to the work they perform for their primary

employer.

2.09. Promote no interest adverse to their employer or client, unless a higher ethical

concern is being compromised; in that case, inform the employer or another appropriate

authority of the ethical concern.

Principle 3: PRODUCT

Software engineers shall ensure that their products and related modifications meet the

highest professional standards possible. In particular, software engineers shall, as

appropriate:

43

3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring

significant tradeoffs are clear to and accepted by the employer and the client, and are

available for consideration by the user and the public.

3.02. Ensure proper and achievable goals and objectives for any project on which they

work or propose.

3.03. Identify, define and address ethical, economic, cultural, legal and environmental

issues related to work projects.

3.04. Ensure that they are qualified for any project on which they work or propose to

work by an appropriate combination of education and training, and experience.

3.05. Ensure an appropriate method is used for any project on which they work or
propose to work.

3.06. Work to follow professional standards, when available, that are most appropriate

for the task at hand, departing from these only when ethically or technically justified.

3.07. Strive to fully understand the specifications for software on which they work.

3.08. Ensure that specifications for software on which they work have been well

documented, satisfy the users’ requirements and have the appropriate approvals.

3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and

outcomes on any project on which they work or propose to work and provide an

uncertainty assessment of these estimates.

3.10. Ensure adequate testing, debugging, and review of software and related

documents on which they work.

3.11. Ensure adequate documentation, including significant problems discovered and

solutions adopted, for any project on which they work.

3.12. Work to develop software and related documents that respect the privacy of those

who will be affected by that software.

3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it

only in ways properly authorized.

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

3.15 Treat all forms of software maintenance with the same professionalism as new

development.

Principle 4: JUDGMENT

Software engineers shall maintain integrity and independence in their professional

judgment. In particular, software engineers shall, as appropriate:

44

4.01. Temper all technical judgments by the need to support and maintain human

values.

4.02 Only endorse documents either prepared under their supervision or within their

areas of competence and with which they are in agreement.

4.03. Maintain professional objectivity with respect to any software or related

documents they are asked to evaluate.

4.04. Not engage in deceptive financial practices such as bribery, double billing, or other

improper financial practices.

4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably

be avoided or escaped.

4.06. Refuse to participate, as members or advisors, in a private, governmental or

professional body concerned with software related issues, in which they, their employers

or their clients have undisclosed potential conflicts of interest.

Principle 5: MANAGEMENT

Software engineering managers and leaders shall subscribe to and promote an ethical

approach to the management of software development and maintenance . In particular,

those managing or leading software engineers shall, as appropriate:

5.01 Ensure good management for any project on which they work, including effective

procedures for promotion of quality and reduction of risk.

5.02. Ensure that software engineers are informed of standards before being held to

them.

5.03. Ensure that software engineers know the employer's policies and procedures for

protecting passwords, files and information that is confidential to the employer or

confidential to others.

5.04. Assign work only after taking into account appropriate contributions of education

and experience tempered with a desire to further that education and experience.

5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and

outcomes on any project on which they work or propose to work, and provide an

uncertainty assessment of these estimates.

5.06. Attract potential software engineers only by full and accurate description of the

conditions of employment.

5.07. Offer fair and just remuneration.

5.08. Not unjustly prevent someone from taking a position for which that person is

suitably qualified.
45

5.09. Ensure that there is a fair agreement concerning ownership of any software,

processes, research, writing, or other intellectual property to which a software engineer

has contributed.

5.10. Provide for due process in hearing charges of violation of an employer's policy or

of this Code.

5.11. Not ask a software engineer to do anything inconsistent with this Code.

5.12. Not punish anyone for expressing ethical concerns about a project.

Principle 6: PROFESSION

Software engineers shall advance the integrity and reputation of the profession

consistent with the public interest. In particular, software engineers shall, as

appropriate:

6.01. Help develop an organizational environment favorable to acting ethically.

6.02. Promote public knowledge of software engineering.

6.03. Extend software engineering knowledge by appropriate participation in

professional organizations, meetings and publications.

6.04. Support, as members of a profession, other software engineers striving to follow

this Code.

6.05. Not promote their own interest at the expense of the profession, client or

employer.

6.06. Obey all laws governing their work, unless, in exceptional circumstances, such

compliance is inconsistent with the public interest.

6.07. Be accurate in stating the characteristics of software on which they work, avoiding

not only false claims but also claims that might reasonably be supposed to be

speculative, vacuous, deceptive, misleading, or doubtful.

6.08. Take responsibility for detecting, correcting, and reporting errors in software and

associated documents on which they work.

6.09. Ensure that clients, employers, and supervisors know of the software engineer's

commitment to this Code of ethics, and the subsequent ramifications of such

commitment.

6.10. Avoid associations with businesses and organizations which are in conflict with

this code.

6.11. Recognize that violations of this Code are inconsistent with being a professional

software engineer.

46

6.12. Express concerns to the people involved when significant violations of this Code

are detected unless this is impossible, counter-productive, or dangerous.

6.13. Report significant violations of this Code to appropriate authorities when it is clear

that consultation with people involved in these significant violations is impossible,

counter-productive or dangerous.

Principle 7: COLLEAGUES

Software engineers shall be fair to and supportive of their colleagues. In particular,

software engineers shall, as appropriate:

7.01. Encourage colleagues to adhere to this Code.

7.02. Assist colleagues in professional development.

7.03. Credit fully the work of others and refrain from taking undue credit.

7.04. Review the work of others in an objective, candid, and properly-documented way.

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.

7.06. Assist colleagues in being fully aware of current standard work practices including

policies and procedures for protecting passwords, files and other confidential

information, and security measures in general.

7.07. Not unfairly intervene in the career of any colleague; however, concern for the

employer, the client or public interest may compel software engineers, in good faith, to

question the competence of a colleague.

7.08. In situations outside of their own areas of competence, call upon the opinions of

other professionals who have competence in that area.

Principle 8: SELF

Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession. In

particular, software engineers shall continually endeavor to:

8.01. Further their knowledge of developments in the analysis, specification, design,

development, maintenance and testing of software and related documents, together with

the management of the development process.

8.02. Improve their ability to create safe, reliable, and useful quality software at

reasonable cost and within a reasonable time.

8.03. Improve their ability to produce accurate, informative, and well-written

documentation.

47

8.04. Improve their understanding of the software and related documents on which they

work and of the environment in which they will be used.

8.05. Improve their knowledge of relevant standards and the law governing the

software and related documents on which they work.

8.06 Improve their knowledge of this Code, its interpretation, and its application to

their work.

8.07 Not give unfair treatment to anyone because of any irrelevant prejudices.

8.08. Not influence others to undertake any action that involves a breach of this Code.

8.09. Recognize that personal violations of this Code are inconsistent with being a

professional software engineer.

This Code was developed by the ACM/IEEE-CS joint task force on Software

Engineering Ethics and Professional Practices (SEEPP):

Executive Committee: Donald Gotterbarn (Chair), Keith Miller and Simon Rogerson;

Members: Steve Barber, Peter Barnes, Ilene Burnstein, Michael Davis, Amr El-Kadi, N.

Ben Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Mark Kanko, Ernie

Kallman, Duncan Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman,

Douglas Phillips, Peter Ron Prinzivalli, Patrick Sullivan, John Weckert, Vivian Weil, S.

Weisband and Laurie Honour Werth.

This Code may be published without permission as long as it is not changed in any way
and it carries the copyright notice. Copyright (c) 1999 by the Association for

Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers,