Software Engineering Unit-1

Software Engineering UNIMAK
1
Unit-1
1.0 Introduction
The notion of ‘software engineering’ was first proposed in 1968 at a conference held to discuss
what was then called the ‘software crisis’ (Naur and Randell, 1969). It became clear that
individual approaches to program development did not scale up to large and complex software
systems. These were unreliable, cost more than expected, and were delivered late.
Throughout the 1970s and 1980s, a variety of new software engineering techniques and methods
were developed, such as structured programming, information hiding and object-oriented
development. Tools and standard notations were developed and are now extensively used.
 Software is more than just a program code. A program is an executable code, which
serves some computational purpose. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.
 Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods.
 Software Engineering is an engineering branch associated with development of software
product using well-defined scientific principles, methods and procedures or software
engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the
system after it has gone into use. The outcome of software engineering is an efficient and
reliable software product.

2
1.1 Software Evolution
The process of developing a software product using software engineering principles and methods
is referred to as Software Evolution. This includes the initial development of software and its
maintenance and updates, till desired software product is developed, which satisfies the expected
requirements.
Evolution starts from the requirement gathering process. After which developers create a
prototype of the intended software and show it to the users to get their feedback at the early stage
of the software product development. The users suggest changes, on which several consecutive
updates and maintenance keep on changing too. This process changes to the original software,
till the desired software is accomplished.
Even after the user has the desired software in hand, the advancing technology and the changing
requirements force the software product to change accordingly.
Re-creating software from scratch and to go one-on-one with the requirement is not feasible. The
only feasible and economical solution is to update the existing software so that it matches the
latest requirements.
1.1.1 Software Evolution Laws
1. Static-type (S-type) - This is a software, which works strictly according to defined
specifications and solutions. The solution and the method to achieve it, both are
immediately understood before coding. The s-type software is least subjected to changes

3
hence this is the simplest of all. For example, calculator program for mathematical
computation.
2. Practical-type (P-type)-This is a software with a collection of procedures. This is
defined by exactly what procedures can do. In this software, the specifications can be
described but the solution is not obviously instant. For example, gaming software
3. Embedded-type (E-type) - This Software works closely as the requirement of real-world
environment. This software has a high degree of evolution as there are various changes in
laws, taxes etc. in the real world situations. For example, online trading software.
1.2 Software Paradigm
Software paradigms refer to the methods and steps, which are taken while designing the
software. There are many methods proposed and are implemented. But, we need to see where in
the software engineering concept, these paradigms stand. These can be combined into various
categories, though each of them is contained in one another:
Programming paradigm is a subset of Software design paradigm which is further a subset of
software development paradigm.
1.2.1 Software Development Paradigm
This paradigm is known as software engineering paradigms; where all the engineering concepts
pertaining to the development of software are applied. It includes various researches and
requirement gathering which helps the software product to build. It consists of
 Requirement gathering

4
 Software design
 Programming
1.2.3 Software Design Paradigm
This paradigm is a part of Software Development and includes
 Design
 Maintenance
 Programming
1.2.4 Software Programming Paradigm
This paradigm is related closely to programming aspect of software development. This includes
 Coding
 Testing
 Integration
1.3 Why Software Engineering
The need of software engineering arises because of the high rate of change in user requirements
and environment on which the software is working. Following are some of the needs stated:
 To acquire skills to develop large programs
 Ability to solve complex programming problems and break large projects into smaller
and manageable parts
 Learn techniques of specification, design, interface development, testing, project
management, etc.
 To acquire skills to be a better programmer, higher productivity and better quality
programs

5
1.3.1 Characteristics of good software product
A software product can be judged by what it offers and how well it can be used. This software
product must satisfy the following criteria:
1) Operational
2) Transitional
3) Maintenance
1. Operational
This tells us how well the software works in operations. It can be measured on:
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
2. Transitional
This aspect is important when the software is moved from one platform to another:
 Portability
 Interoperability
 Reusability
 Adaptability
3. Maintenance
This aspect briefs about how well the software has the capabilities to maintain itself in the ever-
changing environment:
 Modularity

6
 Maintainability
 Flexibility
 Scalability
1.4 Software Crisis
 Fail to meet user requirements.
 Frequently crash.
 Expensive.
 Difficult to alter, debug, and enhance.
 Often delivered late.
 Use resources non-optimally
