Bc0049 Slm Unit 02

Software Engineering Unit 2

Sikkim Manipal University Page No.: 8

Unit 2 Software Design Processes

Structure

2.1 Introduction

Objectives

2.2 What is meant by Software Engineering?

Self Assessment Questions

2.3 Definitions of Software Engineering


2.4 The Serial or Linear Sequential Development Model


2.5 Iterative Development Model

2.6 The incremental Development Model


2.7 The Parallel or Concurrent Development Model

2.8 Hacking

2.9 Summary

2.10 Terminal Questions

2.11 Answers to Terminal Questions

2.1 Introduction

Software systems are now omnipresent. Software is used to help run

manufacturing industry, schools, universities, health care, finance and

government. The computational power and sophistication of computers

have increased ever since, while their costs have been reduced

dramatically. The specification, development, management and evolution of

these software systems make up the discipline of software engineering.

The more powerful a computer is the more sophisticated programs it can

run. Even simple software systems have a high inherent complexity so that



engineering principles have to be used in their development. The discipline

of software engineering discusses systematic and cost-effective software

development approaches, which have come out from past innovations and

lessons learnt from mistakes. Software Engineering principles have evolved

over the past fifty years of contributions from numerous researches and

software professionals.

To solve actual problems in an industry setting, a software engineer or a

team of engineers must incorporate a development strategy that

encompasses the process, methods, and tools layers and the generic

phases. This strategy is often referred to as a process model or a software-

engineering paradigm. A process model for software engineering is chosen

based on the nature of the project and application, the methods and tools to

be used, and the controls and deliverables that are required.

In the software development process the focus is on the activities directly

related to production of the software, for example, design coding, and

testing. A development process model specifies some activities that,

according to the model, should be performed, and the order in which they

should be performed.

As the development process specifies the major development and quality

assurance activities that need to be performed in the project, the

development process really forms the core of the software process. The

management process is decided based on the development process. Due to

the importance of development process, various models have been

proposed.

Objectives

Upon Completion of this Unit, you should be able to:

Explain what basically is meant by software engineering.

Know more about Program maintenance.

Know about software product and software process Models.



2.2 What is meant by Software Engineering?

Software Engineering is an engineering discipline whose focus is the cost-

effective development of high-quality software systems. It is a sub discipline

of Computer Science that attempts to apply engineering principles to the

creation, operation, modification and maintenance of the software

components of various systems.

Software engineering is an engineering discipline which is concerned with

all aspects of software production. Software engineering is concerned with

the practicalities of developing and delivering useful software. The cost of

software engineering includes roughly 60% of development costs and 40%

of testing costs. Structured approaches to software development include

system models, notations, rules, design advice and process guidelines.

Coping with increasing diversity, demands for reduced delivery times and

developing trustworthy software are the key challenges facing Software

Engineering.

What is engineering?

Engineering is the application of well-understood scientific methods to the

construction, operation, modification and maintenance of useful devices and

systems.

What is software?

Software comprises the aspects of a system not reduced to tangible

devices. Eg., computer programs and documentation. It is distinguished

from hardware, which consists of tangible devices, and often exists as

collections of states of hardware devices. The boundary between hardware

and software can be blurry, as with firmware and micro code.



Systems

A system is an assemblage of components that interact in some manner

among themselves and, possibly, with the world outside the system

boundary.

We understand systems by decomposing them into

Subsystems

System components.

It is very difficult to separate the software components of a system from the

other components of a system.


1) What is Engineering ?

2) Define Software.

2.3 Definitions of Software Engineering

Software Engineering is the systematic approach to the development,

operation, maintenance and retirement of software. This is the definition as

per IEEE.

According to Bauer, Software Engineering is nothing but the establishment

and use of sound engineering principles in order to obtain economical

software that is reliable and works efficiently on real machines.

There is yet another definition for software engineering. It is the application

of science and mathematics by which the capabilities of computer

equipment are made useful to humans via computer programs, procedures,

and associated documentation. This is by Boehm.

