SOFTWARE ENGINEERING

Subject Code : BCS501

MODULE 1
 CHAPTER 1 :

SOFTWARE AND SOFTWARE

ENGINEERING
 Table of Contents

› The Nature of Software

› The Unique nature of Webapps
› Software Engineering
› The Software Process
› Software Engineering Practice
› Software Myths
 Quick Look
What is it? : Computer software is the product that software professionals
build and then support over the long term. Software engineering
encompasses a process, a collection of methods (practice) and an array of
tools that allow professionals to build high quality computer software.

Who does it? : Software engineers build and sup port software, and virtually
everyone in the industrialized world uses it either directly or indirectly.

Why is it important? : Software engineering is important because it enables

us to build complex systems in a timely manner and with high quality.

What are the steps? : You build computer soft ware like you build any
successful product, by applying an agile, adaptable process that leads to a
high-quality result that meets the needs of the people who will use the
product.
 History
Computer software continues to be the single most important technology on the world stage. It is also a
prime example of the law of unintended consequences.

Fifty years ago no one could have predicted:

• that software would become an indispensable technology for business, science, and engineering.
• that software would enable the creation of new technologies (genetic engineering and nanotechnology),
the extension of existing technologies (telecommunications), and the radical change in older technologies
(the printing industry).
• that software would be the driving force behind the personal computer revolution.
• that software would slowly evolve from a product to a service as “on-demand” software companies
deliver just-in-time functionality via a Web browser.
• that a vast software-driven network called the Internet would evolve and change everything from library
research to consumer shopping to political discourse to the dating habits of young (and not so young)
adults.
No one could predict that millions of computer programs would have to be corrected, adapted, and
enhanced as time passed. The burden of performing these “maintenance” activities would absorb more
people and more resources than all work applied to the creation of new software.

As software’s importance has grown, the software community has continually attempted to develop
technologies that will make it easier, faster, and less expensive to build and maintain high-quality computer
programs. Some of these technologies are targeted at a specific application domain (e.g., website design and
implementation); others focus on a technology domain (e.g., object-oriented systems or aspect oriented
programming); and still others are broad-based (e.g., operating systems such as Linux)
 The Nature 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, by a network
of computers that are accessible by local hardware.

Whether it resides within a mobile 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 derived from data acquired from dozens of
independent sources.

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 this time—information. It transforms personal data 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, and provides the means for acquiring information
in all of its forms.

Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose
huge problems for those who must build complex systems.

Teams of software specialists, each focusing on one part of the technology required to deliver a complex
application, have replaced the lone programmer of an earlier era.
Defining Software:

Software is:

(1) instructions (computer programs) that when executed provide desired features, function, and
performance,

(2) data structures that enable the programs to adequately manipulate information, and

(3) descriptive information in both hard copy and virtual forms that describes the operation and use of the
programs.
Software is a logical rather than a physical system element. Therefore, software has characteristics that are
considerably different than those of hardware:

 Software is developed or engineered; it is not manufactured in the classical sense

Although some similarities exist between software development and hardware manufacturing, the two
activities are fundamentally different.

In both activities, high quality is achieved through good design, but the manufacturing phase for hardware
can introduce quality problems that are nonexistent (or easily corrected) for software.

Both activities are dependent on people, but the relationship between people applied and work
accomplished is entirely different.

Both activities require the construction of a “product,” but the approaches are different.
 Software doesn’t “wear out.”

Figure depicts failure rate as a function of time for hardware.

The relationship indicates that hardware exhibits relatively high
failure rates early in its life (these failures are often attributable
to design or manufacturing defects).

Defects are corrected and the failure rate drops to a steady-

state level (hopefully, quite low) for some period of time.

As time passes, however, the failure rate rises again as

hardware components suffer from the cumulative effects of
dust, vibration, abuse, temperature extremes, and many other
environmental maladies.

Stated simply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause
hardware to wear out.

In theory, therefore, the failure rate curve for software should take the form
of the “idealized curve.

Undiscovered defects will cause high failure rates early in the life of a
program. However, these are corrected and the curve flattens.

As changes are made, it is likely that errors will be introduced, causing the
failure rate curve to spike as shown in the “actual curve”. Before the curve
can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again.

However, the implication is clear—software doesn’t wear out. But it does

deteriorate!
 Although the industry is moving toward component-based construction, most software continues to be
custom built.

