lOMoARcPSD|44595149

Software Engineering study material

system software (University of Calicut)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)
 lOMoARcPSD|44595149

Software Engineering

Unit – I

1.0) Introduction

Software Engineering is concerned with methods, tools and techniques for

developing and managing the process of creating and evolving software products.

The Product is the computer software that software engineers design and build.
The roadmap that we follow to develop a product is called the process. To solve actual
problems, a software engineer must incorporate a development strategy that encompasses
the process, which is referred as process model. The various software process models are

 The Linear Sequential Model

 The Prototyping Model
 The RAD Model
 Evolutionary Software Process Model
 The Incremental Model
 The Spiral Model
 The WINWIN Model
 The Concurrent Development Model

1.1) Objective

The objective of this lesson makes the leaner to know about fundamental concepts
of software engineering. The content of the lesson starts with the product such as
evolution of software, characteristics of software. This lesson also aims the learner to get
the skill on process, process models such as waterfall and Boehm’s Spiral Model.

Towards end of this lesson student can sharpen their skills on software
engineering concepts from the stretch. It also makes them to read the fundamentals of
software engineering concepts.

1.2) Content

1.2.1 The Product

Software engineering is to produce software products. Software system delivered
to a customer with documentation describes how to install and use the system.
Software products fall into two broad classes:
(1) Generic products These are stand-alone systems, which are produced by a
development organization and sold on the open market to any customer who is
able to buy them.

Page 1

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

(2) Bespoke (customized) products these are systems, which are commissioned by a
particular customer. Some contractor develops the software especially for that
customer.
The challenge for software engineers is to produce high-quality software with a
finite amount of resources and to a predicted schedule.
The attributes of a software product are the characteristics displayed by the
product once it is installed and put into use. These are not the services provided by the
product. Rather, they are concerned with the product’s dynamic behaviour and the use
made of the product. Examples of these attributes are therefore efficiency, reliability,
maintainability, robustness, portability, and so on.

The relative importance of these characteristics obviously varies from system to

system. However, the characteristics shown in the Table below are critical quality
attributes, which is the essence of well-engineered software.

Product characteristic Description

Maintainability It should be possible to evolve software to meet the

changing needs of customer.

Dependability Software dependability includes a range of

characteristics including reliability, security and
safety. Dependable software should not cause
physical or economic damage in the event of system
failure.

Efficiency Software should not make wasteful use of system

resources such as memory and processor cycles.

Usability Software should have an appropriate user interface

and adequate documentation.

Optimizing all of these attributes is difficult as some are exclusive. For example,
providing a better user interface may reduce system efficiency. All are subject to the law
of these attributes is not a linear one. Small improvements in any of the attributes can be
expensive. A great deal of effort must be devoted to optimizing a particular attribute.

1.2.1.1 Evolution Of Software

The development of software has passed almost five decades.

In the first era (1950 to mid 1960’s) of computer system evolution, the major
focus was given to hardware. Software was custom designed for each application and
has a relatively limited distribution. Most software was developed and used by the same
person or organizations.

Page 2

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

In the second era (from mid 1960s to the late 1970s), multiprogramming and
multiuser systems were introduced for software applications. Real time systems were
used for process control. Database applications came into practice. Even in second era,
software developed in-house and the size of source code was unmanageable.

The third era (from mid 1970s till now) employs distributed and concurrent
processing in its applications. The need for software development has been increased
because of global and local area networks, high-bandwidth digital communications and
high-speed data access. Low-cost hardware increases the uses of computers now days.

The fourth era in computer software is just beginning. Object oriented

technologies are rapidly displacing more conventional software development approaches
in many application areas. Expert systems and artificial intelligence software solve many
real-world problems. Artificial neural network software has opened exciting possibilities
for pattern recognition and human like information processing abilities.

In the early days of computing, computer-based systems were developed using

hardware-oriented management. Project managers focused on hardware. Technical
standards were used to control hardware cost. Today cost allocated to computer-based
system is mainly to software development.

Also software developed 20 years ago that have undergone 40 generations of

changes and are now unmanageable and unmaintainable. Because even small changes
can cause the entire system fail. Apart from this, internal structure of any software
product is highly critical and hard for understanding. Finally embedded systems (used to
control power plants, air traffic and factories) exhibit strange and some times unexplained
behaviour. This is called “software shock” and software is aging.

Software is instructions (computer programs), data structures that enable the

programs to manipulate information and documents that describe the operation and use of
the programs.

1.2.1.1.1 Software

Software is instructions (computer programs) that when executed provide desired

function and performance, data structures that enable the programs to adequately
manipulate information, and documents that describe the operation and use of the
programs.

1.2.1.1.2 Software Characteristics

Software is a logical rather than a physical system element. The characteristic of

software product is illustrated below.

i) Software is developed or engineered; it is not manufactured in the classical

sense. Although software development resembles hardware manufacturing
process, the quality of software can be easily corrected. Also automated tools
could be used in software factory.

Page 3

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

ii) Software doesn’t wear out. Hardware exhibits high failure rates early in its
life. When defects are corrected, failure rate drops to steady-state level. As time
passes, due to depreciation, dust, vibration, abuse, temperature extremes and
environmental factors, the hardware begins to ware out (Refer Figure 1.1).
Software is not susceptible to the environmental maladies. Therefore, the failure
rate will be low. Undiscovered defects will cause high failure rates early in the life of a
program. However these are corrected and curve flattens to steady state level (Refer
Figure 1.2).
iii) Most software is custom-built, rather than being assembled from existing
components.
Hardware engineer draws the circuit, does some analysis, takes the parts and ICs
and assembles. Where as software reusability is very minimal and the software
development needs to pass through many phases.

Figure 1.1: Hardware Failure curve

Figure 1.2: Software failure curve

1.2.1.1.3 Software Components
Computer software is broadly classified into two forms, non-machine executable
components and machine executable components. This topic focuses only machine-
executable software components.

Page 4

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Software components are created through a series of translations that map

