SOFTWARE ENGINEERING

UNIT – I
INTRODUCTION TO SOFTWARE
ENGINEERING

Software Engineering is a systematic, disciplined, quantifiable study and

approach to the design, development, operation, and maintenance of a
software system.

➢ Software Engineering is mainly used for large projects based on

software systems rather than single programs or applications.
➢ The main goal of software Engineering is to develop software
application for improving the quality, budget and time efficiency.
➢ Software Engineering ensures that the software that has to built should
be consistent, correct, also on budget, on time and within the required
requirements.

Objectives of Software Engineering:

1. Maintainability – It should be feasible for the software to evolve to meet

changing requirements.
2. Efficiency – The software should not make wasteful use of computing devices
such as memory, processor cycles, etc.
3. Correctness – A software product is correct if the different requirements as
specified in the SRS document have been correctly implemented.
4. Reusability – A software product has good reusability if the different modules of
the product can easily be reused to develop new products.
5. Testability – Here software facilitates both the establishment of test criteria and
the evaluation of the software with respect to those criteria.
6. Reliability – It is an attribute of software quality. The extent to which a program
can be expected to perform its desired function, over an arbitrary time period.
7. Portability – In this case, the software can be transferred from one computer
system or environment to another.
8. Adaptability – In this case, the software allows differing system constraints and
the user needs to be satisfied by making changes to the software.
9. Interoperability – Capability of 2 or more functional units to process data
cooperatively.
 THE EVOLVING ROLE OF SOFTWARE

Today, software takes on a dual role. It is a product and, at the same time, the
vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer
hardware or, more broadly, a network of computers that are accessible by local
hardware.
Whether it resides within a cellular phone or operates inside a mainframe
computer, software is an information transformer—producing, managing, acquiring,
modifying, displaying, or transmitting information that can be as simple as a single bit
or as complex as a multimedia presentation.
As the vehicle used to deliver the product, software acts as the basis for the
control of the computer (operating systems), the communication of information
(networks), and the creation and control of other programs (software tools and
environments).
Software delivers the most important product of our time—information.
Software transforms personal data (e.g., an individual’s financial transactions) so that
the data can be more useful in a local context; it manages business information to
enhance competitiveness; it provides a gateway to worldwide information networks
(e.g., Internet) and provides the means for acquiring information in all of its forms.

1. As a product –

• It delivers the computing potential across networks of Hardware.

• It enables the Hardware to deliver the expected functionality.
• It acts as an information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.

2. As a vehicle for delivering a product –

• It provides system functionality (e.g., payroll system)

• It controls other software (e.g., an operating system)
• It helps build other software (e.g., software tools)

SOFTWARE
Software
Software is
(1) instructions (computer programs) that when executed provide desired
function and performance,
(2) data structures that enable the programs to adequately manipulate
information, and++
(3) documents that describe the operation and use of the programs.
Software Characteristics
To gain an understanding of software (and ultimately an understanding of
software engineering), it is important to examine the characteristics of software that
make it different from other things that human beings build.
Software is a logical rather than a physical system element.
Therefore, software has characteristics that are considerably different than those
of hardware:

❖ Functionality.
❖ Usability (User-friendly)
❖ Efficiency.
❖ Flexibility.
❖ Reliability.
❖ Maintainability.
❖ Portability.
❖ Integrity.
Functionality
The functionality of software refers to its ability to perform and function
according to design specification.
In simple terms, software systems should function correctly, i.e. perform all the
functions for which they are designed.
The functions refer to the features that the end user as well as the business
expect as basic facilities from the system.
All these functions must be integrated into the system. Many software
applications out there are designed for simplicity, but ultimately, the purpose of
software is to provide its users with the desired functionality.
In order to look like the best software product, it must have a clear appearance,
components, and functions. However, there are also those products out there that can
provide a great deal of value for your money.
Usability (User-friendly)
The user-friendliness of the software is characterized by its ease of use. In other
words, learning how to use the software should require less effort or time.
Navigating the software is extremely important since it helps determine the
journey the user takes within the software.
This is imperative to ensuring visitors remain on your website and have a
positive experience, which leads to an increase in sales and brand loyalty.
Efficiency
Essentially, it refers to the software’s ability to utilize human and system
resources such as time, effort, CPU, memory, computation power, network bandwidth,
files, databases, etc., as effectively and efficiently as possible.
 For a software project to succeed, efficiency is crucial. In addition to meeting