An engineering approach to software engineering is characterized by a

practical, orderly, and measured development of software. The principal aim

of this approach is to produce satisfactory systems on time and within



budget. There is a good reason for tackling the problem of planning,

developing, evaluating and maintaining software using the engineering

approach. Quite simply this approach is needed to avoid chaos in

developing software. The engineering approach is practical because it is

based on proven methods and practices in software development. The

approach is orderly and development can be mapped to fit customer

requirements. Finally, this approach is measured, during each phase,

software metrics are applied to products to gauge quality, cost and reliability

of what has been produced.

Software Maintenance

Maintenance refers to the support phase of software development.

Maintenance focuses on CHANGE associated with error correction,

adaptations required as the software environment evolves, and changes

due to enhancements brought about by changing customer requirements or

improved capability on the part of developers. Four types of maintenance

are typically encountered.

Correction

Even with the best quality assurance activities, it is likely that the customer

will uncover defects in the software. Corrective maintenance changes the

software to correct defects.

Adaption

Overtime, the original environment (e.g., CPU, operating system, business

rules, external product characteristics) for which the software was

developed is likely to change. Adaptive Maintenance results in modification

to the software to accommodate changes to its external environment.

Enhancement

As software is used, the customer/user will recognize additional functions

that will provide benefit. Perfective Maintenance extends the software



beyond its original functional requirements. Developers can also initiate

enhancements by utilizing their experience on similer project and replicating

the same on earlier developed systems.


1. Define Software Engineering ?

2.4 The Serial or Linear Sequential Development Model

This Model also called as the Classic life cycle or the Waterfall model. The

Linear sequential model suggests a systematic sequential approach to

software development that begins at the system level and progresses

through analysis, design, coding, testing, and support. Figure 2.1 shows the

linear sequential model for software engineering Modeled after a

conventional engineering cycle, the linear sequential model has the

following activities:

Fig. 2.1: The linear sequential model

System/Information Engineering and modeling:

Because software is a part of a large system, work begins by establishing

requirements for all system elements and then allocating some subset of

these requirements to software. This system view is essential when

software must interact with other element such as hardware, people and

databases. System engineering and analysis encompasses requirements



gathering at the system level with a small amount of top level design and

analysis. Information engineering encompasses requirements gathering at

the strategic business level and at the business area level.

Software requirement analysis

The requirement gathering process is intensified and focused specifically on

software. To understand the nature of the program to be built, the software

engineer (analyst) must understand the information domain for the software,

as well as required function, behavior, performance and interface.

Requirements for the both system and the software are documented and

reviewed with the customer.

Design

Software design is actually a multistep process that focuses on four distinct

attributes of a program, data structure, software architecture, interface

representations, and procedural (algorithmic) detail. The design process

translates requirements into a representation of the software that can be

assessed for quality before coding begins. Like requirements, the design is

documented and becomes part of the software configuration.

Code Generation

The design must be translated into a machine–readable form. The code

generation step performs this task. If design is performed in a detailed

manner, code generation can be accomplished mechanistically.

Testing

Once code has been generated, program testing begins. The testing

process focuses on the logical internals of the software, ensuring that all

statements have been tested, and on the functional externals; that is,

conducting tests to uncover errors and ensure that defined input will

produce actual results that agree with required results.



Support

Software will undergo change after it is delivered to the customer. Change

will occur because errors have been encountered, because the software

must be adopted to accommodate changes in its external environments or

because the customer requires functional or performance enhancements.

Software maintenance re-applies each of the preceding phases to an

existing program rather than a new one.

A successful software product is one that satisfies all the objectives of the

development project. These objectives include satisfying the requirements

and performing the development within time and cost constraints.

Generally, for any reasonable size projects, all the phases listed in the

model must be performed explicitly and formally.

The second reason is the one that is now under debate. For many projects

the linear ordering of these phases is clearly the optimum way to organize

these activities. However some argue that for many projects this ordering of

activity is unfeasible or suboptimal. Still waterfall model is conceptually the