customer requirements to machine executable code. A requirements model (called
prototype) is translated into design. The software design is translated into a language
form that specifies software data structure, procedural attributes and related requirements.
A translator that converts it into machines executable instructions processes the language
form.
Reusability is an important characteristic of high quality software components. In
early days (1960s) scientific subroutine libraries were reused in many applications. But
now classes are reused to create new applications. Today’s interactive interfaces create
graphics windows, pull-down menus and other interactive mechanisms.
Software components are built using a programming language. Machine code,
assembly (machine level) languages, and higher order programming languages are called
the first three generations of computer languages. Languages such as COBOL,
FORTRAN, APL LISP, OPS5, PROLOG, Pascal and C all procedural languages. Over
the past decade, a group of 4GLs (Fourth generation Languages) or non-procedural
languages have been introduced.
1.2.1.1.4 Software Applications
Software may be applied in any situation for which a prespecified set of
procedural steps (i.e., an algorithm) has been defined. Information content and
determinacy are important factors in determining the nature of a software application.
Content refers to the meaning and form of incoming and outgoing information.
Information determinacy refers to the predictability of the order and timing of
information. An engineering analysis program accepts data that have a predefined order,
executes the analysis algorithm(s) without interruption, and produces resultant data in
report or graphical format. Such applications are determinate.
The following software areas indicate the wide range of applications.
a) System Software
System software is a collection of programs written to service other programs.
Examples of system software are compilers, editors, and file management utilities. These
system software process complex, but determinate, information structures other system
applications such as operating system components, drivers, and telecommunication
processors process largely indeterminate data.
b) Real-Time Software
Software that monitors / analyzes / controls real-world events is called real time.
Elements of real time software include.
- a data gathering component to collect and format information.
- an analysis component to transform information as required by the application.
- a control/output component to respond to external environment.
- a monitoring component to control all other components
Real time system differs from interactive or time sharing systems in the way it
responds within strict time constraints.

Page 5

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

c) Business software

Business information processing is the largest single software application area.

Discrete “systems” (e.g., payroll, accounts receivable/payable, inventory) have evolved
into management information system (MIS) software that accesses one or more large
databases containing business information. Applications in this area restructure existing
data in a way that facilitates business operations or management decision-making. In
addition to conventional data processing application, business software applications also
encompass interactive computing (e.g., point-of-sale transaction processing).

d) Engineering and scientific software

Engineering and scientific software have been characterized by “number

crunching” algorithms. Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular biology
to automated manufacturing. However, modern applications within the
engineering/scientific area are moving away from conventional numerical algorithms.
Computer-aided design, system simulation, and other interactive applications have begun
to take on real-time and even system software characteristics.

e) Embedded Software

Embedded software resides in read-only memory and is used to control products

and systems for the consumer and industrial markets. Embedded software is used in Key
Pad Control, Fuel Control, Dashboard Display and Breaking Systems etc.

f) Personal Computer Software

Applications of personal computer software include word processing, Spread

Sheets, Computer Graphics, Entertainment, Data Base Management, Personal and
Business Financial Applications, External Network, and Data Base Access.

g) Web-based software

The Web pages retrieved by a browser are software that incorporates executable
instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a variety of
visual and audio formats). In essence, the network becomes a massive computer
providing an almost unlimited software resource that can be accessed by anyone with a
modem.

h) Artificial Intelligence software

Artificial intelligence (AI) software makes use of nonnumerical algorithms to

complex problems that are not amenable to computation or straightforward analysis.
Expert systems, also called knowledge-based systems, pattern recognition (image and
voice), artificial neural networks, theorem proving, and game playing are representative
of applications within this category.

Page 6

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

1.2.1.1.5 Software Myths

Software myth can be viewed in three dimensions namely

1) Management myths
2) Customer myths
3) Practitioner myths

Management myths. Managers with software responsibility, like managers in most

disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality. Like a drowning person who grasps at a straw, a software manager
often grasps at belief in a software myth, if that belief will lessen the pressure (even
temporarily).

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 is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering prac-
tice? Is it complete? Is it streamlined to improve time to delivery while still maintaining a
focus on quality? In many cases, the answer to all of these questions is "no."

Myth: My people have state-of the-art software development tools; after all, we buy them
the newest computers.

Reality: It takes much more than the latest model mainframe, workstation, or PC to do
high-quality software development. Computer-Aided Software Engineering (CASE) tools
are more important than hardware for achieving good quality and productivity, yet the
majority of software developers still do not use them effectively.

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. In the

words of Brooks, "adding people to a late software project makes it later." At first, this
statement may seem counterintuitive. However, 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 outsource 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.

Page 7

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Customer myths. A customer who requests computer software may be a person at the
next desk, a technical group down the hall, the marketing/sales department, or an outside
company that has requested software under contract. In many cases, the customer
believes myths about software because software managers and practitioners do little to
correct misinformation. Myths lead to false expectations (by the customer) and
ultimately, dissatisfaction with the developer.

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 information domain, function, behavior, performance,
interfaces, design constraints, and validation criteria is essential. These characteristics can
be determined only after thorough communication between customer and developer.
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. If serious attention is given to up-front definition,
early requests for change can be accommodated easily. The customer can review
requirements and recommend modifications with relatively little impact on cost. 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
upheaval that requires additional resources and major design modification, that is,
additional cost. Changes in function, performance, interface, or other characteristics
during implementation (code and test) have a severe impact on cost. Change, when
requested after software is in production, can be over an order of magnitude more
expensive than the same change requested earlier.
1.2.2 The Process
The software process is the set of activities and associated results, which produce
a software product. Software engineers mostly carry out these activities.
There are four fundamental process activities, which are common to all software
processes. The activities are:
(1) Software specification the functionality of the software and constraints on its
operation must be defined.
(2) Software development The software to meet the specification must be
produced.
(3) Software validation The software must be validated to ensure that it does what
the customer wants.
(4) Software evolution The software must evolve to meet changing customer
needs.
Software process is a framework for the tasks that are required to build high-
quality software. A software process defines the approach that is taken as software is
engineered.

Page 8

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

But software engineering also encompasses technologies that populate the

process-technical methods and automated tools. Creative, knowledgeable people who
should work within a defined and mature software process that is appropriate for the
products they build and the demands of their marketplace perform software engineering.

1.2.2.1 The Software Process

A Software process can be characterized as shown in Figure 1.3. A Common

process framework is established by defining a small number of framework activities that
are applicable to all software projects, regardless of their size or complexity. A number
of task sets - each a collection of software engineering work tasks, project milestones,

Figure 1.3 the Software Process

Work products, and quality assurance points - enable the framework activities to
be adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities-such as software quality assurance, software
configuration management, and measurement-overlay the process model. Umbrella
activities are independent of any one-framework activity and occur throughout the
process.
Software engineering practices and establishes five process maturity levels that
are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occasionally even
chaotic. Few processes are defined, and success depends on individual effort.
Level 2: Repeatable. Basic project management processes are established to track cost,
schedule, and functionality. The necessary process discipline is in place to repeat earlier
successes on projects with similar applications
Level 3: Defined. The software process for both management and engineering activities
is documented, standardized, and integrated into an organization wide software process.
All projects use a documented and approved version of the organization’s process for
developing and supporting software. This level includes all characteristics defined for
level 2.

Page 9

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Level 4: Managed. Detailed measures of the software process and product quality are
collected. Both the software process and products are quantitatively understood and
controlled using detailed measures. This level includes all characteristics defined for
level 3.

