0% found this document useful (0 votes)
43 views36 pages

Software Engineering: Kamalika Bhowal

Uploaded by

rayobose51
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views36 pages

Software Engineering: Kamalika Bhowal

Uploaded by

rayobose51
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 36

SOFTWARE ENGINEERING

Kamalika Bhowal
What is software engineering?

•A popular definition of software engineering is: “A systematic


collection of good program development practices and techniques”.
•Good program development techniques have resulted from research
innovations as well as from the lessons learned by programmers
through years of programming experience.
•An alternative definition of software engineering is: “An engineering
approach to develop software”.
•Based on these two point of view, we can define software
engineering as follows:

•Software engineering discusses systematic and cost-effective


techniques for software development. These techniques help develop
software using an engineering approach.
Is Software engineering a science or art?
•The classification of software engineering as either a science or an art is
a topic of ongoing debate within the field. There are arguments
supporting both perspectives, and ultimately, it can be seen as a
combination of both.
•On one hand, software engineering can be considered a science because
it follows systematic and structured approaches to problem-solving. It
relies on principles and methodologies that are based on scientific
theories and empirical evidence. There is a strong emphasis on logical
thinking, analysis, and the application of mathematical and
computational concepts to develop reliable and efficient software
systems. Additionally, software engineering involves experimentation,
hypothesis testing, and the use of tools and metrics to measure and
improve software quality.
•On the other hand, software engineering also exhibits artistic elements.
Developing software often requires creativity and innovation in
designing elegant and user-friendly solutions. Software engineers make
choices that involve subjective judgment, such as selecting appropriate
algorithms, designing intuitive user interfaces, or finding creative ways
to optimize performance. There is room for individual expression and
different approaches to problem-solving, much like in traditional art
forms.
•In essence, software engineering encompasses scientific principles and
methodologies, but it also incorporates creativity, problem-solving skills,
and a certain degree of subjective decision-making. It combines
elements of both science and art, making it a unique discipline that
bridges the gap between the two.
Evolution from an Art form to an Engineering Discipline

□ Software engineering principles have evolved over the last sixty years
with contributions from numerous researchers and software
professionals. Over the years, it has emerged from a pure art to a craft,
and finally to an engineering discipline.

□ The early programmers used an ad hoc programming style. This style of


program development is now variously being referred to as exploratory,
build and fix, and code and fix styles.
□ In a build and fix style, a program is quickly developed without
making any specification, plan, or design. The different imperfections
that are subsequently noticed are fixed.
□ The exploratory programming style is an informal style in the sense
that there are no set rules or recommendations that a programmer
has to adhere to—every programmer himself evolves his own
software development techniques solely guided by his own intuition,
experience, whims, and fancies. The exploratory style comes naturally
to all first time programmers.
Evolution Pattern for Engineering Disciplines
□ If we analyze the evolution of software development styles over the
last sixty years, we can easily notice that it has evolved from an
esoteric art form to a craft form, and then has slowly emerged as an
engineering discipline.
□ As a matter of fact, this pattern of evolution is not very different from
that seen in other engineering disciplines. Irrespective of whether it is
iron making, paper making, software development, or building
construction; the evolution of technology has followed strikingly
similar patterns.
□ This pattern of technology development has schematically been
shown in Figure 1.1. It can be seen from Figure 1.1 that every
technology in the initial years starts as a form of art. Over time, it
graduates to a craft and finally emerges as an engineering discipline.
What is Software Crisis?
The term "software crisis" refers to a phenomenon that occurred in the
early days of computer programming when the development of
software systems faced significant challenges and difficulties. It was
coined to describe the widespread problems and shortcomings in
software development projects.