simplest process model for software development that has been used most

often.

Limitation of the linear sequential model

1. The linear sequential model or waterfall model assumes the requirement

of a system which can be frozen (baseline) before the design begins.

This is possible for systems designed to automate an existing manual

system. But for a new system, determining the requirements is difficult

as the user does not even know the requirements. Hence, having

unchanging requirements is unrealistic for such projects.

2. Freezing the requirements usually requires choosing the hardware

(because it forms a part of the requirement specifications) A large

project might take a few years to complete. If the hardware is selected



early, then due to the speed at which hardware technology is changing ,

it is likely the final software will use a hardware technology on the verge

of becoming obsolete. This is clearly not desirable for such expensive

software systems.

3. The waterfall model stipulates that the requirements be completely

specified before the rest of the development can proceed. In some

situations it might be desirable to first develop a part of the system

completely and then later enhance the system in phases. This is often

done for software products that are developed not necessarily for a

client, but for general marketing, in which case the requirements are

likely to be determined largely by the developers themselves.

4. It is a document driven process that requires formal documents at the

end of each phase. This approach tends to make the process

documentation-heavy and is not suitable for many applications,

particularly interactive application, where developing elaborate

documentation of the user interfaces is not feasible. Also, if the

development is done using fourth generation language or modern

development tools, developing elaborate specifications before

implementation is sometimes unnecessary.

Despite these limitations, the serial model is the most widely used process

model. It is well suited for routine types of projects where the requirements

are well understood. That is if the developing organization is quite familiar

with the problem domain and requirements for the software are quite clear,

the waterfall model or serial model works well.

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 the rapid development is achieved by using



component-based construction. If requirements are clear and well

understood and the project scope is constrained, the RAD process enables

a development team to create a fully functional system within a very short

period of time.

The RAD approach encompasses the following phases:

Business modeling

Here we try to find answers to questions like what information drives the

business process? What information is generated? Who generates it?

Where does the information go? Who processes it? Etc.,

Data modeling: Here the information flow which would have been defined

as part of the business modelling phase is refined into a set of data objects

that are needed to support the business.

Process modeling

The data objects defined in the data modelling 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 reuse, 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.



Drawbacks of the RAD model:

For large but scalable projects, RAD requires sufficient human resources

to create the right number of RAD teams.

RAD requires developers and customers who are committed to the

rapid-fire acitivites necessary to get a system complete in a much

abbreviated time frame. If commitment is lacking from either, 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 a heavy use of new technology or when the

new software requires a high degree of interoperability with existing

computer programs.


1. Explain the drawbacks of the RAD model ?

2.5 Iterative Development Model

The iterative enhance model counters the third limitation of the waterfall

model and tries to combine a benefit of both prototyping and the waterfall

model. The basic idea is that the software should be developed in

increments, each increment adding 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 because testing each increment is likely to be easier

than testing the entire system as in the waterfall model. The increment



models provide feedback to the client i.e., useful for determining the final

requirements of the system.

In the first step of this model, a simple initial implementation is done for a

subset of the overall problem. This subset is one that contains some of the

key aspects of the problem that are easy to understand and implement and

which form a useful and usable system. A project control list is created that

contains, in 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 task from the list, designing the

implementation for the selected task, coding and testing the implementation,

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 integrated until the project control list is empty, at which time the final

implementation of the system will be available. The iterative enhancement

process model is shown in figure 2.2.

Fig. 2.2: The iterative enhancement model

The project control list guides the iteration steps and keeps track of all tasks

that must be done. Based on the analysis, one of the tasks in the list can

include redesign of defective components or redesign of the entire system.

Redesign of the system will occur only in the initial steps. In the later steps,

the design would have stabilized and there is less chance of redesign. Each



entry in the list is a task that should be performed in one step of the iterative

enhancement process and should be completely understood. Selecting

tasks in this manner will minimize the chance of error and reduce the

redesign work. The design and implementation phases of each step can be

performed in a top-down manner or by using some other technique.