Level 5: Optimizing. Continuous process improvement is enabled by quantitative

feedback from the process and from testing innovative ideas and technologies. This level
includes all characteristics defined for level 4.

There is no such thing as a ‘right’ or a wrong’ software process. Different

software processes decompose these activities in different ways. The timing of the
activities varies as does the results of each activity. Different organizations use different
processes to produce the same type of product. Different types of product may be
produced by an organization using different processes. However, some processes are
more suitable than others for some types of application. If the wrong process is used, this
will probably reduce the quality or the usefulness of the software product to be developed

Because there are a variety of different process models used, it is impossible to

produce reliable figure for cost distribution across these activities. However, we do know
that modifying software usually takes up more than 60% of total software costs. This
percentage is increasing as more and more software is produced and has to be
maintained. Designing software for change is therefore essential.

Software process (like most business processes) is complex and involves a very
large number of activities. Like products, processes also have attributes or characteristics
such as those shown below.

It is not possible to optimize all process attributes simultaneously. For example, if

a rapid development process is required then it may be necessary to reduce the process
visibility. Making a process visible means producing documents at regular intervals. This
will slow down the process.

Detailed software process models are still the subjects of research but it is now
clear that there are a number of different general models or paradigms of software
development:

(1) The waterfall approach: - This takes the above activities and represents them as
separate process phases such as requirements specification, software design,
implementation, testing and so on. After each stage is defined it is ‘signed-off’
and development goes on to the following stage.
(2) Evolutionary development: - This approach interleaves the activities of
specification, development and validation. An initial system is rapidly developed
from very abstract specifications. This is then refined with customer input to
produce a system, which satisfies the customer’s needs. The system may then be
delivered. Alternatively, it may be re-implemented using a more structured
approach to produce a more robust and maintainable system.

Page 10

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

(3) Formal transformation: - This approach is based on producing a formal

mathematical system specification and transforming this specification, using
mathematical methods, to a program. These transformations are ‘correctness –
preserving’. This means that you can be sure that the developed program meets
its specification.

(4) System assembly from reusable components: - This technique assumes that parts
of the system already exist. The system development process focuses on
integrating these parts rather than developing them from scratch.

The first two of these approaches, namely the waterfall approach and evolutionary
development, are now widely used for practical system development. Some systems
have been built using correctness-preserving transformations but this is still an
experimental process.

1.2.3 Software Engineering Paradigms

Paradigm refers to pattern or model. Software engineering is a discipline for

software development. Before passing on the software engineering model, let us now
define software engineering.

1.2.3.1 Fritz Bauer’s Definition

The establishment and use of sound engineering principles in order to obtain

economically software that is reliable and works efficiently on real machines.

1.2.3.2 Boehm’s Definition

Software Engineering involves the practical application of scientific knowledge to

the design and construction of computer programs and the associated documentation
required to develop, operate and maintain them.

1.2.3.3 IEEE’s Definition

Software Engineering is the systematic approach to the development, operation,

maintenance and retirement of software.
The Primary goals of software engineering are to improve the quality of software
products and to increase the productivity and job satisfaction of software engineers.
Software engineering encompasses a set of three key elements – methods, tools
and procedures as briefly explained below.

Software engineering “methods” provide the technical “how to do’s for building
software”. Methods encompass an array of tasks such as project planning, estimation,
software requirement analysis, design of data structure, program architecture and
algorithm, procedure, coding, testing and maintenance.

Page 11

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Software engineering tools provide automated or semi automated support for

methods. Today, tools exist for all the methods. Computer-Aided Software Engineering
(CASE) tools integrate set of tools for software development. It combines software,
hardware and a software engineering database.

Software engineering procedures hold the methods and tools together to enable
the software development in time. Procedures define the sequence in which methods will
be applied, the documents, reports etc to be delivered the controls that help ensure quality
and coordinate change, and methods to assess progress.

Software engineering is comprised of a set of steps that encompass methods, tools

and procedures discussed above. These steps are often referred to as software
engineering paradigms.

The following sections describe the paradigms in some detail.

1.2.3.4 Waterfall Model

Software Development activity will have several stages wherein one identifies the
problem to be solved, develops a design, writes the code and so on. These activities,
along with a specified order in which they are performed are called a software
development process.

The simplest of such processes (process model as they are called) is the Waterfall
model. It is also called as classic life cycle model or the linear sequential model. The
waterfall model states that the various activities are performed one after the other, in a
linear fashion – akin to the water flowing down in a waterfall.
Typical phases in the waterfall model shown in Figure 1.4 are analysis and
specification, design, coding, testing, integration and maintanance.
(1) Requirements analysis and definition The system’s services, constraints and goals
are established by consultation with system users. Both users and development
staff then define them in a manner, which is understandable.
(2) System and software design The systems design process partitions the
requirements to either hardware or software systems. It establishes an overall
system architecture. Software design involves representing the software system
functions in a form that may be transformed into one or more executable
programs.
(3) Implementation and unit testing During this stage, the software design is realized
as a set of programs or program units. Unit testing involves verifying that each
unit meets its specification.
(4) Integration and system testing The individual program units or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to the
customer.

Page 12

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

(5) Operation and maintenance Normally (although not necessarily) this is the
longest life cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are discovered.

These stages overlap and feed information to each other. During design, problems
with requirements are identified; during coding, design problems are found and so on.
The software process is not a simple linear model but involves a sequence of iterations of
the development activities.

During the final life cycle phase (operation and maintenance) the software is put
into use. Errors and omissions in the original software requirements are discovered.
Program and design errors emerge and the need for new functionality is identified.
Modifications become necessary for the software to remain useful. Making these
changes (software maintenance) may involve repeating some or all-previous process
stages.

Unfortunately, a model, which includes frequent iterations, makes it difficult to

identify definite management checkpoints for planning and reporting. Therefore, after a
small number of iterations, it is normal to freeze parts of the development, such as the
specification, and to continue with the later development stages. Problems are left for
later resolution, ignored or are programmed around. This premature freezing of
requirements may mean that the system won’t do what the user wants. It may also lead to
badly structured system as design problems are circumvented by implementation tricks.

The Waterfall model has some disadvantages, like:

1. It works only for systems designed to automate an existing manual system. For
absolutely new system determining the requirement is difficult, as the user
himself does not know them advance what is being built or finalised at each stage.

2. Freezing the requirements means freezing the hardware. A large project might
take few years to complete, by the time the product is available the hardware
become obsolete.

3. It assumes that requirements are frozen before the rest of development can
proceed. In some situations it might be desirable to first develop a part of the
system completely, and later enhance the system in phases. This is often done for
the software product that are developed not necessarily for a client, but for general
marketing in which case the requirements are likely to be determined largely by
developers themselves.

