Unit 3

Software Engineering UNIT-1

SOFTWARE PROCESS

Introduction –S/W Engineering Paradigm – life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, object oriented) - system engineering – computer based system – verification – validation – life cycle process – development process –system engineering hierarchy.

1

What is Software?

Software is a set of items or objects

that form a “configuration” that

includes

• programs

• documents

• data ...

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

2

What is Software?

The basic software have following characteristics:

• Software is engineered

• Software doesn’t wear out

• Software is complex


3

software is engineered

• Software is developed or engineered, it is not manufactured in the classical sense.

(Source: Pressman, R. Software Engineering: A Practitioner’s

Approach. McGraw-Hill, 2005) 4

software doesn’t wear out



Software Applications

• system software

• real-time software(application sw)

• business software

• engineering/scientific software

• embedded software

• PC software

• AI software

• WebApps (Web applications)


6

Goals/ Objectives of Software Engineering

• Satisfy user requirements

• High reliability

• Low Maintenance costs

• Delivery on time

• Low production costs

• High Performance

• Ease of use (Source: Pressman, R. Software

Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

7

Software engineering

• Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

• The computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting.

Source2: Wikipedia (Source1: Pressman, R. Software Engineering: A Practitioner’s Approach.

McGraw-Hill, 2005) 8

Cont..

• A systematic approach to the analysis, design, implementation and maintenance of software.

• Software engineering is the engineering discipline through which software is developed. Commonly the process involves finding out what the client wants, composing this in a list of requirements, designing an architecture capable of supporting all of the requirements, designing, coding, testing and integrating the separate parts, testing the whole, deploying and maintaining the software. Programming is only a small part of software engineering.

Source1 : Wikipedia (Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


Cont..

The Software Engineering Body of Knowledge (SWEBOK)

divides software engineering into 10 knowledge areas:

• Software requirements

• Software design

• Software construction

• Software testing

• Software maintenance

• Software configuration management

• Software engineering management

• Software engineering process

• Software engineering tools and methods

• Software quality

Source: Wikipedia (Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


Software Engineering

A Layered Technology


a “quality” focus

process model

methods

tools


11

Process Flow


12

Process Flow Linear process flow executes each of the five

activities in sequence.

An iterative process flow repeats one or more of the

activities before proceeding to the next.

An evolutionary process flow executes the activities

in a circular manner. Each circuit leads to a more

complete version of the software.

A parallel process flow executes one or more

activities in parallel with other activities ( modeling

for one aspect of the software in parallel with

construction of another aspect of the software. ) (Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


S/W Engineering Paradigm or process

• The software development strategy is referred as Software Engineering Paradigm.

• The software development strategy consists of methods, tools, and procedures. There exist various software development strategies or process models.


14

Software Development Models (or) process models

Software Development Models • Water Fall Model • Incremental process model

• Incremental Model • RAD (Rapid Application Development) Model

• Evolutionary Process models: • Spiral Model • WINWIN Spiral Model

• Prototyping model • Object oriented Model

• Each model has its own specific steps for software development . A suitable development model is selected by considering several factors like requirement , application type, application software to be used for development etc (Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


The Waterfall Model (1)

• Sometimes called the classic life cycle • Suggests a systematic, sequential (or linear)

approach to s/w development • The oldest paradigm for s/w engineering • Works best when –

– Requirements of a problem are reasonably well understood

– Well-defined adaptations or enhancements to an existing system must be made

– Requirements are well-defined and reasonably stable


16

The Waterfall Model (2)

Communication project initiation requirements gathering Planning

estimating scheduling tracking

Modeling analysis design

Construction code test Deployment

delivery support feedback

Fig The waterfall model (Source: Pressman, R. Software Engineering: A Practitioner’s Approach.

McGraw-Hill, 2005)

17

Real time example

We can take real life examples for water fall model like automobile companies make cars and bikes. when they are building a car, the requirements are fixed, predefined. There will be no change in the requirements during the process of building a car. Once we complete a stage, we proceed to the next one. If there is any change in requirements come then we have to go back and make those changes. Then we have to change our complete system that requires extra time and extra money. This is a major disadvantage of water fall model.

Some of other examples are:

1. Online event management system.

2. Material resource planning in a manufacturing unit



The Waterfall Model - Problems • Real projects rarely follow the sequential flow

– Accommodates iteration indirectly – Changes can cause confusion

• It is often difficult for the customer to state all requirements explicitly – Has difficulty accommodating the natural uncertainty that exists

at the beginning of many projects

• The customer must have patience – A working version of the program(s) will not be available until late

in the project time-span – A major blunder, if undetected until the working program is

reviewed, can be disastrous

• Leads to “blocking states”


19

Incremental Process Models (1)

Fig 3.2: The incremental model

Project Calendar Time

So

ftw

are

Fu

nc

tio

na

lity

an

d

Fe

atu

res

Communication

Planning

Modeling (analysis, design)

Construction (code, test)

Deployment (delivery, feedback)

increment # 1

increment # 2

increment # n

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

20

Incremental Models (2)

• Combines elements of the waterfall model applied in an iterative fashion

• Each linear sequence produces deliverable “increments” of the software

• The first increment is often a core product

• The core product is used by the customer (or undergoes detailed evaluation)

• Based on evaluation results, a plan is developed for the next increment


21

Incremental Process Models (3)

• The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature

• But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment

• Particularly useful when – Staffing is unavailable

• Increments can be planned to manage technical risks


22

Incremental model example

For Example:

In the diagram above when we work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until it’s complete.


23

RAD(Rapid Application Development)

• Rapid Application Development

• Emphasizes a short development cycle

• A “high speed” adaptation of the waterfall model

• Uses a component-based construction approach

• components or functions are developed in parallel as if they were mini projects.

• May deliver software within a very short time period (e.g. , 60 to 90 days) if requirements are well understood and project scope is constrained


24

The RAD Model

Communication

Planning

Modeling

business modeling

data modeling

process modeling

Construction

component reuse

automatic code

generation

testing

Deployment

integration

delivery

feedback

Construction

component reuse

automatic code

generation

testing

Modeling

business modeling

data modeling

process modeling

Modeling

business modeling

data modeling

process modeling

Construction

component reuse

automatic code

generation

testing

60 – 90 days

Team # 1

Team # 2

Team # n

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005) 25

Advantages and disadvantages Advantages of the RAD model:

• Reduced development time.

• Increases reusability of components

• Quick initial reviews occur

• Encourages customer feedback

• Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

• Depends on strong team and individual performances for identifying business requirements.

• Requires highly skilled developers/designers.

• High dependency on modeling skills

• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

When to use RAD model:

• RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

• It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.


Evolutionary Process Models • Evolutionary Models take the concept of “evolution” into the

engineering paradigm.

• Therefore Evolutionary Models are iterative.

• They are built in a manner that enables software engineers to develop increasingly more complex versions of the software.

• Business and product requirements often change as development proceeds, making a straight-line path to an end product is unrealistic.


The Spiral Model (1) • Couples the iterative nature of prototyping with the

controlled and systematic aspects of the waterfall model

• It provides the potential for rapid development of increasingly more complete versions of the software

• It is a risk-driven process model generator

• It has two main distinguishing features – Cyclic approach

• Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk

– A set of anchor point milestones • A combination of work products and conditions that are attained

along the path of the spiral


The Spiral Model (2)

Communication

Planning

Modeling

Construction Deployment

delivery

feedback

Start

analysis

design

code

test

estimation

scheduling

risk analysis

Fig : A typical spiral model (Source: Pressman, R. Software


29

The Spiral Model (3) • Unlike other process models that end when software

is delivered, the spiral model can be adapted to apply throughout the life of the computer s/w

• The circuits around the spiral might represent – Concept development project – New Product development project – Product enhancement project

• The spiral model demands a direct consideration of technical risks at all stages of the project

Examples of Spiral model • The evolution of Microsoft Operating System,

Compilers and other operating systems.


The Spiral Model - Drawbacks

• 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.


Win Win Spiral Model

• The Win-Win spiral approach is an extension of the spiral approach.

• The phase in this approach is same as the phase in the spiral approach.

• The only difference is that at the time of the identifying the requirements, the development team and the customer hold discussion and negotiate on the requirements that need to be included in the current iteration of the software.

• The approach is called Win-Win because it is a winning situation for the development team and also for the customer. The customer wins by getting the product that fulfils most of the requirements while the development team wins by delivering software which is developed with all the requirements established after negotiations with the customer. The Win-Win approach is generally used when you have time-bound releases.


Win Win spiral model


Prototyping

u i t o

Q u i c k p l a n

C o s t r c i n

f

r t t p e

D e i v y

e a c

o y t Deployment

Delivery

& Feedback Construction

of

prototype

Communication Quick plan

Modeling

Quick design

Fig : The prototyping model (Source: Pressman, R. Software


35

Advantages

1. Iterative process facilitating enhancements.

2. Partial products can be viewed by the customer.

3. Flexibility of the product.

4. Customer satisfaction of the product.


Prototyping - Problems

1. Customers may press for immediate delivery of working but inefficient products

2. The developer often makes implementation compromises in order to get a prototype working quickly

3. No optimal solution.

4. Time consuming if the algorithm used is inefficient.

5. Iterative process continues forever which cannot be stopped at a particular stage.

6. Poorer documentation resulting in difficult maintenance.


The Concurrent Development Model (1)

• Sometimes called concurrent engineering • Can be represented schematically as a series of framework

activities, s/w engineering actions and tasks, and their associated states

• Defines a series of events that will trigger transitions from state to state for each of the s/w engineering activities, actions, or tasks

• Applicable to all types of s/w development • Defines a network of activities • Events generated at one point in the process network trigger

transitions among the states


The Concurrent Development Model (2)

None

Under development

Awaiting changes

Under revision

Done

Under review

Baselined

Represents the state of a software engineering activity or task

Modeling activity



System Engineering

- Computer-based system

- System engineering process

- “Business process” engineering

- Product engineering


Computer-based System


41

Introduction

• Software engineering occurs as a consequence of system engineering

• System engineering may take on two different forms depending on the application domain – “Business process” engineering – conducted when the context of the work

focuses on a business enterprise

– Product engineering – conducted when the context of the work focuses on a product that is to be built

• Both forms bring order to the development of computer-based systems

• Both forms work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system


42

System

• System – A set or arrangement of things so related as to form a unity or organic whole

– A set of facts, principles, rules. etc., … to show a logical plan linking the various parts

– A method or plan of classification or arrangement

– An established way of doing something such as a method or procedure


43

Computer-based System • Defined: A set or arrangement of elements that are organized to accomplish

some predefined goal by processing information

• The goal may be to support some business function or to develop a product that can be sold to generate business revenue

• A computer-based system makes use of system elements

• Elements constituting one system may represent one macro element of a still larger system

• Example – A factory automation system may consist of a numerical control machine, robots,

and data entry devices; each can be its own system

– At the next lower hierarchical level, a manufacturing cell is its own computer-based system that may integrate other macro elements

• The role of the system engineer is to define the elements of a specific computer-based system in the context of the overall hierarchy of systems

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


Computer-based System (continued)

• A computer-based system makes use of the following four system elements that combine in a variety of ways to transform information – Software: computer programs, data structures, and related work products that

serve to effect the logical method, procedure, or control that is required – Hardware: electronic devices that provide computing capability, interconnectivity

devices that enable flow of data, and electromechanical devices that provide external functions

– People: Users and operators of hardware and software – Database: A large, organized collection of information that is accessed via

software and persists over time

• The uses of these elements are described in the following: – Documentation: Descriptive information that portrays the use and operation of

the system – Procedures: The steps that define the specific use of each system element or the

procedural context in which the system resides


45

System Engineering Process


46

System Engineering Process • The system engineering process begins with a world view; the business or product

domain is examined to ensure that the proper business or technology context can be established

• The world view is refined to focus on a specific domain of interest

• Within a specific domain, the need for targeted system elements is analyzed

• Finally, the analysis, design, and construction of a targeted system element are initiated

• At the world view level, a very broad context is established

• At the bottom level, detailed technical activities are conducted by the relevant engineering discipline (e.g., software engineering)

"Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, and environment in a city plan"


47

System Engineering Hierarchy



Cont..

• Stated in a slightly more formal manner, the world view (WV) is composed of a set of domains (Di), which can each be a system or system of systems in its own right.

WV = {D1, D2, D3, . . . , Dn}

• Each domain is composed of specific elements (Ej) each of which serves some role in accomplishing the objective and goals of the domain or component:

Di = {E1, E2, E3, . . . , Em}

• Finally, each element is implemented by specifying the technical components (Ck) that achieve the necessary function for an element.

Ej = {C1, C2, C3, . . . , Ck}


49

System Modeling (at each view level)

• Defines the processes (e.g., domain classes in OO terminology) that serve the needs of the view under consideration

• Represents the behavior of the processes and the assumptions on which the behavior is based

• Explicitly defines intra-level and inter-level input that form links between entities in the model

• Represents all linkages (including output) that will enable the engineer to better understand the view

• May result in models that call for one of the following – Completely automated solution

– A semi-automated solution

– A non-automated (i.e., manual) approach


50

Factors to Consider when Constructing a Model

• Assumptions – These reduce the number of possible variations, thus enabling a model to reflect

the problem in a reasonable manner

• Simplifications – These enable the model to be created in a timely manner

• Limitations – These help to bound the maximum and minimum values of the system

• Constraints – These guide the manner in which the model is created and the approach taken

when the model is implemented

• Preferences – These indicate the preferred solution for all data, functions, and behavior

– They are driven by customer requirements

Optimization of some of these factors may be mutually exclusive


51

System Modeling with UML

• The Uniform Modeling Language (UML) provides diagrams for analysis and design at both the system and software levels

• Examples

– Use case diagrams

– Activity diagrams

– Class diagrams

– State diagrams


52

53

Different Views

Users Designers Analyzers

54

Use case diagram

Online C2C shopping

• overview the usage requirements • presentations project stakeholders • "the meat" of the actual requirements

Actor

Actor: An actor is a person, organization, or external system that plays a role in one or more interactions with your system

Use case

Use case: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse

System boundary

System boundary: indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not

55

Class Diagram

Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.

Name

Attributes

Operations

Relations

• Associations • Aggregation

• Generalization

56

Sequence Diagram

• A sequence diagram is • An interaction diagram that

details how operations are carried out.

• What messages are sent and when.

• Sequence diagrams are organized according to time

Object: Class

Lifeline

Operations

Message

57

Activities Diagram

Activity diagrams describe the workflow behaviour of a system

Start

Fork

Branch

Merge Joint

End

58

State Machine Diagram

A State Machine diagram

shows the possible states of

the object and the transitions

that cause a change in state.

“Business Process” Engineering


59

Business Process Engineering • “Business process” engineering defines architectures that will enable

a business to use information effectively

• It involves the specification of the appropriate computing architecture and the development of the software architecture for the organization's computing resources

• Three different architectures must be analyzed and designed within the context of business objectives and goals – The data architecture provides a framework for the information needs of

a business (e.g., ERD)

– The application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose

– The technology infrastructure provides the foundation for the data and application architectures • It includes the hardware and software that are used to support the

applications and data


60


61

Product Engineering


62

Product Engineering • Product engineering translates the customer's desire for a set

of defined capabilities into a working product.

• It achieves this goal by establishing a product architecture and a support infrastructure

– Product architecture components consist of people, hardware, software, and data

– Support infrastructure includes the technology required to tie the components together and the information to support the components


63

Cont..

• Requirements engineering elicits the requirements from the customer and allocates function and behavior to each of the four components

• System component engineering happens next as a set of concurrent activities that address each of the components separately

– Each component takes a domain-specific view but maintains communication with the other domains

– The actual activities of the engineering discipline takes on an element view

• Analysis modeling allocates requirements into function, data, and behavior

• Design modeling maps the analysis model into data/class, architectural, interface, and component design

(Source: Pressman, R. Software


64

Product Engineering Hierarchy Product Requirements

Engineering

Hardware Engineering


Database Engineering

Construction

Human Engineering

Analysis Modeling Function

Data and Classes

Behavior

Architectural Design

Interface Design

Component Design

Data/Class Design

Design Modeling

System Component Engineering


65

Verification & Validation

• Verification: "Are we building the product right”. The software should conform to its specification.

• Validation: "Are we building the right product". The software should do what the user really requires.

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach.


The V & V process

• Is a whole life-cycle process - V & V must be applied at each stage in the software process.

• Has two principal objectives

– The discovery of defects in a system;

– The assessment of whether or not the system is useful and useable in an operational


67

V& V goals

• Verification and validation should establish confidence that the software is fit for purpose.

• This does NOT mean completely free of defects.

• Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed.


68

Unit 3

Documents

maintenance of software

basic software

software engineering

engineered software

engineering discipline

application of engineering

practitioners approach

systematic approach