One effective use of this type of model is for product development, in which

the developers themselves provide the specifications and therefore have a

lot of control on what specifications go in the system and what stay out.

In a customized software development, where the client has to essentially

provide and approve the specifications, it is not always clear how this

process can be applied. Another practical problem with this type of

development project comes in generating the business contract-how will the

cost of additional features be determined and negotiated, particularly

because the client organization is likely to be tied to the original vendor who

developed the first version. Overall, in these types of projects, this process

model can be useful if the “core” of the applications to be developed is well

understood and the “increments” can be easily defined and negotiated. In

client-oriented projects, this process has the major advantage that the

client’s organization does not have to pay for the entire software together, it

can get the main part of the software developed and perform cost-benefit

analysis for it before enhancing the software with more capabilities.

2.6 The incremental Development Model

The incremental model combines elements of the linear sequential model

with the iterative of prototyping. Figure 2.3 shows the incremental model

applies linear sequences in a staggered fashion as calendar time

progresses. Each linear sequence produces a deliverable “increment” of the

software. For e.g., word processing software developed using the



incremental paradigm might deliver basic file management, editing, and

document production functions in the first increment; more sophisticated

editing and document production capabilities in the second increment;

spelling and grammar checking in the third increment; and advanced page

layout capability in the fourth increment. It should be noted that the process

flow for any increment could incorporate the prototyping paradigm.

Fig. 2.3: The incremental model

When an incremental model is used, the first increment is a core product.

That is, basic requirements are addressed, but many supplementary

features remain undelivered. The customer uses the core product. 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. The incremental process

model is iterative in nature. The incremental model focuses on the delivery

of an operational product with each increment.

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 can be

added to implement the next increment. In addition increments can be

planned to manage technical risks. For e.g.: a major system might require

the availability of new hardware i.e., 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.

Spiral model

This model couples the iterative nature of the prototyping with the controlled

and systematic aspects of the linear sequential model. It provides the

potential for rapid development of incremental versions of the software.

Using the spiral model, software is developed in a series of incremental

releases. During early iterations, the incremental release might be a paper

model or prototype. During later iterations, increasingly more complete

versions of the engineered system are produced.

Usually the spiral model consists of around six task regions or phases.

Customer communication: tasks required to establish effective

communication between developer and customer.

Planning: tasks required to define resources, timelines, and other project-

related information.

Risk analysis: tasks required to assess both technical and management

risks.

Engineering: tasks required to build one or more representations of the

application.

Construction and release: tasks required to construct, test, install and

provide user support. (e.g. documentation and training).



Customer evaluation: tasks required to obtain customer feedback based

on evaluation of the software representations created during the engineering

stage and implemented during the installation stage.

As the evolutionary process begins, the software engineering team moves

around the spiral in a clockwise direction, beginning at the center. The first

circuit around the spiral might result in the development of a product

specification; subsequent circuit passes around the spiral might be used to

develop a prototype and then progressively more spohesticated versions of

the software. Each passes through the planning region resulting in

adjustments to the project plan. Cost and schedule are adjusted based on

feedback derived from customer evaluation. In addition, the project manager

adjusts the planned number of iterations required to complete the software.


1. Explain the Spiral Model.

2.7 The Parallel or Concurrent Development Model

The concurrent process model can be represented schematically as a series

of major technical activities, tasks, and their associated states. For e.g.:, the

engineering activity defined for the spiral model is accomplished by invoking

the following tasks. Prototyping and / or analysis modeling, requirements

specification, and design.

Figure 2.4 shows that it 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. For e.g., early in

a project the customer communication activity has completed its first

iteration and exists in the awaiting Changes State. The analysis activity



(which existed in the none state while initial customer communication was

completed) now makes a transition into the under development state. If the

customer indicates that changes in requirements must be made, the

analysis activity moves from the under development state into the

awaiting changes state.

The concurrent process model defines a series of events that will trigger

transition from state to state for each of the software engineering activities.

For e.g., during early stages of design, an inconsistency in the analysis