Page 13

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Figure 1.4 The Software Life Cycle

1.2.3.5 Prototyping

Suppose a customer has not identified the detailed input, processing or output
requirements, or developer may be unsure of the efficiency of an algorithm, operating
system etc, then prototyping approach would be the best approach.

Prototyping is a process that enables the developer to create a model of the

software that must be built. The model can take - a paper prototype, a working prototype
or an existing program that needs to be improved.

The steps of prototyping paradigm are illustrated in Figure – 1.5.

Figure 1.5 Prototyping

Page 14

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Like all other approaches, prototyping begins with requirements gathering.

Developer and customer meet and define the objectives for the software, identify the
requirements and out line the system. The quick design then occurs. Quick design focuses
the input approaches and output formats leading to the construction of the prototype. The
prototype is evaluated by the customer/user and is used to refine requirements for the
software to be-developed. A process of iteration occurs until prototype satisfies the needs
of the customer.

Advantages

Prototyping model is highly advantageous for software requirements specification

by the customer and to understand what is to be done by the developer.

Problems

Prototyping paradigm is also problematic for the following reasons,

It is very difficult to consider the software quality or long-term maintainability.

Because the model iterates many times, customer gets frustrated as the prototype is
rebuilt many times.

The developer often makes implementation compromises in order to get a

prototype working quickly. An inappropriate operating system or an inefficient algorithm
might have been unknowingly used.

Even though problem can occur, since the customer and developer agree the
prototype for defining requirements, prototyping is an effective paradigm for software
engineering.

1.2.3.6 The RAD Model

Rapid application development (RAD) illustrated in Fig1.6 is an incremental

software development process model that emphasizes an extremely short development
cycle. The RAD model is a “high-speed” adaptation of the linear sequential model in
which rapid development is achieved by using component-based construction. If
requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a “fully functional system” within very short time
periods the RAD approach encompasses the following phases.

Business modeling. The information flow among business functions is modeled in a way
that answers the following questions: what information drives the business process?
What information is generated? Who generates it? Where does the information go? Who
processes it?

Data modeling. The information flow defined as part of the business-modeling phase is
refined into a set of data objects that are needed to support the business.

Page 15

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Figure 1.6 The RAD model

The characteristics (called attributes) of each object are identified and the
relationships between these objects defined.

Process modeling. The data objects defined in the data-modeling phase are transformed
to achieve the information flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.

Application generation. RAD assumes the use of fourth generation techniques . Rather
than creating software using conventional third generation programming languages the
RAD process works to reuse existing program components (when possible)
or create reusable components (when necessary). In all cases, automated tools are used to
facilitate construction of the software.

Testing and turnover. Since the RAD process emphasizes re-use, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested and all interfaces must be fully exercised.

Like all process models, the RAD approach has drawbacks:

 For large but scalable projects, RAD requires sufficient human resources to create the
right number of RAD teams.

Page 16

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

 RAD requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much-abbreviated time frame. If
commitment is lacking from either constituency, RAD projects will fail.

 Not all types of applications are appropriate for RAD. If a system cannot be properly
modularized, building the components necessary for RAD will be problematic. If
high performance is an issue and performance is to be achieved through tuning the
interfaces to system components, the RAD approach may not work.
 RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software requires a
high degree of interoperability with existing computer programs.
1.2.4 Evolutionary Software Process Models
i. The Spiral Model

Barry Boehm's spiral model of the lifecycle shows the development of software
over a number of iterations. Two things of significance in this model are

a. that before each cycle of development is undertaken, a risk analysis exercise is

completed, to identify the likelihood of threats to the project's success; to identify
strategies for minimizing these threats and to make contingency plans
b. that activities such as the development of a test plan and the creation of user
documentation can get underway quite early, as soon as a design is in place and
before coding starts

The Spiral model includes the features of both the classic life cycle and
prototyping. Also it adds a new element-risk analysis. The model, represented in the
given Fig1.7, defines four major activities.
1. Planning - to determine objectives, alternatives and
Constraints
2. Risk Analysis - to analyze alternatives and to identify risks
3. Engineering - to develop the product
4. Customer evaluation - to assess the product
With each iteration around the spiral, more complete versions of the software are
built. During the first circuit, objectives, alternatives, and constraints are defined and
risks are identified and analyzed. If risk analysis indicates the uncertainty in
requirements, prototyping may be used in the engineering quadrant to assist the customer
and developer.
The customer evaluates the engineering work and makes suggestions for
modification. Based on the customer input, the next phase of planning and risk analysis
occur. At each loop around the spiral, whether to proceed or not is decided. If risks are
too great the project is terminated.

Page 17

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Figure 1.7 Spiral Model

Advantages
Spiral model is the most realistic approach at present, of the various process
models. It uses prototyping as a risk reduction mechanism and maintains the systematic
stepwise approach suggested by waterfall model.
Problems
Like the other models, Spiral Model is also having problems listed below:
- It may be difficult to convince large customers,
- It demands considerable risk assessment expertise,
- Problems will occur if major -risks is not identified,
- It is a new model and not widely applied.
The spiral model is a realistic approach to the development of large-scale systems
and software. Because software evolves as the process progresses, the developer and
customer better understand and react to risks at each evolutionary level. The spiral model
uses prototyping as a risk reduction mechanism but, more important, enables the devel-
oper to apply the prototyping approach at any stage in the evolution of the product. It
maintains the systematic stepwise approach suggested by the classic life cycle but incor-
porates it into an iterative framework that more realistically reflects the real world. The
spiral model demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be difficult to
convince customers (particularly in contract situations) that the evolutionary approach is
controllable. It demands considerable risk assessment expertise and relies on this
expertise for success. If a major risk is not uncovered and managed, problems will
undoubtedly occur. Finally, the model has not been used as widely as the linear sequential
or prototyping paradigms.

Page 18

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

ii. The Incremental Model

The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping. Referring to Fig1.8, the
incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces a deliverable “increment” of the software.
When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed, but many supplementary features (some known, others
unknown) remain undelivered. The core product is used by the customer (or undergoes
detailed review). As a result of use and/or evaluation, a plan is developed for the next
increment. The plan addresses the modification of the core product to better meet the
needs of the customer and the delivery of additional features and functionality. This
process is repeated following the delivery of each increment, until the complete product
is produced.

Figure 1.8 The Incremental model

The incremental process model is iterative in nature. It focuses on the delivery of
an operational product with each increment. Early increments are stripped down versions
of the final product, but they do provide capability that serves the user and also provide a
platform for evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the
project. Early increments can be implemented with fewer people. If the core product is
well received, then additional staff (if required) can be added to implement the next
increment. In addition, increments can be planned to manage technical risks. For
example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial
functionality to be delivered to end-users without inordinate delay.