Standard screws and off-the-shelf integrated circuits are only two of thousands of standard components that
are used by mechanical and electrical engineers as they design new systems. The reusable components have
been created so that the engineer can concentrate on the truly innovative elements of a design, that is, the
parts of the design that represent something new. In the hardware world, component reuse is a natural part
of the engineering process.

A software component should be designed and implemented so that it can be reused in many different
programs. Modern reusable components encapsulate both data and the processing that is applied to the
data, enabling the software engineer to create new applications from reusable parts.
Software Application Domains

Today, seven broad categories of computer software present continuing challenges for software engineers:

• System software: a collection of programs written to service other programs (compilers, editors, and file
management utilities, operating system components, drivers, networking software, telecommunications
processors).

• Application software: stand-alone programs that solve a specific business need. Applications in this area
process business or technical data in a way that facilitates business operations or management/technical
decision making (point-of-sale transaction processing, real-time manufacturing process control).
• Engineering/scientific software: Applications range from astronomy to volcanology, from automotive
stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing.

• Embedded software: resides within a product or system and is used to implement and control features
and functions for the end user and for the system itself (key pad control for a microwave oven, digital
functions in an automobile such as fuel control, dashboard displays, and braking systems).

• Product-line software: designed to provide a specific capability for use by many different customers.
Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or
address mass consumer markets (e.g., word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, and personal and business financial applications).
• Web applications: called “WebApps,” this network-centric software category spans a wide array of
applications. In their simplest form, WebApps can be little more than a set of linked hypertext files that
present information using text and limited graphics. However WebApps are evolving into sophisticated
computing environments that not only provide stand-alone features, computing functions, and content to
the end user, but also are integrated with corporate databases and business applications.

• Artificial intelligence software: makes use of non-numerical algorithms to solve complex problems that
are not amenable to computation or straight-for ward analysis. Applications within this area include robotics,
expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game
playing.
Legacy Software

Some of the software in these categories are state of-the-art software. These older programs—often referred
to as legacy software—have been the focus of continuous attention and concern since the 1960s.

Legacy software systems were developed decades ago and have been continually modified to meet changes
in business requirements and computing platforms. The proliferation of such systems is causing headaches
for large organizations who find them costly to maintain and risky to evolve.

Unfortunately, there is sometimes one additional characteristic that is present in legacy software—poor
quality. Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent
documentation, test cases and results that were never archived, a poorly managed change history.
 The Unique Nature of WebApps
WebApps encounter the following attributes:

• Network intensiveness: A WebApp resides on a network and must serve the needs of a diverse community of
clients.

• Concurrency: A large number of users may access the WebApp at one time. In many cases, the patterns of usage
among end users will vary greatly.

• Unpredictable load: The number of users of the WebApp may vary by orders of magnitude from day to day.

• Performance: If a WebApp user must wait too long, he or she may decide to go elsewhere.

• Availability: Although expectation of 100 percent availability is unreason able, users of popular WebApps often
demand access on a 24/7/365 basis.
• Data driven: The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and
video content to the end user.

• Content sensitive: The quality and aesthetic nature of content remains an important determinant of the quality
of a WebApp.

• Continuous evolution: Unlike conventional application software that evolves over a series of planned,
chronologically spaced releases, Web applications evolve continuously.

• Immediacy: Although immediacy—the compelling need to get software to market quickly—is a characteristic of
many application domains, WebApps often exhibit a time-to-market that can be a matter of a few days or weeks.

• Security: Because WebApps are available via network access, it is difficult, if not impossible, to limit the
population of end users who may access the application. In order to protect sensitive content and provide secure
modes of data transmission.

• Aesthetics: An undeniable part of the appeal of a WebApp is its look and feel.
 Software Engineering
In order to build software that is ready to meet the challenges of the twenty-first century, you must recognize
a few simple realities:
• It follows that a coordinated effort should be made to understand the problem before a software solution
is developed.

• It follows that design becomes a pivotal activity.

• It follows that software should exhibit high quality.

• It follows that software should be maintainable.

These simple realities lead to one conclusion: software in all of its forms and across all of its application
domains should be engineered.
Software engineering is the establishment and use of sound engineering principles in or der to obtain
economically software that is reliable and works efficiently on real machines.
Software engineering is a layered technology.

The foundation for software engineering is the process layer. The software engineering process is the glue that holds the
technology layers together and enables rational and timely development of computer software.

