Introduction to Software Engineering. Software Characteristics Components Applications Layered...

Chapter 1Introduction to Software Engineering

Software Characteristics Components Applications Layered Technologies Processes Methods And Tools Generic View Of Software Engineering Process Models- Waterfall model,

Incremental, Evolutionary process models- Prototype, Spiral And Concurrent Development Model

Topics

Software:== Program +good user interface +

operating procedures+ documentation

Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware

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

2. Software doesn't "wear out.“3. Although the industry is moving toward

component-based assembly, most software continues to be custom built. (reusability of components)

Software Characteristics

Failure curve forHardware Software

Poor quality s/w producedDevelopment team exceeds the budget

Late delivery of s/wUser requirement not completely supported

Difficult to maintain.

Software crisis

System software. Real-time software. Business software Engineering and scientific software Embedded software. Personal computer software. Web-based software. Artificial intelligence software.

Software Applications

1. [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines

2.[IEEE] The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

Software EngineeringDefinition

Improved requirement specification Improved cost and scheduled estimates Improved quality Better use of automated tools Less defects in final products Better maintenance of delivered s/w Well defined processes

Advantages of using S.E.

Process, Methods, Tools / A Layered Technology

The bedrock that supports software engineering is a quality focus.

Quality Focus

The foundation for software engineering is the process layer.

Process defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology.

Process

Software engineering methods provide the technical how-to's for building software.

Methods encompass a broad array of tasks that include requirements analysis,

design, program construction, testing, and support.

Methods

Software engineering tools provide automated or semi-automated support for the process and the methods.

When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

Tools

The work associated with software engineering can be categorized into three generic phases, regardless of application area, project size, or complexity.

1. The definition phase focuses on what.2. The development phase focuses on how.

3.The support phase focuses on change associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements.

A Generic View of Software Engineering

1. Correction: corrective maintenance changes the s/w to correct defects

2. Adaption: Adaptive maintenance in modification of external environment

3. Enhancement: Perfective Maintenance beyond to its original functions

4. Prevention: Preventive Maintenance, s/w reengineering- makes changes for more easiness of above 3 changes

Type of change of SUPPORT PHASE

The phases and related steps described in our generic view of software engineering are complemented by a number of umbrella activities.

Typical activities in this category include:• Software project tracking and control• Formal technical reviews• Software quality assurance• Software configuration management• Document preparation and production• Reusability management• Measurement• Risk management

Cont..

THE SOFTWARE PROCESS

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, 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

Cont…

umbrella activities—such as software quality assurance, software

configuration management, and measurement2—overlay the process model.

Umbrella activities are independent of any one framework activity and occur throughout

the process.

Cont…

Linear. Iterative. Evolutionary. Parallel.

Process Flow

What is a Process … ?

When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks◦ You do not usually

bake a cake before all the ingredients are mixed together We can think of a series of activities as a process The software process is the way we produce

software.

Any process has the following characteristics◦ It prescribes all of the major activities◦ It uses resources and produces intermediate and final

products◦ It may include sub-processes and has entry and exit

criteria◦ The activities are organized in a sequence◦ Constrains or control may apply to activities

(budget control, availability of resources )

Software Processes When the process involves the building of some

product we refer to the process as a life cycle

Software development process – software life cycle

A software process model is an abstract representation of a process

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.

Process model also known as software life cycle models

Software Process Models

The Waterfall Model

Generic Framework

Requirements – defines needed information, function, behavior, performance and interfaces.

Design – data structures, software architecture, interface representations, algorithmic details.

Implementation – source code, database, user documentation, testing.

Waterfall Strengths◦ Easy to understand, easy to use◦ Each phase has well defined inputs & outputs◦ Each stage has well defined deliverable & Milestones.◦ Good for management control (plan, staff, track)◦ Works well when quality is more important than cost or

schedule.

The Waterfall Model

Once the phase x is over then next phase y started. Model is always sequential in nature.

Users have little interaction with the project team. Their feedback is not taken during development.

After the development starts changes cannot be possible easily.

Model do not support delivery of system in pieces.

Working version is available very late so review of software product from customers is also late.

Model is very rigid because output of each phases is depend on their successive stages.

Disadvantages of Waterfall model

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality

User requirements are prioritised and the highest priority requirements are included in early increments

Once the development of an increment is started, the requirements are frozen.

it combines elements of the waterfall model applied in iterative fashion. (iterative process model).

Example: word processing software

Incremental Process Model

Incremental Models: Incremental

C-Communication

P-Planning

M-Modeling

C-Construction

D-Deployment

Limited number of persons can be put on project because work is to be delivered in parts.

Customer value can be delivered with each increment so system functionality is available earlier

Early increments act as a prototype to help elicit requirements for later increments

Lower risk of overall project failure

Total cost of project is distributed. End user’s feedback requirements for successive releases

become more clear. Testing become more easily. Risk of failure is decrease.

Advantages of Incremental Model

Model required well defined project planning schedule to distribute the work properly.

Testing of modules result into overhead and increased cost.

Product is delivered in parts, total development cost is higher.

Well define interfaces are required to connect modules.

Disadvantages of Incremental Model

If requirements are well understood and project scope is well defined then this model is very useful.

It is high speed model to develop the project.

It is incremental model.

Important feature of RAD model is customer/user involve in all stages of development.

The process start with building rapid prototype (in 60 days) and delivered to customer for use and feedback.

Final shape of project is started after positive feedback.

RAD Model (Rapid Application Development)

RAD Model

Customer involved in all stages so software achieving customer satisfaction.

Feedback from the customer is available at the initial stages.

Development time of the product may be reduced due to use of powerful tools.

In order to increase productivity, case tools and framework are used.

Quick initial view of the product are possible.

Involvement of the users may increase the acceptability of the product.

Advantages of RAD model

Highly specialized and skilled developers are required.

Model is ineffective if system can not be properly modularized.

If user cannot be involved throughout the life cycle, this model is not suitable.

Absence of reusable components can lead to failure of the project.

It may be hard to use a legacy systems.

Disadvantages of RAD model

Note: when to use the RAD model First, on systems that may be modularized and that are scalableSecond, on systems with reasonably well known requirements

B

This model is also known as the successive versions model. System is first broken down into several modules or

functional units that can be incrementally implemented and delivered.

The developers first develop the core modules of the system.

Next refine the modules as another incremental level by adding new functionalities.

Evolutionary Models

A A C BA

A,B,C are modules of a software product that are incrementally developed and delivered

1. Rough requirements specification2. Indentify the core and other parts to be

developed incrementally3. Develop the core part using an IWM4. Collect customer feedback and modify

requirements5. Develop the next identified features

using an IWM 4----all features complete----6. maintenance

Although it can be used as a standalone process model, it is more commonly used as a technique that can be implemented within the context of other process models

The prototyping paradigm assists the SW engineer and the customer to better understand what is to be built when requirements are fuzzy(customer identify general objective but not defines the details of input ,processing , and processing so the developer becomes unsure about efficiency , algorithms and so on to solve this problem prototype is used )

Ideally, the prototype serves as a mechanism for identifying SW requirement

Risk analysis is better. It supports changing requirements. Initial Operating time is less. Better suited for large and mission-critical

projects. During life cycle software is produced early

which facilitates customer evaluation and feedback.

Advantages.

Not suitable for smaller projects. Management complexity is more. End of project may not be know which is a

risk. Can be costly to use. Highly skilled resources are required for risk

analysis. Project’s progress is highly dependent upon

the risk analysis phase.

Disadvantages

Customer knows all general objectives of software but does not define input, output and functionality very clearly then this…..

In other case developer does not sure of different algorithms then…

Before developing actual software, a working prototype of the system should be built.

It is partial developed product. It has limited functional capabilities, low reliability and inefficient performance.

The prototype may be useable program but is not suitable as the final software product.

Prototype model

Evolutionary Model: Prototyping

Requirement Gathering Quick design build prototype customer

evaluation of prototype (suggestions)

Acceptance by customer design implement test maintain feedback

Scenario of model

Limited functions Shortcut implementation Use : input data formats like gui based,

reports etc.. When technical solutions are

unclear(product dev, design decision, algorithm etc)

Prototype ?

Advantages of Prototype model◦ A partial product is built in the initial stages therefore

customer get a chance to see the product early in the life cycle so give the necessary feedback.

◦ Flexibility in design and development is also supported by the model.

◦ Customer may be more satisfied because he is involved from starting phase.

Disadvantages of prototype model◦ After seeing an early prototype the users may demand

the actual system to be delivered soon.◦ End user may not be understand the prototype model.◦ Poor documentation.◦ If user not satisfied then he may be loose the interest in

the project.

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

ConstructionDeployment delivery feedback

Start

analysis design

code test

estimation scheduling risk analysis

Fig 3.5: A typical spiral model

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

Simplified Spiral Model

If risks cannot be resolved, project is immediately terminated

Strengths◦ Introduces risk management◦ Prototyping controls costs◦ Evolutionary development

Weaknesses◦ Lack of risk management experience◦ Model is not suitable for small project

Spiral Model (Strength and Weaknesses)

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)