Page 19

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

iii. The WINWIN Spiral Model

Boehm’s WINWIN spiral model defines a set of negotiation activities at the

beginning of each pass amount the spiral. Rather than a single customer communication
activity, the following activities are defined:

Figure 1.9 The WINWIN spiral model

1. Identification of the system of subsystem’s key “stakeholders”. A shakeholder is

anyone in the organization that has a direct business interest in the system or
product to be built and will be rewarded for a successful outcome or criticized in
the effort fails.
2. Determination of the stakeholders’ “wins conditions”.
3. Negotiations of the stakeholders win conditions to reconcile them into a set of
win-win conditions for all concerned (including the software project team).
Successful completion of these initial steps achieves a win-win result, which
becomes the key criterion for proceeding to software and system definition. The
WINWIN spiral model is illustrated in Figure 1.9.
iv. The Concurrent Development Model
The concurrent process model can be represented schematically as a series of
major technical activities, tasks, and their associated states. Figure 1.10 provides a
schematic representation of one activity with the concurrent process model. The activity-
analysis-may be in any one of the states noted at any given time. Similarly, other
activities (e.g., design or customer communication) can be represented in an analogous
manner. All activities exist concurrently but reside in different states. In a project the
customer communication activity has completed its first iteration and exists in the
awaiting changes state. If, however, the customer indicates that changes in requirements
must be made, the analysis activity moves from the under development state into the
awaiting changes state.

Page 20

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Figure 1.10 One element of the concurrent process model

The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities.
1.2.5 Fourth - Generation Techniques Model
4GT model allows software developer to use tools to generate source code based
on the specification. 4GT paradigm enables to specify software close to natural language
at faster speed. 4GT paradigm, currently, includes the following tools – non-procedural
languages for data base query, report generation, data manipulation, screen interaction,
code generation, graphics capability and spread sheet capability.

Figure 1.11 4 GT Model

The 4GT paradigm is depicted in Figure – 1.11. Like other paradigms, 4GT
begins with a requirements gathering step. Ideally, the customer would describe
requirements and these would be directly translated into an operational prototype. Since
customer may not know what is required, the developer needs to have a dialogue with the
customer as described in other paradigms.

Page 21

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

For small applications, 4GL (Fourth Generation Language) can be used to

implement requirements without design step. But larger-sized applications require design
strategy to improve quality; maintainability and customer acceptance.
Implementation step makes use of automated tools for generating the necessary
source code. Obviously, a data structure with relevant information must exist and be
readily accessible by the 4GL. To transform a 4GT implementation into a product, the
developer must conduct thorough testing, develop meaningful documentation and
perform other activities.
The term Fourth Generation Techniques (4GT) encompasses a broad array of
software tools that have one thing in common: each enables the software engineer to
specify some characteristic of software at a high level. The tool then automatically
generates source code based on the developer's specification. There is little debate that
the higher the level at which software can be specified to a machine, the faster a program
can be built. The 4GT paradigm for software engineering focuses on the ability to specify
software using specialized language forms or a graphic notation that describes the
problem to be solved in terms that the customer can understand.
Currently, a software development environment that supports the 4GT paradigm
includes some or all of the following tools: nonprocedural languages for database query,
report generation, data manipulation, screen interaction and definition, code generation,
high-level graphics capability, spreadsheet capability, and automated generation of
HTML and similar languages used for Web-site creation using advanced software tools.
Initially, many of the tools noted previously were available only for very specific
application domains, but today 4GT environments have been extended to address most
software application categories.
Like all software engineering paradigms, the 4GT model has advantages and dis-
advantages. Proponents claim dramatic reduction in software development time and
greatly improved productivity for people who build software. Opponents claim that
current 4GT tools are not all that much easier to use than programming languages, that
the resultant source code produced by such tools is "inefficient," and that the
maintainability of large software systems developed using 4GT is open to question.
There is some merit in the claims of both sides and it is possible to summarize the
current state of 4GT approaches:
1. The use of 4GT is a viable approach for many different application areas. Coupled
with Computer-Aided Software Engineering tools and code generators, 4GT
offers a credible solution to many software problems.
2. Data collected from companies that use 4GT indicate that the time required to
produce software is greatly reduced for small and intermediate applications and
that the amount of design and analysis for small applications is also reduced.
3. However, the use of 4GT for large software development efforts demands as
much or more analysis, design, and testing (software engineering activities) to
achieve substantial timesavings that result from the elimination of coding.

Page 22

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

1.2.6 Combining Paradigms

In many applications, all the paradigms discussed need to be combined so that the
strengths of each can be achieved on a single project.
Figure – 1.12 illustrates how software engineering paradigms can be combined
during a single software development effort. Preliminary requirements gathering include
the determination of objectives, alternatives and constraints. From this point, any one of
the paths indicated can be taken. For instance, the classic life cycle steps (for left hand
path) can be followed, if the system can be fully specified at the beginning. If
requirements are uncertain, a prototype can be used to define requirements fully. Using
the prototype as a guide; the developer can then return to the steps of classic life cycle
(design, code and test). Alternatively, the prototype can return to the life cycle paradigm
for testing. 4GTs can be used to implement the prototype or to implement the production
system during the coding step of the life cycle. 4GT can also be used in conjunction with
the spiral model for prototyping or coding steps.
To sum up, the nature of the application determines the choice of paradigm and
how to combine approaches to achieve desired result better.

Figure 1.12 using many paradigms

1.2.7 Product And Process
If the process is weak, the end product will undoubtedly suffer, but an obsessive
overreliance on process is also dangerous. In a brief essay, Margaret Davis comments on
the duality of product and process:

Page 23

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

About every ten years, give or take five, the software community redefines "the
problem" by shifting its focus from product issues to process issues. Thus, we have
embraced structured programming languages (product) followed by structured analysis
methods (process) followed by data encapsulation (product) followed by the current
emphasis on the Software Engineering Institute's Software Development Capability
Maturity Model (process).
While the natural tendency of a pendulum is to come to rest at a point midway
between two extremes, the software community's focus constantly shifts because new
force is applied when the last swing fails. These swings are harmful in and of themselves
because they confuse the average software practitioner by radically changing what it
means to perform the job let alone perform it well. The swings also do not solve "the
problem" for they are doomed to fail as long as product and process are treated as
forming a dichotomy instead of a duality.

There is precedence in the scientific community to advance notions of duality