During the early stages of computing, there were high expectations for
the potential of software to automate tasks, improve productivity, and
solve complex problems. However, the development of software
systems proved to be much more challenging than initially anticipated.
The software crisis arose due to several key factors:
•Complexity: Software systems became increasingly complex, with
larger programs and intricate algorithms. Managing this complexity
and ensuring the correct functioning of the software became difficult.
•Cost and Schedule Overruns: Many software projects experienced
significant delays and cost overruns. Developers struggled to
accurately estimate the time and resources required for software
development, leading to project failures and financial losses.
•Quality and Reliability Issues: Software systems frequently suffered
from bugs, errors, and reliability issues. This led to system failures,
data corruption, and even safety risks in critical applications.
•Lack of Methodologies: Initially, there were no well-defined
methodologies or standardized approaches to software development.
This lack of structure contributed to the difficulties in managing
projects effectively and ensuring software quality.
Programs versus Products
•Many toy software is being developed by individuals such as students
for their classroom assignments and hobbyists for their personal use.
•These are usually small in size and support limited functionalities.
Further, the author of a program is usually the sole user of the
software and maintains the code. These toy software therefore
usually lack good user interface and proper documentation.
•Besides these may have poor maintainability, efficiency, and
reliability.
documentsSince these as
such toyusers
software do notmaintenance
manual, have any supporting
manual,
document, design test documents, etc., wecall these toy
program. software a
•In contrast, professional software usually has multiple users and,
therefore, has a good user interface proper user manuals, and good
documentation support. Since a software product has a large number of
users, it is systematically designed, carefully implemented, and thoroughly
tested. In addition, professionally written software usually consists not
only of the program code but also of all associated documents such as
requirements specification documents, design documents, test documents,
users’ manuals, etc.
•A further difference is that professional software is often too large and
complex to be developed by any single individual. It is usually developed by
a group of developers working in a team.
•Professional software is developed by a group of software developers
working together in a team. It is therefore necessary for them to use some
systematic development methodology. Otherwise, they would find it very
difficult to interface and understand each other’s work and produce a
coherent set of documents
Types of Software Development Projects

A software development company is typically structured into a large number


of teams that handle various types of software development projects. These
software development projects concern the development of either software
product or some software service.
Software products and Software Services
• We all know of a variety of software such as Microsoft’s Windows and the Office
suite, Oracle DBMS, software accompanying a camcorder or a laser printer, etc.
• These software are available off-the-shelf for purchase and are used by a
diverse range of customers. These are called generic software products since
many users essentially use the same software.
• When a software development company wishes to develop a generic product, it first
determines the features or functionalities that would be useful to a large cross section
of users.
Software services

•A software service usually involves either development of a customized


software or development of some specific part of a software in an
outsourced mode. A customized software is developed according to the
specification drawn up by one or at most a few customers. These need to
be developed in a short time frame (typically a couple of months), and at
the same time the development cost must be low. Usually, a developing
company develops customized software by tailoring some of its existing
software.
Software services

•In a customized software development project, a large part of the software