NoneNone

Underdevelopment

Underdevelopment

AwaitingchangesAwaitingchanges

UnderrevisionUnder

revision

DoneDone

Under reviewUnder review

BaselinedBaselined

Represents the stateof a software engineeringactivity or task

Modeling activity

Advantages of CDM:

Disadvantages of CDM:

SEI (Software Engineering Institute) has developed a comprehensive model

To grade organizations’ current state of process maturity

Grading scheme determines compliance with a Capability Maturity Model (CMM) that defines key activities required at different levels of process maturity.

Is used for improving the s/w project

CMM Level

Level 1: Initial s/w process characterized as adhoc and

occasionally even chaotic Few processes are defined and success

depends on individual effort

Cont.

Basic project management processes are established to track cost, schedule and functionality.

Level 3: Defined- s/w process for both management and

engineering activities is documented, standardized and integrated into an organizational wide s/w process

Level 2 : Repeatable

Detailed measures of the software process and product quality are collected.

Both the s/w process and products are quantitatively understood and controlled using detailed measures.

Level 5: Optimizing- Continuous process improvement is enabled

by quantitative feedback from the process and from testing innovative ideas and technologies

Level 4 : Managed

1. s/w project tracking & control2. Risk mgmt.3. SQA4. Formal Technical review5. S/w configuration mgmt.6. Work product preparation & production7. Reusability mgmt.8. Measurement