when contradictions in observations cannot be fully explained by one competing theory
or another. The dual nature of light, which seems to be simultaneously particle and wave,
has been accepted since the 1920's when Louis de Broglie proposed it. I believe that the
observations we can make on the artifacts of software and its development demonstrate a
fundamental duality between product and process. You can never derive or understand the
full artifact, its context, use, meaning, and worth if you view it as only a process or only a
product.
All of human activity may be a process, but each of us derives a sense of self
worth from those activities that result in a representation or instance that can be used or
appreciated either by more than one person, used over and over, or used in some other
context not considered. That is, we derive feelings of satisfaction from reuse of our
products by others or ourselves.
Thus, while the rapid assimilation of reuse goals into software development,
potentially increases the satisfaction software practitioners derive from their work, it also
increases the urgency for acceptance of the duality of product and process. Thinking of a
reusable artifact as only product or only process either obscures the context and ways to
use it or obscures the fact that each use results in product that will, in turn, be used as
input to some other software development activity. Taking one view over the other
dramatically reduces the opportunities for reuse and, hence, loses the opportunity for
increasing job satisfaction.
People derive as much (or more) satisfaction from the creative process as they do
from the end product. An artist enjoys the brush strokes as much the framed result. A
writer enjoys the search for the proper metaphor as much as the finished book. A creative
software professional should also derive as much satisfaction from the process as the end
product.
The work of software people will change in the years ahead. The duality of prod-
uct and process is one important element in keeping creative people engaged as the
transition from programming to software engineering is finalized.

Page 24

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

1.3) Revision Point

Software Engineering
Software engineering is the profession concerned with creating and maintaining software
applications by applying technologies and practices from computer science, project
management, engineering, application domains, and other fields.
The Product
Software engineering is to produce software products. Software system delivered to a
customer with documentation describes how to install and use the system. Software
products fall into two broad classes: they are 1) Generic products 2) Bespoke
(customized) products
Software
Coded instructions that direct the operation of a computer. A set of such instructions for
accomplishing a particular task is referred to as a program.
The Process
The software process is the set of activities and associated results, which produce a
software product. Software engineers mostly carry out these activities. There are four
fundamental process activities, which are 1) Software specification 2) Software
development 3) Software validation 4) Software evolution.
Waterfall Model
The simplest software process is the Waterfall model. It is also called as classic life cycle
model or the linear sequential model. The waterfall model states that the various activities
are performed one after the other, in a linear fashion. Typical phases in the waterfall
model are analysis and specification, design, coding, testing, integration and
maintenance.
Prototyping
Prototyping is a process that enables the developer to create a model of the software that
must be built. The model can take - a paper prototype, a working prototype or an existing
program that needs to be improved.
The RAD Model
Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle. The RAD model is a
“high-speed” adaptation of the linear sequential model in which rapid development is
achieved by using component-based construction.

Spiral model
The Spiral model includes the features of both the classic life cycle and prototyping. Also
it adds a new element-risk analysis. The model, defines four major activities. Planning,
Risk Analysis, Engineering and Customer evaluation

The Incremental Model

The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping.

Page 25

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Time Boxing Model

In time boxing model, development is done iteratively as in the iterative enhancement

model. However, in time boxing model, each iteration is done in a timebox of fixed
duration. The functionality to be developed is adjusted to fit the duration of the timebox.
Moreover, each timebox is divided into a sequence of fixed stages where each stage
performs a clearly defined task (analysis, implementation, and deploy) that can be done
independently. This model also requires that the time duration of each stage is
approximately equal so that pipelining concept is employed to have the reduction in
development time and product releases.

There is a dedicated team for each stage so that the work can be done in pipelining. Thus,
stages should be chosen in such a way that each stage perform some logical unit of work
that becomes the input for next stage.

In addition to the advantages of iterative model, time boxing model has some other
advantages too. Various advantages and disadvantages associated with timeboxing model
are listed in Table.

Table Advantages and Disadvantages of the Time boxing Model

Advantages Disadvantages
1. Speeds up the development process 1. Project management becomes more
and shortens the delivery time complex.

2. Well suited to develop projects with 2. Not suited to projects in which entire
a number of features in short time development work cannot be divided
period. into multiple iterations of almost,
equal duration.

Formal Method Model

Page 26

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

The formal methods model is concerned with the application of a mathematical

technique to design and implement the software. This model lays the foundation for
developing a complex system and supporting the program development. The formal
methods used during the development process provide a mechanism for eliminating
problems, which are difficult to overcome using other software process models. The
software engineer creates formal specifications for this model. These methods minimize
specification errors and this result in fewer errors when the user begins using the system.

Formal methods comprise formal specification using mathematics to specify the desired
properties of the system. Formal specification is expressed in a language whose syntax
and semantics are formally defined. This language comprises a syntax that defines
specific notation used for specification representation; semantic, which uses objects to
describe the system; and a set of relations, which uses rules to indicate the objects for
satisfying the specification.

Generally, the formal method comprises two approaches, namely, property based and
model-based. The property-based specification describes the operations performed on
the system. In addition, it describes the relationship that exists among these operations. A
property-based specification consists of two parts: signatures, which determine the syntax
of operations and an equation, which defines the semantics of the operations through a set
of equations known as axioms. The model-based specification utilizes the tools of set
theory, function theory, and logic to develop an abstract model of the system. In addition,
it specifies the operations performed on the abstract model. The model thus developed is
of a high level and idealized. A model-based specification comprises a definition of the
set of states of the system and definitions of the legal operations performed on the system
to indicate how these legal operations change the current state.

Various advantages and disadvantages associated with a formal method model are listed
in Table.

Table Advantages and Disadvantages of Formal Methods Model

Advantages Disadvantages
1. Discovers ambiguity, 1. Time consuming and expensive.
incompleteness, and inconsistency 2. Difficult to use this model as a
in the software. communication mechanism for non
2. Offers defect-free software. technical personnel.
3. Incrementally grows in effective
solution after each iteration. 3. Extensive training is required since
4. This model does not involve high only few developers have the essential
complexity rate. knowledge to implement this model.

5. Formal specification language

semantics verify self-consistency.

Page 27

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Similarity and differences from Conventional Engineering Process

Similarities:

 Both are getting automated slowly.

 Both require in-depth knowledge of their field.
 Both have fixed work timings most of the time unlike doctors.
 Both are trying to make the world a better place.

Differences:

 Software Engineers have a high starting salary.

 Conventional engineers have higher government sector opportunity.
 Software Engineers have more opportunities of foreign settlement.
 Software Engineer have a typical office job whereas conventional ones have a
more physically active role.

Component Based Development Model

Component-based architecture focuses on the decomposition of the design into individual

functional or logical components that represent well-defined communication interfaces
containing methods, events, and properties. It provides a higher level of abstraction and
divides the problem into sub-problems, each associated with component partitions.