the needs for which the software was made, it must also provide excellent features
designed to assist users in completing their tasks faster.
Software should make efficient use of storage space and execute commands
according to timing requirements.
Flexibility
Software Flexibility refers to the ability of the software solution to adapt to
potential or future changes in its requirements.
When evaluating the flexibility of software, look at how simple it is to add,
modify, or remove features without interfering with the current operation.
It is essential to keep up with rapidly changing markets, technologies, and
customer needs. In software development, change is inevitable; it can arise during the
development process itself or as the result of future requirements.
Flexibility is therefore highly valued. Consequently, any software product must
be scalable, flexible, and easily adaptable to future technology.
When designing or building a software product, be sure to plan for these
changes that are inevitably going to occur.
Loose coupling of components is the key to creating highly flexible systems.
Reliability
The reliability of a software product describes the likelihood it will operate
without failure over a specified period of time under certain conditions.
It determines the ability of software to maintain its level of performance
(provide desired functionality) under specified conditions for a specified period of
time. Generally speaking, software reliability is measured as the availability of the
software.
The value should not be less than 99%. In reliability testing, the goal is not
perfection, but achieving a level of reliability that is acceptable before a software
product is released to customers.
MTTF, MTTR, MTBR, etc., are some reliability metrics that can be used to
quantify the reliability of a software product.
Maintainability
Maintainability refers to how easily you can repair, improve and comprehend
software code.
In some ways, maintaining is similar to being flexible. Maintainability deals
with the modification of errors and minor alterations to software code, while
flexibility focuses on major functional extensions. It also involves maintaining the
services and functionality of the software.
Most of the time, developers are not the ones who maintain the software.
Therefore, good documentation is crucial, which includes code documentation,
interface definitions, etc.
 Maintainability of software products is affected by the quality of the
documentation.
Typically, more than half of development budgets are spent on software
maintenance.
Maintenance should therefore be integrated into the development lifecycle for
effective software maintenance.
Portability
Software portability is a critical factor that cannot be ignored. Portability refers
to the ability to use software in different environments.
This is the ease with which software can be ported from one platform to
another without (or with minimal) changes, while obtaining similar results.
As simple as it may sound, it refers to the ability of software to work on
different hardware platforms without any (or little) modifications needed.
Furthermore, you should be aware that porting software to a new environment
is comparatively cheaper than developing an equivalent application from scratch.
There can be no doubt that portability is a crucial aspect of reducing
development costs.
Integrity
There are multiple interpretations of software integrity. Some people tend to
associate integrity with security, believing it is resistant to hacks and privacy
violations.
To others, high integrity means that the software cannot be modified without
authorization.
Integrity is key for demonstrating the safety, security, and maintainability of
your software.
In addition, software that needs to be compliant with industry regulations and
coding standards requires high code integrity.
Achieving software integrity can be difficult. Yet, with the right practices to
improve safety, security, and maintainability, the challenge can be easily overcome.
In these days of increased security threats, all software must include this factor.

THE CHANGING NATURE OF SOFTWARE

Nowadays, seven broad categories of computer software present continuing

challenges for software engineers .which is given below:
System Software:
System software is a collection of programs which are written to service other
programs.
Some system software processes complex but determinate, information
structures.
 Other system application process largely indeterminate data. Sometimes