1.4.1 Factors Contributing to Software Crisis
 Larger problems,
 Lack of adequate training in software engineering,
 Increasing skill shortage,
 Low productivity improvements
1.5 Software Engineering Ethics
Like other engineering disciplines, software engineering is carried out within a social and legal
framework that limits the freedom of people working in that area. As a software engineer, you
must accept that your job involves wider responsibilities than simply the application of technical
skills. You must also behave in an ethical and morally responsible way if you are to be respected
as a professional engineer. It goes without saying that you should uphold normal standards of
honesty and integrity. You should not use your skills and abilities to behave in a dishonest way
or in a way that will bring disrepute to the software engineering profession. However, there are
areas where standards of acceptable behavior are not bound by laws but by the more
questionable notion of professional responsibility. Some of these are:

7
1. Confidentiality: You should normally respect the confidentiality of your employers or
clients irrespective of whether or not a formal confidentiality agreement has been signed.
2. Competence: You should not misrepresent your level of competence. You should not
knowingly accept work that is outside your competence.
3. Intellectual property rights: You should be aware of local laws governing the use of
intellectual property such as patents and copyright. You should be careful to ensure that
the intellectual property of employers and clients is protected.
4. Computer misuse: You should not use your technical skills to misuse other people’s
computers. Computer misuse ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious (dissemination of viruses or other
malware).
1.6 Software Life Cycle Models
A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities required
to make a software product transit through its life cycle phases. It also captures the order in
which these activities are to be undertaken. In other words, a life cycle model maps the different
activities performed on a software product from its inception to retirement. Different life cycle
models may map the basic development activities to phases in different ways. Thus, no matter
which life cycle model is followed, the basic activities are included in all life cycle models
though the activities may be carried out in different orders in different life cycle models. During
any life cycle phase, more than one activity may also be carried out. A life cycle model provides
a series of steps to be followed to design and develop a software product efficiently.
1.6.1 The need for a software life cycle model
The development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software product is being
developed by a team there must be a clear understanding among team members about when and
what to do. Otherwise it would lead to chaos and project failure. This problem can be illustrated
by using an example. Suppose a software development problem is divided into several parts and

8
the parts are assigned to the team members. From then on, suppose the team members are
allowed the freedom to develop the parts assigned to them in whatever way they like. It is
possible that one member might start writing the code for his part, another might decide to
prepare the test documents first, and some other engineer might begin with the design phase of
the parts assigned to him. This would be one of the perfect recipes for project failure. Software
life cycle model defines entry and exit criteria for every phase. A phase can start only if its
phase-entry criteria have been satisfied. So without software life cycle model the entry and exit
criteria for a phase cannot be recognized. Without software life cycle models it becomes difficult
for software project managers to monitor the progress of the project.
1.6.2 Types of Life cycle models
Many life cycle models have been proposed so far. Each of them has some advantages as well as
some disadvantages. A few important and commonly used life cycle models are as follows:
1. Waterfall Model
2. Incremental Model
3. Prototyping Model
4. Evolutionary Model
5. Spiral Model
6. Object-oriented model
7. WINWIN Model
1. Waterfall Model
The waterfall model is intuitively the most obvious way to develop software. Though the
waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it
cannot be used in actual software development projects. Thus, this model can be considered to be
a theoretical way of developing software. But all other life cycle models are essentially derived
from the waterfall model. So, in order to be able to appreciate other life cycle models it is
necessary to learn the waterfall model.
The waterfall model is the classical model of software engineering. This model is one of the
oldest models and is widely used in government projects and in many major companies. As this
model emphasizes planning in early stages, it ensures design flaws before they develop. In
addition, its intensive document and planning make it work well for projects in which quality

9
control is a major concern. Waterfall model divides the life cycle into the following phases as
shown below:
2. Incremental Model
Incremental development is based on the idea of developing an initial implementation, exposing
this to user comment and evolving it through several versions until an adequate system has been
developed. Specification, development, and validation activities are inter-leaved rather than
separate, with rapid feedback across activities. Incremental software development, which is a
fundamental part of agile approaches, is better than a waterfall approach for most business, e-
commerce, and personal systems. Incremental development reflects the way that we solve
problems. We rarely work out a complete problem solution in advance but move toward a
solution in a series of steps, backtracking when we realize that we have made a mistake. By
developing the software incrementally, it is cheaper and easier to make changes in the software
as it is being developed.

