Software Engineering: Kamalika Bhowal
Software Engineering: Kamalika Bhowal
Kamalika Bhowal
What is software engineering?
□ 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.
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
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
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.
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.