model is uncovered. This generates the event analysis model correction,

which will trigger the analysis activity from the done state into the awaiting

Changes State.

Fig. 2.4: One element of concurrent process model



The concurrent process model is often used as the paradigm for the

development of client/server applications. A client/server system is

composed of a set of functional components. When applied to client/server,

the concurrent process model defines activities in two dimensions a system

dimension and component dimension. System level issues are addressed

using three activities, design assembly, and use. The component dimension

addressed with two-activity design and realization. Concurrency is achieved

in two ways; (1) System and component activities occur simultaneously and

can be modeled using the state – oriented approach (2) a typical client

server application is implemented with many components, each of which

can be designed and realized concurrently.

The concurrent process model is applicable to all types of software

development and provides an accurate picture of the current state of a

project. Rather than confining software-engineering activities to a sequence

of events, it defines a net work of activities. Each activity on the network

exists simultaneously with other activities. Events generated within a given

activity or at some other place in the activity network trigger transitions

among the sates of an activity.

Component based development model:

This model incorporates the characteristics of the spiral model. It is

evolutionary in nature, demanding an iterative approach to the creation of

software. However, the component-based development model composes

applications from prepackaged software components called classes.

Classes created in past software engineering projects are stored in a class

library or repository. Once candidate classes are identified, the class library

is searched to determine if these classes already exist. If they do, they are

extracted from the library and reused. If a candidate class does not reside in

the library, it is engineered using object-oriented methods. The first iteration



of the application to be built is then composed using classes extracted from

the library and any new classes built to meet the unique needs of the

application. Process flow then returns to the spiral and will ultimately

re-enter the component assembly iteration during subsequent passes

through the engineering activity.

The component based development model leads to software reuse, and

reusability provides software engineers with a number of measurable

benefits although it is very much dependent on the robustness of the

component library.

2.8 Hacking

The growing dependence of society on software also places tremendous

social responsibilities on the shoulders of software engineers and their

managers. When the software is being used to monitor the health of

patients, control nuclear power plants, apply the breaks in an automobile,

transfer billions of dollars in an instant, launch missiles, or navigate an

airplane, it is not simply good engineering to build reliable software; it is also

the engineer’s ethical responsibilities to do so.

Program defects are not merely inconvenient “bugs” or interesting technical

puzzles to be captured, but potentially serious business-or life-threatening

errors. Building reliable software is technical objective of the software

engineer, but it also has ethical and social implications that must guide the

actions of a serious professional. In this light, “ Hacking”, i.e., inserting “play

full” bugs into programs, creating viruses, writing quick and dirty code just to

meet a schedule or a market window, shipping defective software, and even

shipping software that works but does not meet the agreed upon

specifications is unethical.



2.9 Summary

Software engineering is a discipline that integrates process, methods

and tools for the development of computer software.

The software process models consist of activities, which are involved, in

developing software products. Basic activities are software specification,

development, validation and evolution.

The linear sequential model of the software process considers each

process activity as a separate and discrete phase.

The evolutionary development model such as iterative, increment model

of the software process treats specification, development and validation

as concurrent activities.

2.10 Terminal Questions

1. Explain whether the linear sequential model of the software process is

an accurate reflection of software development activities or not.

2. Giving reason for your answer based on the system being developed

suggest the most appropriate generic software process model which

might be used as a basic for managing the development of the following

systems;

a) a system to control anti-lock barking in a car;

b) a virtual reality system to support software maintenance;

c) a university accounting system which is intended to replace an

existing system;

d) an interactive system which allows railway passenger to find train

times from terminals installed in stations.

3. Which of the software engineering paradigms presented in this chapter

do you think would be most effective? Why?

4. Describe the concurrent development model in your own words.



2.11 Answers to Terminal Questions

1. Refer to section 2.4

2. Refer to sections 2.4 to 2.6

3. Refer to section 2.7

Bc0049 Slm Unit 02

Documents

software development

software engineering

softwareengineering

software professionals

software product

software process models

development process

introduction software