is reused from the code of related software that the company might have
already developed. Usually, only a small part of the software that is specific
to some client is developed.
•For example, suppose a software development organization has developed
an academic automation software that automates the student registration,
grading, Establishment, hostel and other aspects of an academic
institution. When a new educational institution requests for developing a
software for automation of its activities, a large part of the existing
software would be reused. However, a small part of the existing code may
be modified to take into account small variations in the required features.
Customized s/w vs Outsourced s/w
Software service can be again categorized into Customized and Outsourced
software.
Customized software is developed according to the specification drawn up by
one or at most a few customers. These need to be developed in a short time
frame (typically a couple of months), and at the same time, the development
cost must be low. Usually, a developing company develops customized
software by tailoring some of its existing software. For example, when an
academic institution wishes to have software that would automate its
important activities such as student registration, grading, and fee collection;
companies would normally develop such software as a customized product.
This means that for developing customized software, the developing
company would normally tailor one of the existing software products that it
might have developed in the past for some other academic institution.
Customized s/w vs Outsourced s/w
Another type of software service is outsourced software. Sometimes, it can
make good commercial sense for a company developing a large project to
outsource some parts of its development work to other companies. The
reasons behind such a decision may be many. For example, a company might
consider the outsourcing option, if it feels that it does not have sufficient
expertise to develop some specific parts of the software; or if it determines
that some parts can be developed cost-effectively by another company.
Since an outsourced project is a small part of some larger projects,
outsourced projects are usually small in size and need to be completed
within a few months or a few weeks of time.
EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT
□ The exploratory program development style refers to an informal
development style where the programmer makes use of his own intuition
to develop a program rather than making use of the systematic body of
knowledge categorized under the software engineering discipline.
□ The exploratory development style gives complete freedom to the
programmer to choose the activities using which to develop software.
□ An exploratory development style can be successful when used for
developing very small programs, and not for professional software.
Summary of the shortcomings of the exploratory
style of software development:
□ The foremost difficulty is the exponential growth of development time and
effort with problem size and large-sized software becomes almost
impossible using this style of development.
□ The exploratory style usually results in unmaintainable code. The reason
for this is that any code developed without proper design would result in
highly unstructured and poor-quality code.
□ It becomes very difficult to use the exploratory style in a team
development environment. In the exploratory style, the development work
is undertaken without any proper design and documentation.
Therefore it becomes very difficult to meaningfully partition the work
among a set of developers who can work concurrently. On the other
hand, team development is indispensable for developing modern
software—most software mandates huge development efforts,
necessitating team effort for developing these. Besides poor quality
code, lack of proper documentation makes any later maintenance of
the code very difficult.
Abstraction
Abstraction refers to the construction of a simpler version of a problem by
ignoring the details. The principle of constructing an abstraction is popularly
known as modeling (or model construction ).
When using the principle of abstraction to understand a complex problem,
we focus our attention on only one or two specific aspects of the problem
and ignore the rest. Whenever we omit some details of a problem to
construct an abstraction, we construct a model of the problem. In every day
life, we use the principle of abstraction frequently to understand a problem
or to assess a situation.
Suppose you are asked to develop an overall understanding of some country. No one in his right mind would
start this task by meeting all the citizens of the country, visiting every house, examining every tree of the
country, etc. You would probably take the help of several types of abstractions to do this. You would possibly
start by referring to and understanding various types of maps for that country. A map, in fact, is an abstract
representation of a country. It ignores detailed information such as the specific persons who inhabit it, houses,
schools, playgrounds, trees, etc. Again, there are two important types of maps—physical and political maps. A
physical map shows the physical features of an area; such as mountains, lakes, rivers, coastlines, and so on. On
the other hand, the political map shows states, capitals, national boundaries, etc. The physical map is an
abstract model of the country and ignores the state and district boundaries. The political map, on the other
hand, is another abstraction of the country that ignores the physical characteristics such as elevation of lands,
vegetation, etc. It can be seen that, for the same object (e.g. country), several abstractions are possible. In each
abstraction, some aspects of the object are ignored. We understand a problem by abstracting out different
aspects of a problem (constructing different types of models) and understanding them. It is not very difficult to
realize that proper use of the principle of abstraction can be a very effective help to master even intimidating
problems.
Decomposition

The decomposition principle advocates decomposing the problem into many small independent parts. The
small parts are then taken up one by one and solved separately. The idea is that each small part would be easy
to grasp and understand and can be easily solved. The full problem is solved when all the parts are solved.

As an example of a use of the principle of decomposition, consider the following. You would understand a book
better when the contents are decomposed (organized) into more or less independent chapters. That is each
chapter focuses on a separate topic, rather than when the book mixes up all topics together throughout all the
pages. Similarly, each chapter should be decomposed into sections such that each section discusses a different
issue. Each section should be decomposed into subsections and so on. If various subsections are nearly
independent of each other, the subsections can be understood one by one rather than keeping on
cross-referencing to various subsections across the book to understand one.
Why study software engineering?
Let us examine the skills that you could acquire from a study of software engineering principles. The following
two are possibly the most important skill you could be acquiring after completing a study of software
engineering:

>>The skill to participate in the development of large software. You can meaningfully participate in a team
effort to develop a large software only after learning the systematic techniques that are being used in the
industry.
>>You would learn how to effectively handle complexity in a software development problem. In particular, you
would learn how to apply the principles of abstraction and decomposition to handle complexity during various
stages in software development such as specification, design, construction, and testing.

Besides the above two important skills, you would also be learning the techniques of software requirements
specification user interface development, quality assurance, testing, project management, maintenance, etc.
EMERGENCE OF SOFTWARE ENGINEERING

Early Computer Programming


Early commercial computers were very slow and too elementary as
compared to today’s standards. Even simple processing tasks took
considerable computation time on those computers. No wonder that
programs at that time were very small in size and lacked sophistication.
Those programs were usually written in assembly languages. Program
lengths were typically limited to about a few hundred of lines of monolithic
assembly code.
High-level Language Programming
Computers became faster with the introduction of semiconductor
technology in the early 1960s. Faster semiconductor transistors replaced the
prevalent vacuum tube-based circuits in a computer. With the availability of
more powerful computers, it became possible to solve larger and more
complex problems. At this time, high-level languages such as FORTRAN,
ALGOL, and COBOL were introduced.
Control Flow-based Design
As the size and complexity of programs kept on increasing, the exploratory
programming style proved to be insufficient. Programmers found it
increasingly difficult not only to write cost-effective and correct programs
but also to understand and maintain programs written by others. To cope
with this problem, experienced programmers advised other programmers to
pay particular attention to the design of a program’s control flow structure.
•In order to help develop programs having good control flow structures, the
flowcharting technique was developed.
Structured programming—a logical extension

A program is called structured when it uses only the sequence, selection,


and iteration types of constructs and is modular.
Structured programs avoid unstructured control flows by restricting the use
of GO-TO statements. Structured programming is facilitated, if the
programming language being used supports single-entry, single-exit program
constructs such as if-then-else, do-while, etc. Thus, an important feature of
structured programs is the design of good control structures.
Data Structure-oriented Design

Computers became even more powerful with the advent of integrated circuits (ICs)
in the early seventies. These could now be used to solve more complex problems.
Software developers were tasked to develop larger and more complicated software.
which often required writing in excess of several tens of thousands of lines of source
code. The control flow-based program development techniques could not be used
satisfactorily any more to write those programs, and more effective program
development techniques were needed.

Using data structure-oriented design techniques, first, a program’s data structures


are designed. The code structure is designed based on the data structure.
Data Flow-oriented Design

As computers became still faster and more powerful with the introduction of very
large-scale integrated (VLSI) Circuits and some new architectural concepts, more
complex and sophisticated software was needed to solve further challenging
problems. Therefore, software developers looked out for more effective
techniques for designing software, and soon data flow-oriented techniques were
proposed.

The functions (also called processes ) and the data items that are exchanged
between the different functions are represented in a diagram known as a data flow
diagram (DFD). The program structure can be designed from the DFD
representation of the problem.
Data Flow-oriented Design
DFD has proven to be a generic technique that is being used to model all types of systems, and not just software systems.
For example, Figure 1.11 shows the data-flow representation of an automated car assembly plant. If you have never
visited an automated car assembly plant, a brief description of an automated car assembly plant would be necessary. In
an automated car assembly plant, there are several processing stations (also called workstations ) that are located
alongside a conveyor belt (also called an assembly line ). Each workstation is specialized to do jobs such as fitting of
wheels, fitting the engine, spray painting the car, etc. As the partially assembled program moves along the assembly line,
different workstations perform their respective jobs on the partially assembled software. Each circle in the DFD model of
Figure 1.11 represents a workstation (called a process o r bubble ). Each workstation consumes certain input items and
produces certain output items. As a car under assembly arrives at a workstation, it fetches the necessary items to be fitted
from the corresponding stores (represented by two parallel horizontal lines), and as soon as the fitting work is complete
passes on to the next workstation.

You might also like