Process defines a framework that must be established for effective delivery of software engineering technology.

Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of
tasks that include communication, requirements analysis, design modeling, program construction, testing, and support.

Software engineering tools provide automated or semi-automated support for the process and the methods.
 The Software Process
A process is a collection of activities, actions, and tasks that are performed when some work product is to be
created.

An activity strives to achieve a broad objective (communication with stakeholders) and is applied regardless
of the application domain, size of the project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.

An action encompasses a set of tasks that produce a major work product (an architectural design model).

A task focuses on a small, but well-defined objective (conducting a unit test) that produces a tangible
outcome.
A process framework establishes the foundation for a complete software engineering process by identifying a small
number of framework activities that are applicable to all software projects, regardless of their size or complexity.

A generic process framework for software engineering encompasses five activities:

• Communication : The intent is to understand stakeholders’ objectives for the project and to gather requirements that
help define software features and functions

• Planning : The map—called a software project plan—defines the software engineering work by describing the
technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule

• Modeling : A software engineer creates models to better understand software requirements and the design that will
achieve those requirements.

• Construction : This activity combines code generation and the testing that is required to uncover errors in the code.

• Deployment : The software is delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation.
Software engineering process framework activities are complemented by a number of umbrella activities.

Umbrella activities are applied throughout a soft ware project and help a software team manage and control
progress, quality, change, and risk.
• Software project tracking and control : allows the software team to assess progress against the project
plan and take any necessary action to maintain the schedule.

• Risk management : assesses risks that may affect the outcome of the project or the quality of the
product.

• Software quality assurance : defines and conducts the activities required to ensure software quality.

• Technical reviews : assesses software engineering work products in an effort to uncover and remove
errors before they are propagated to the next activity.
• Measurement : defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework
and umbrella activities.

• Software configuration management : manages the effects of change throughout the software process.

• Reusability management : defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.

• Work product preparation and production : encompasses the activities required to create work products
such as models, documents, logs, forms, and lists.
 Software Engineering Practice
The Essence of Practice

1. Understand the problem (communication and analysis)

• Who has a stake in the solution to the problem? That is, who are the stake holders?

• What are the unknowns? What data, functions, and features 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?

2. Plan a solution (modeling and software design)

• 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, and features that are required?

• Has a similar problem been solved? If so, are elements of the solution reusable?

• Can sub-problems be defined? 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?
3. Carry out the plan (code generation)
• Does the solution conform to the plan? Is source code traceable to the design model?

• Is each component part of the solution provably correct? Have the design and code been reviewed, or
better, have correctness proofs been applied to the algorithm?

4. Examine the result for accuracy (testing and quality assurance)

• Is it possible to test each component part of the solution? Has a reasonable testing strategy been
implemented?

• Does the solution produce results that conform to the data, functions, and features that are required? Has
the software been validated against all stakeholder requirements?
The General Principles:

The dictionary defines the word principle as “an important underlying law or assumption required in a system
of thought”. David Hooker has proposed seven principles that focus on software engineering practice as a
whole

The First Principle: The Reason It All Exists

A software system exists for one reason: to provide value to its users. All decisions should be made with this
in mind.

The Second Principle: Keep It Simple, Stupid!

Software design is not a haphazard process. There are many factors to consider in any design effort. All design
should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily
maintained system.
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. 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

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

• Design, keeping the implementers in mind. Code with concern for those that must maintain and extend
the system.
The Fifth Principle: Be Open to the Future
• A system with a long lifetime has more value. Never design yourself into a corner. Always ask “what if,” and
prepare for all possible answers by creating systems that solve the general problem, not just the specific one.

The Sixth Principle: Plan Ahead for Reuse

• Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to accomplish in
developing a software system.
• 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!

• 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.
 Software Myths
Software myths—incorrect beliefs about software and the process that is used to build it—can be traced to
the earliest days of computing.

For instance, they appear to be reasonable statements of fact, they have an intuitive feel, and they are often
promoted by experienced practitioners who “know it all.”

Management myths:
• 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?

• If we get behind schedule, we can add more programmers and catch up.

• If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Customer myths :
• A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.

• Software requirements continually change, but change can be easily accommodated because software is
flexible.

Practitioner’s myths :

• Once we write the program and get it to work, our job is done.

• Until I get the program “running” I have no way of assessing its quality.

• The only deliverable work product for a successful project is the working program.

• Software engineering will make us create voluminous and unnecessary documentation and will invariably
slow us down.