when, the system software area is characterized by the heavy interaction with
computer hardware that requires scheduling, resource sharing, and sophisticated
process management.
Application Software:
Application software is defined as programs that solve a specific business
need.
Application in this area process business or technical data in a way that
facilitates business operation or management technical decision making.
In addition to convention data processing application, application software is
used to control business function in real time.
Engineering and Scientific Software:
This software is used to facilitate the engineering function and task. however
modern application within the engineering and scientific area are moving away from
the conventional numerical algorithms.
Computer-aided design, system simulation, and other interactive applications
have begun to take a real-time and even system software characteristic.
Embedded Software:
Embedded software resides within the system or product and is used to
implement and control feature and function for the end-user and for the system itself.
Embedded software can perform the limited and esoteric function or provided
significant function and control capability.
Product-line Software:
Designed to provide a specific capability for use by many different customers,
product line software can focus on the limited and esoteric marketplace or address
the mass consumer market.
Web Application:
It is a client-server computer program which the client runs on the web
browser.
In their simplest form, Web apps can be little more than a set of linked
hypertext files that present information using text and limited graphics.
However, as e-commerce and B2B application grow in importance.
Web apps are evolving into a sophisticate computing environment that not
only provides a standalone feature, computing function, and content to the end user.
Artificial Intelligence Software:
Artificial intelligence software makes use of a non numerical algorithm to
solve a complex problem that is not amenable to computation or straightforward
analysis.
Application within this area includes robotics, expert system, pattern
recognition, artificial neural network, theorem proving and game playing.
It makes use of non numerical algorithms to solve complex problems that are
not amenable to computations or straightaway analysis.
 Applications within this area include robotics, expert systems pattern
recognition, artificial neural networks, theorem proving and game playing. 8.
Ubiquitous computing
The rapid growth of wireless networking may soon lead to true distributed
computing.
The challenge for software engineers will be develop systems and application
software that will allow small devices, personal computers and enterprise system to
communicate across vast network.
Net sourcing
The www is rapidly becoming a computing engine as well as content provider.
The challenge for software engineers is to architect simple and sophisticated
applications that provide benefit to target end user markets worldwide.
Open source
The challenge for software engineers to build source code that is self
descriptive but more importantly to develop techniques that will enable both
customers and developers to know what changes have been made and how those
changes manifest themselves within the software.
The new economy
The dot-com insanity that gripped financial markets during the late 1990s and
the bust that followed in the early 2000s have lead many business people to believe
that the new economy is dead.
The new economy is alive and well but it will evolve slowly.
It will be characterized by mass communication and distribution.
The challenge for software engineers is to build applications that will facilitate
mass communication and mass product distribution using concepts that are only now
forming.

LEGACY SOFTWARE

Hundreds of thousands of computer programs fall into one of the seven

broads application domains – system software, application software, engineering
/scientific software, embedded software, product software, web apps and AI
applications.
A legacy system is any outdated computing system, hardware or software that
is still in use.
Legacy systems include computer hardware, software applications, file
formats and programming languages.
However, not all legacy systems are obsolete technologies. Most legacy
systems work even if they are outdated, and enterprises will often continue using
legacy systems that are critical to their daily functions and business needs.
The Quality Of Legacy Software
There is one additional characteristic that can be present in legacy software –
“poor quality”.
Legacy system sometimes have inextensible designs, convoluted code, poor or
nonexistent documentation, test cases and results that were never archived, a poorly
managed change history – the list can be quite long.
The legacy system must undergo some significant change.
If the legacy meets the needs of its users and runs reliably, it isn’t broken and
does not need to be fixed.
The legacy systems often evolve for one or more of the following reasons:
❖ The software must be adopted to meet the needs of new computing
environments or technology.
❖ The software must be enhanced to implement new business
requirements.
❖ The software must be extended to make it interoperable with more
modern systems or databases.
❖ The software must be re-architected to make it viable within a network
environment.
Software Evolution
Regardless of its application domain, size or complexity, computer software
will evolve over time.
Change drives this process and occurs when errors are corrected when the
software is adapted to the new environment, when the customer requests new features
or functions and when the application is reengineered to provide benefit in a modern
context.
The eight laws are:

1. The Law of "Continuing Change" (1974) — An E-type system must be