10
3. Prototyping Model
A prototype is a toy implementation of the system. A prototype usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve using
inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for
example, may produce the desired results by using a table look-up instead of performing the
actual computations. A prototype usually turns out to be a very crude version of the actual
system.
Need for a prototype in software development
There are several uses of a prototype. An important purpose is to illustrate the input data formats,
messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism
for gaining better understanding of the customer’s needs:
 how the screens might look like
 how the user interface would behave
 how the system would produce outputs
Another reason for developing a prototype is that it is impossible to get the perfect product in the
first attempt. Many researchers and engineers advocate that if you want to develop a good

11
product you must plan to throw away the first version. The experience gained in developing the
prototype can be used to develop the final product.
4. Evolutionary Model
It is also called successive versions model or incremental model. At first, a simple working
model is built. Subsequently it undergoes functional improvements & we keep on adding new
functions till the desired system is built.
Applications:
 Large projects where you can easily find modules for incremental implementation. Often
used when the customer wants to start using the core features rather than waiting for the
full software.
 Also used in object oriented software development because the system can be easily
portioned into units in terms of objects.
Advantages:
 User gets a chance to experiment partially developed system
 Reduce the error because the core modules get tested thoroughly.
Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented & delivered.

12
5. Spiral model
The Spiral model of software development is shown below. The diagrammatic representation of
this model appears like a spiral with many loops. The exact number of loops in the spiral is not
fixed. Each loop of the spiral represents a phase of the software process. For example, the
innermost loop might be concerned with feasibility study, the next loop with requirements
specification, the next one with design, and so on. Each phase in this model is split into four
sectors (or quadrants) as shown below. The following activities are carried out during each phase
of a spiral model.

13
First quadrant (Objective Setting)
 During the first quadrant, it is needed to identify the objectives of the phase.
 Examine the risks associated with these objectives.
Second Quadrant (Risk Assessment and Reduction)
 A detailed analysis is carried out for each identified project risk.
 Steps are taken to reduce the risks. For example, if there is a risk that the requirements
are inappropriate, a prototype system may be developed
Third Quadrant (Development and Validation)
 Develop and validate the next level of the product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
 Review the results achieved so far with the customer and plan the next iteration around
the spiral.
 Progressively more complete version of the software gets built with each iteration
around the spiral.
When to use spiral model
The spiral model is called a Meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However, this
model is much more complex than the other models – this is probably a factor deterring its use in
ordinary projects.
6. Object-Oriented Model
Object Oriented Design (OOD) model works around the entities and their characteristics instead
of functions involved in the software system. This design strategy focuses on entities and its
characteristics. The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:

14
 Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company, and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object. In the solution design, attributes are stored as
variables and functionalities are defined by means of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes. This property of OOD is known as inheritance. This
makes it easier to define specific class and to create generalized classes from specific
ones.
 Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
executed
7. WIN-WIN spiral Model
The Win-Win spiral approach is an extension of the spiral approach. The phase in this approach
is same as the phase in the spiral approach. The only difference is that at the time of the
identifying the requirements, the development team and the customer hold discussion and
negotiate on the requirements that need to be included in the current iteration of the software.

15
The approach is called Win-Win because it is a winning situation for the development team and
also for the customer. The customer wins by getting the product that fulfils most of the
requirements while the development team wins by delivering software which is developed with
all the requirements established after negotiations with the customer. The Win-Win approach is
generally used when you have time-bound releases.
1.7 System Engineering
A system is an integrated composite of people, products, and processes that provide a capability
to satisfy a stated need or objective.
Computer systems engineering encompasses software engineering, many products require
development of software as well as specific hardware to run it, example a mobile communication
product etc. Often hardware and software are developed together; hardware simulator is used
during software development.
Systems engineering is a standardized, disciplined management process for development of
system solutions that provides a constant approach to system development in an environment of
change and uncertainty. It also provides for simultaneous product and process development, as
well as a common basis for communication. Systems engineering ensures that the correct
technical tasks get done during development through planning, tracking, and coordinating.