The primary objective of component-based architecture is to ensure component

reusability. A component encapsulates functionality and behaviors of a software element
into a reusable and self-deployable binary unit. There are many standard component
frameworks such as COM/DCOM, JavaBean, EJB, CORBA, .NET, web services, and
grid services. These technologies are widely used in local desktop GUI application design
such as graphic JavaBean components, MS ActiveX components, and COM components
which can be reused by simply drag and drop operation.

Component-oriented software design has many advantages over the traditional object-
oriented approaches such as −

 Reduced time in market and the development cost by reusing existing

components.
 Increased reliability with the reuse of the existing components.

What is a Component?

A component is a modular, portable, replaceable, and reusable set of well-defined

functionality that encapsulates its implementation and exporting it as a higher-level
interface.

Page 28

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

A component is a software object, intended to interact with other components,

encapsulating certain functionality or a set of functionalities. It has an obviously defined
interface and conforms to a recommended behavior common to all components within an
architecture.

A software component can be defined as a unit of composition with a contractually

specified interface and explicit context dependencies only. That is, a software component
can be deployed independently and is subject to composition by third parties.

Views of a Component

A component can have three different views − object-oriented view, conventional view,
and process-related view.

Object-oriented view

A component is viewed as a set of one or more cooperating classes. Each problem

domain class (analysis) and infrastructure class (design) are explained to identify all
attributes and operations that apply to its implementation. It also involves defining the
interfaces that enable classes to communicate and cooperate.

Conventional view

It is viewed as a functional element or a module of a program that integrates the

processing logic, the internal data structures that are required to implement the processing
logic and an interface that enables the component to be invoked and data to be passed to
it.

Process-related view

In this view, instead of creating each component from scratch, the system is building
from existing components maintained in a library. As the software architecture is
formulated, components are selected from the library and used to populate the
architecture.

 A user interface (UI) component includes grids, buttons referred as controls, and
utility components expose a specific subset of functions used in other
components.
 Other common types of components are those that are resource intensive, not
frequently accessed, and must be activated using the just-in-time (JIT) approach.

 Many components are invisible which are distributed in enterprise business

applications and internet web applications such as Enterprise JavaBean (EJB),
.NET components, and CORBA components.

Page 29

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Characteristics of Components

 Reusability − Components are usually designed to be reused in different

situations in different applications. However, some components may be designed
for a specific task.
 Replaceable − Components may be freely substituted with other similar
components.

 Not context specific − Components are designed to operate in different

environments and contexts.

 Extensible − A component can be extended from existing components to provide

new behavior.

 Encapsulated − A A component depicts the interfaces, which allow the caller to

use its functionality, and do not expose details of the internal processes or any
internal variables or state.

 Independent − Components are designed to have minimal dependencies on other

components.

Principles of Component−Based Design

A component-level design can be represented by using some intermediary representation

(e.g. graphical, tabular, or text-based) that can be translated into source code. The design
of data structures, interfaces, and algorithms should conform to well-established
guidelines to help us avoid the introduction of errors.

 The software system is decomposed into reusable, cohesive, and encapsulated

component units.
 Each component has its own interface that specifies required ports and provided
ports; each component hides its detailed implementation.

 A component should be extended without the need to make internal code or

design modifications to the existing parts of the component.

 Depend on abstractions component do not depend on other concrete components,

which increase difficulty in expendability.

 Connectors connected components, specifying and ruling the interaction among

components. The interaction type is specified by the interfaces of the components.

 Components interaction can take the form of method invocations, asynchronous

invocations, broadcasting, message driven interactions, data stream
communications, and other protocol specific interactions.

Page 30

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

 For a server class, specialized interfaces should be created to serve major

categories of clients. Only those operations that are relevant to a particular
category of clients should be specified in the interface.

 A component can extend to other components and still offer its own extension
points. It is the concept of plug-in based architecture. This allows a plugin to offer
another plugin API.

Component-Level Design Guidelines

Creates a naming conventions for components that are specified as part of the
architectural model and then refines or elaborates as part of the component-level model.

 Attains architectural component names from the problem domain and ensures that
they have meaning to all stakeholders who view the architectural model.
 Extracts the business process entities that can exist independently without any
associated dependency on other entities.

 Recognizes and discover these independent entities as new components.

 Uses infrastructure component names that reflect their implementation-specific

meaning.

 Models any dependencies from left to right and inheritance from top (base class)
to bottom (derived classes).

 Model any component dependencies as interfaces rather than representing them as

a direct component-to-component dependency.

Conducting Component-Level Design

Recognizes all design classes that correspond to the problem domain as defined in the
analysis model and architectural model.

 Recognizes all design classes that correspond to the infrastructure domain.

Page 31

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

 Describes all design classes that are not acquired as reusable components, and
specifies message details.

 Identifies appropriate interfaces for each component and elaborates attributes and
defines data types and data structures required to implement them.

 Describes processing flow within each operation in detail by means of pseudo

code or UML activity diagrams.

 Describes persistent data sources (databases and files) and identifies the classes
required to manage them.

 Develop and elaborates behavioral representations for a class or component. This

can be done by elaborating the UML state diagrams created for the analysis model
and by examining all use cases that are relevant to the design class.

 Elaborates deployment diagrams to provide additional implementation detail.

 Demonstrates the location of key packages or classes of components in a system

by using class instances and designating specific hardware and operating system
environment.

 The final decision can be made by using established design principles and
guidelines. Experienced designers consider all (or most) of the alternative design
solutions before settling on the final design model.

Advantages

 Ease of deployment − As new compatible versions become available, it is easier

to replace existing versions with no impact on the other components or the system
as a whole.
 Reduced cost − The use of third-party components allows you to spread the cost
of development and maintenance.

 Ease of development − Components implement well-known interfaces to provide

defined functionality, allowing development without impacting other parts of the
system.

 Reusable − The use of reusable components means that they can be used to
spread the development and maintenance cost across several applications or
systems.

 Modification of technical complexity − A component modifies the complexity

through the use of a component container and its services.

Page 32

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

 Reliability − The overall system reliability increases since the reliability of each
individual component enhances the reliability of the whole system via reuse.

 System maintenance and evolution − Easy to change and update the

implementation without affecting the rest of the system.

 Independent − Independency and flexible connectivity of components.

Independent development of components by different group in parallel.
Productivity for the software development and future software development.

Evolutionary Development Model

Evolutionary model is a combination of Iterative and Incremental model of software

development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial requirements
and architecture envisioning need to be done.

It is better for software products that have their feature sets redefined during development
because of user feedback and other factors. The Evolutionary development model divides
the development cycle into smaller, incremental waterfall models in which users are able
to get access to the product at the end of each cycle.