Umbrella activities

Chapter 2Requirement Engineering

Problem recognition Requirement Engineering Tasks Processes SRS Use cases and Functional specification Requirement validation Requirement Analysis Modeling and types

Topics

A requirement can range from high level abstract statement of a service or of a system constrain to a detailed mathematical specification.

Requirement ?

Is the process of

Establishing the services that the customer requirement from system

The contraints under which it operates and is developed

Requirement engineering ?

1. User – collection of statement written for customer.

2. System – structured document gives detailed description. Contract between client and contractor.

3. Software specification – software description for design implementation.

Types of Req.

Problem Recognition

Sys engineering

Req analysis Sw design

Analyst Designer Developer

How is Req analysis helpful?

Problem Recognition Evaluation Modeling Specification Review

What are req. ana. Efforts?

What is system analyst ???

Role of system analyst

“Is a person who starts requirement gathering and requirement analysis activity by collecting all the information from the customer.”

Cont..

What is the problem ? What is the need to solve the problem ? What could be the solutions to the

problem ? What sort complexities or problem that

might arise while solving the problem ? What kind of input or output would be for

the system ?

cont..

1) functional and non- functional requirement.

2) user requirement.

Types of Req engineering.

Software Requirements Specification

Requirement analysis and specification consist of basic two activities:

◦ Requirements gathering and analysis Solve the following problems:

Anomaly (ambiguity) Inconsistency Incompleteness

◦ Requirement Specification SRS

Software Requirements Specification

Who needs the SRS and for what purpose?

◦ Users, customers and marketing personnel SRS will meet their needs

◦ Software developers Develop the exact functionality which is specify in SRS

document◦ Test engineers

SRS provide meaningful functionality for making test templates.◦ User documentation writers

Understand the SRS documents well enough to be able to write user’s manual.

◦ Project managers Estimate the cost easily and planning

◦ Maintenance engineers Understand the functionality, design and coding.

Software Requirements Specification

SRS document should clearly document the following aspects of a system:◦ Functional requirement◦ Non functional requirement◦ Goals of implementation

Functional requirement◦ High level functional requirements◦ Sub requirements

Non functional requirement◦ This include aspects concerning maintainability, portability and

usability.◦ Also include reliability issues, accuracy of results, human-computer

interfaces issues. Goals of implementation

◦ Give some general suggestions regarding development.

Characteristics of a good SRS documents Concise

◦ The SRS document is to the point at the same time unambiguous, consistent and complete. Irrelevant description reduce reliability and increase error in srs.

Structured ◦ The SRS document should be well structured.

Black-box view◦ The SRS should specify the externally visible behavior of the

system. Conceptual integrity

◦ The SRS document should exhibit conceptual integrity so that the reader can easily understand the contents.

Response to undesired events◦ The SRS document should characterize acceptable responses

to undesired events. Verifiable

◦ Whether or not requirements have been met in an implementation.

Organization of the SRS document

Depends on system analysist Depends on Project type Depends on company polices and rules

So SRS document is always differ organization to organization.

Software Requirements Specification Format

Introduction ◦ Purpose ◦ Scope◦ Definitions, Acronyms and Abbreviations◦ References◦ Overview

Overall Description ◦ Product Perspective◦ Product Functions◦ User characteristics◦ Constraints◦ Assumptions and dependencies

Software Requirements Specification Format Specific Requirements

◦ Functionality◦ Usability ◦ Reliability ◦ Performance◦ Supportability◦ Design Constraints◦ On-line User Documentation and Help System Requirements ◦ Purchased Components◦ Interfaces◦ Licensing Requirements◦ Legal, Copyright, and Other Notices◦ Applicable Standards