16
1.8 Computer Based System
These are complex systems in which computers play a major role. While complex physical
systems and sophisticated software systems can help people to lead healthier and more enjoyable
lives, reliance on these systems can also result in loss of money, time, and life when these
systems fail. Much of the complexity of these systems is due to integration of information
technology into physical and human activities. Such integration dramatically increases the
interdependencies among components, people, and processes, and generates complex dynamics
not taken into account in systems of previous generations. Engineer’s with detailed
understanding both of the application domain and computer electronics, software, human factors,
and communication are needed to provide a holistic approach to system development so that
disasters do not occur.
1.8.1 Engineering activities
The computer-based systems engineer develops a system within a system; the properties of the
former have pervasive effects throughout the larger system. The computer-based systems consist
of all components necessary to capture, process, transfer, store, display, and manage information.
Components include software, processors, networks, buses, firmware, application-specific
integrated circuits, storage devices, and humans (who also process information). Embedded

17
computer-based systems interact with the physical environment through sensors and actuators,
and also interact with external computer-based systems. The computer-based systems engineer
must have a thorough understanding of the system in which the computer-based system is
embedded, for example an automobile, medical diagnostic system, stock exchange.
1.8.2 Model-based development
Models are necessary in systems engineering as they support interdisciplinary communication,
formalize system definition, improve analysis of trade-offs and decision making, and support
optimization and integration. The use of models can reduce the number of errors in the design
and thus the system, reduce engineering effort, and preserve knowledge for future efforts.
Maintaining models with up-to-date knowledge is a major problem as most systems are not
generated from models, although this should be an industry goal. During the later stages of
system development and testing, significant schedule pressure makes it difficult to keep the
models and manually developed software consistent.

18
1.9 Software Validation and Verification
Verification is the process of determining whether the output of one phase of software
development conforms to that of its previous phase, whereas validation is the process of
determining whether a fully developed system conforms to its requirements specification. Thus
while verification is concerned with phase containment of errors, the aim of validation is that the
final product be error free.
Software validation or, more generally, verification and validation (V&V) is intended to show
that a system both conforms to its specification and that it meets the expectations of the system
requirement of customer. Program testing, where the system is executed using simulated test
data, is the principal of validation technique. Validation may also involve checking processes,
such as inspections and reviews, at each stage of the software process from user requirements
definition to program development.

19
1.10 Software Development Process
A software process is a set of related activities that leads to the production of a software product.
These activities may involve the development of software from scratch in a standard
programming language like Java or C. However, business applications are not necessarily
developed in this way. New business software is now often developed by extending and
modifying existing systems or by configuring and integrating off-the-shelf software or system
components. There are many different software processes but all must include four activities
that are fundamental to software engineering:
 Software specification: The functionality of the software and constraints on its operation
must be defined.
 Software design and implementation: The software to meet the specification must be
produced.
 Software validation: The software must be validated to ensure that it does what the
customer wants.
 Software evolution: The software must evolve to meet changing customer needs
In some form, these activities are part of all software processes. In practice, they are complex
activities in themselves and include sub-activities such as requirements validation, architectural
design, unit testing, etc. There are also supporting process activities such as documentation and
software configuration management. When we describe and discuss processes, we usually talk
about the activities in these processes such as specifying a data model, designing a user interface,
etc., and the ordering of these activities. However, as well as activities, process descriptions may
also include:
1. Products, which are the outcomes of a process activity. For example, the outcome of the
activity of architectural design may be a model of the software architecture.
2. Roles, which reflect the responsibilities of the people involved in the process. Examples
of roles are project manager, configuration manager, programmer, etc.
3. Pre- and post-conditions, which are statements that are true before and after a process
activity has been enacted or a product produced. For example, before architectural design

20
begins, a pre-condition may be that all requirements have been approved by the customer;
after this activity is finished; a post-condition might be that the UML models describing
the architecture have been reviewed.
1.11 System Engineering Hierarchy
System Engineering encompasses a collection of top- down and methods to navigate the
hierarchy illustrated below. The system engineering process usually begins with a “world view”.
That is, the entire business or product domain is examined to ensure that the proper business or
technology context can be established. The world view is refined to focus more fully on a
specific domain of interest. Within a specific domain, the need for targeted system elements is
analyzed. Finally, the analysis, design, and construction of targeted system elements are initiated.
At the top of the hierarchy, a very broad context is established and, at the bottom, detailed
activities, performed by the relevant engineering disciplines are conducted.

Software Engineering Unit-1

More Related Content

What's hot

Similar to Software Engineering Unit-1

Recently uploaded

Software Engineering Unit-1