continually adapted or it becomes progressively less satisfactory
2. The Law of "Increasing Complexity"(1974) — As an E-type system
evolves, its complexity increases unless work is done to maintain or reduce it.
3. The Law of "Self Regulation" (1974) — E-type system evolution processes
are self-regulating with the distribution of product and process measures close
to normal.
4. The Law of "Conservation of Organisational Stability (1980)" - The
average effective global activity rate in an evolving E-type system is invariant
over the product's lifetime[16]
5. The Law of "Conservation of Familiarity" (1980) — As an E-type system
evolves, all associated with it, developers, sales personnel and users, for
example, must maintain mastery of its content and behaviour to achieve
satisfactory evolution. Excessive growth diminishes that mastery. Hence the
average incremental growth remains invariant as the system evolves.[16]
6. The Law of "Continuing Growth" (1980) — The functional content of an E-
type system must be continually increased to maintain user satisfaction over its
lifetime
 7. The Law of "Declining Quality" (1996) — The quality of an E-type system
will appear to be declining unless it is rigorously maintained and adapted to
operational environment changes
8. The Law of "Feedback System" (1996) — E-type evolution processes
constitute multi-level, multi-loop, multi-agent feedback systems and must be
treated as such to achieve significant improvement over any reasonable base[17]

SOFTWARE MYTHS
Software myths – beliefs about software and the process used to build – can be
traced to the earliest days of computing.
Myths have number of attributes that have made them insidious.

Management myths

Managers with software responsibility are often under pressure to maintain

budgets, keep schedules from slipping, and improve quality. Following are the
management myths:
• Myth: We already have a book that’s full of standards and procedures for building
software, won’t that provide my people with everything they need to know?
Reality: The book of standards may very well exist, but isn’t used. Most software
practitioners aren’t aware of its existence. Also, it doesn’t reflect modern software
engineering practices and is also complete.

• Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
Reality: Software development is not a mechanistic process like manufacturing. As
new people are added, people who were working must spend time educating the
newcomers, thereby reducing the amount of time spent on productive development
effort. People can be added but only in a planned and well-coordinated manner.
• Myth: If I decide to outsource3 the software project to a third party, I can just relax
and let that firm build it.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects.

Customer myths
Customer myths lead to false expectations (by the customer) and ultimately,
dissatisfaction with the developer. Following are the customer myths:
• Myth: A general statement of objectives is sufficient to begin writing programs-we
can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts. A
formal and detailed description of the functions, behavior, performance, interfaces,
design constraints, and validation criteria is essential.
• Myth: Project requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change varies
with the time at which it is introduced. When changes are requested during software
design, the cost impact grows rapidly. Resources have been committed and a design
framework has been established. Change can cause heavy additional costs. Change,
when requested after software is in production, can be much more expensive than the
same change requested earlier.
Practitioner’s myths
Practitioners have following myths:
• Myth: Once we write the program and get it to work, our job is done.
Reality: Industry data indicate that between 60 and 80 percent of all effort expended
on software will be expended after it is delivered to the customer for the first time.
• Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the formal technical review.
• Myth: The only deliverable work product for a successful project is the working
program.
Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides a foundation for successful engineering
and, more important, guidance for software support.
• Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating
quality. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
Many software professionals recognize the fallacy of the myths just described.
Regrettably, habitual attitudes and methods foster poor management and technical
practices, even when reality dictates a better approach. Recognition of software
realities is the first step toward formulation of practical solutions for software
engineering.
SOFTWARE ENGINEERING PRACTICE

A software engineer applies engineering practices to software development, and

typically handles the overall system design of the software application.
While some software engineers also handle programming, these engineers
typically hand off the engineered designs to software programmers for coding.
The Essence Of Practice
The essence of software engineering is managing complexity, personnel
resources, time and money and producing useful products.
1.Understanding 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)
Understand The Problem
Who has a stake in the solution to the problem? That is, who are the stake
holders.
What are the unknowns? What data function, features, and behaviors 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?
Has a similar problem been solved?
Can sub problems be defined?
Can you represent a solution in a manner that leads to effective
implementation?
Carry Out The Problem
Does the solution conform to the plan? Is source code traceable to the design
model?
Is each component part of the solution probably correct?
Examine The Result
Is it possible to test each component part of the solution?
Does the solution produce results that conform to the data, functions, features,
and behavior that are required? Has the been validated against all stakeholders
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.

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.

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
(1) 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.

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.”