Feedback is provided by the users on the product for the planning stage of the next cycle
and the development team responds, often by changing the product, plan or process.
Therefore, the software product evolves with time.
All the models have the disadvantage that the duration of time from start of the project to
the delivery time of a solution is very high. Evolutionary model solves this problem in a
different approach.

Page 33

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Evolutionary model suggests breaking down of work into smaller chunks, prioritizing
them and then delivering those chunks to the customer one by one. The number of chunks
is huge and is the number of deliveries made to the customer. The main advantage is that
the customer’s confidence increases as he constantly gets quantifiable goods or services
from the beginning of the project to verify and validate his requirements. The model
allows for changing requirements as well as all work in broken down into maintainable
work chunks.

Application of Evolutionary Model:

1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants
to start using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.

Advantages:

 In evolutionary model, a user gets a chance to experiment partially developed

system.
 It reduces the error because the core modules get tested thoroughly.

Page 34

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

Disadvantages:

 Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.

Iterative Enhancement Model

The iterative enhancement life cycle model counters the third limitation of the waterfall
model and tries to combine the benefits of both prototyping and the waterfall model. The
basic idea is that the software should be developed in increments, where each increment
adds some functional capability to the system until the full system is implemented. At
each step extensions and design modifications can be made. An advantage of this
approach is that it can result in better testing, since testing each increment is likely to be
easier than testing entire system like in the waterfall model. Furthermore, as in
prototyping, the increments provides feedback to the client which is useful for
determining the final requirements of the system.

In the first step of iterative enhancement model, a simple initial implementation is done
for a subset of the overall problem. This subset is the one that contains some of the key
aspects of the problem which are easy to understand and implement, and which forms a
useful and usable system. A project control list is created which contains, in an order, all
the tasks that must be performed to obtain the final implementation. This project control
list gives an idea of how far the project is at any given step from the final system.

Each step consists of removing the next step from the list. Designing the implementation
for the selected task, coding and testing the implementation, and performing an analysis
of the partial system obtained after this step and updating the list as a result of the
analysis. These three phases are called the design phase, implementation phase and
analysis phase. The process is iterated until the project control list is empty, at the time
the final implementation of the system will be available. The process involved in iterative
enhancement model is shown in the figure below.

The Iterative Enhancement Model

The project control list guides the iteration steps and keeps track of all tasks that must be
done. The tasks in the list can be include redesign of defective components found during
analysis. Each entry in that list is a task that should be performed in one step of the
iterative enhancement process, and should be simple enough to be completely
understood. Selecting tasks in this manner will minimize the chances of errors and reduce
the redesign work.

Page 35

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

An iterative life cycle model does not start with a full specification of requirements. In
this model, the development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements. Moreover, in
iterative model, the iterative process starts with a simple implementation of a small set of
the software requirements, which iteratively enhances the evolving versions until the
complete system is implemented and ready to be deployed. Each release of Iterative
Model is developed in a specific and fixed time period, which is called iteration.

Furthermore, this iteration focuses on a certain set of requirements. Each cycle ends with
a usable system i.e., a particular iteration results in an executable release. Iterative Model
allows accessing previous phases, in which the changes are made accordingly. The final
output of the product is revived at the end of the Software Development Life Cycle
(SDLC). Typically iterative development is used in conjunction with incremental
development, in which a longer software development cycle is split into smaller segments
that are built upon each other. Hence, iterative model is used in following scenarios:

 When the requirements of the complete system are clearly defined and
understood.
 The major requirements are defined, while some functionalities and requested
enhancements evolve with the process of the development process.
 A new technology is being used and is being learnt by the development team,
while they are working on the project.
 If there are some high risk features and goals, which might change in the future.
 When the resources with needed skill sets are not available and are planned to be
used on contract basis for specific iterations.

Process of Iterative Model:

The process of Iterative Model is cyclic, unlike the more traditional models that focus on
a rigorous step-by-step process of development. In this process, once the initial planning
is complete, a handful of phases are repeated again and again, with the completion of
each cycle incrementally improving and iterating on the software. Other phases of the
iterative model are described below:

Page 36

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

1. Planning Phase: This is the first stage of the iterative model, where proper
planning is done by the team, which helps them in mapping out the specifications
documents, establish software or hardware requirements and generally prepare for
the upcoming stages of the cycle.
2. Analysis and Design Phase: Once the planning is complete for the cycle, an
analysis is performed to point out the appropriate business logic, database models
and to know any other requirements of this particular stage. Moreover, the design
stage also occurs in this phase of iterative model, where the technical
requirements are established that will be utilized in order to meet the need of
analysis stage.
3. Implementation Phase: This is the third and the most important phase of the
iterative model. Here, the actual implementation and coding process is executed.
All planning, specification, and design documents up to this point are coded and
implemented into this initial iteration of the project.
4. Testing Phase: After the current build iteration is coded and implemented, testing
is initiated in the cycle to identify and locate any potential bugs or issues that may
have been in the software.
5. Evaluation Phase: The final phase of the Iterative life cycle is the evaluation
phase, where the entire team along with the client, examine the status of the
project and validate whether it is as per the suggested requirements.

Advantages of Iterative Model:

It is extremely necessary to know the advantages of the Iterative model, before

implementing it in the Software Development Life Cycle (SDLC). The biggest advantage
of this model is that, it is implemented during the earlier stages of software development
process, which allows developers and testers to find functional or design related flaws as
early as possible, which further allows them to take corrective measures in a limited
budget. Other benefits or advantages of this model are:

Page 37

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)

 lOMoARcPSD|44595149

Software Engineering

 Some working functionality can be developed and early in the software

development life cycle (SDLC).
 It is easily adaptable to the ever changing needs of the project as well as the
client.
 It is best suited for agile organisations.
 It is more cost effective to change the scope or requirements in Iterative model.
 Parallel development can be planned.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily
managed.
 In iterative model less time is spent on documenting and more time is given for
designing.
 One can get reliable user feedback, when presenting sketches and blueprints of
the product to users for their feedback.

Disadvantages of Iterative Model:

Even though, iterative model is extremely beneficial, there are few drawbacks and
disadvantages attached to it, such as, each phase of an iteration is rigid with no overlaps.
Also, system architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle. Other disadvantages of iterative model
are:

 More resources may be required.

 Although cost of change is lesser, but it is not very suitable for changing
requirements.
 More management attention is required.
 It is not suitable for smaller projects.
 Highly skilled resources are required for skill analysis.
 Project progress is highly dependent upon the risk analysis phase.
 Defining increments may require definition of the complete system.

Page 38

Downloaded by Magimai Magimai (magimaimagimai49@gmail.com)