Sri Vidya College of Engineering & Technology-Virudhunagar · PDF fileSri Vidya College of Engineering & Technology-Virudhunagar CS6403 SOFTWARE ENGINEERING Page 3 Software...

Sri Vidya College of Engineering & Technology-Virudhunagar

CS6403 SOFTWARE ENGINEERING Page 1

Sri Vidya College of Engineering &Technology

Department of Information Technology

Class II Year (04 Semester)

Subject Code CS6403

Subject SOFTWARE ENGINEERING

Prepared By R.Vidhyalakshmi

Lesson Plan for Introduction to Software Engineering

Time: 50 Minutes

Lesson. No Unit – I Lesson No: 1/9

1.Content List: Introduction to Software Engineering

2.Skill addressed:

Understand the Concepts of Software Engineering

3.Objectives of this Lesson Plan:

To enable students to list the basic Concepts of Software Engineering

4.Outcome(s):

Understanding And Analyse the basic concepts of Software Engineering

5.Link sheet:

1. What is Software?

2. What is Software Engineering?

3. What is Software Product?

4. What is Software Process?



6.Evocation: (5 Minutes)

Subject introduction (40 Minutes):

Topics:

Introduction

Examples:

What is Software Engineering?

7.Lecture notes

INTRODUCTION TO SOFTWARE ENGINEERING AND PROCESS,PRODUCT

Software engineering

Software engineering is a discipline in which theories, methods and tools are applied to develop professional

software.

Software

Software is nothing but a collection of computer programs that are related documents that are indented to

provide desired features, functionalities and better performance.

characteristics of the software

a. Software is engineered, not manufactured.

b. Software does not wear out. Most software is custom built rather than being assembled from

components.

various categories of software

o System software

o Application software

o Engineering/Scientific software

o Embedded software

software process



Software process is defined as the structured set of activities that are required to develop the software system

fundamental activities of a software process

Specification

Design and implementation

Validation

Evolution

8.Textbook:

T1: Roger S. Pressman, “Software Engineering – A practitioner’s Approach”, Sixth Edition,

McGraw-Hill International Edition, 2005

9.Application:

Business software, Data mining closely related to database

http://en.wikipedia.org/wiki/Business_software

http://en.wikipedia.org/wiki/Data_mining

http://en.wikipedia.org/wiki/Database






Subject Code CS6403



Lesson Plan for Life Cycle Model – Waterfall, Prototyping ,RAD model

Time: 50 Minutes


1.Content List: Life Cycle Models

2.Skill addressed:

Understand the Concepts of Software Engineering Life Cycle Model


To enable students to list the Life Cycle Model in Software Engineering

4.Outcome(s):

Understandi And Analyse the basic concepts of Software Engineering Life cycle

model

5. Link sheet:

1. Name the Evolutionary process Models

2. What are the merits of waterfall model?

3. What are the merits of waterfall model?

4. What are theAdvantages &Disadvantages of waterfall model?





Topics:

Introduction to lifecycle model

Waterfall model, prototyping model

RAD

7.Lecture Notes

Waterfall model/Linear Sequential Model/classic life cycle :

Systems Engineering

Software as part of larger system, determine requirements for all system elements, allocate requirements

to software.

• Software Requirements Analysis

Develop understanding of problem domain, user needs, function, performance, interfaces, .

Software Design

Multi-step process to determine architecture, interfaces, data structures, functional detail. Produces

(high-level) form that can be checked for quality, conformance before coding.

• Coding

Produce machine readable and executable form, match HW, OS and design needs.

• Testing

Confirm that components, subsystems and complete products meet requirements, specifications and quality,

find and fix defects.

• Maintenance

– Incrementally, evolve software to fix defects, add features, adapt to new condition. Often 80% of effort spent

here!



Waterfall model phases:

• Requirements analysis and definition

• System and software design

• Implementation and unit testing

• Integration and system testing

• Operation and maintenance

• The main drawback of the waterfall model is the difficulty of accommodating change after the process is

underway. One phase has to be complete before moving onto the next phase.

• Each phase terminates only when the documents are complete and approved by the SQA group.

• Maintenance begins when the client reports an error after having accepted the product. It could also begin due

to a change in requirements after the client has accepted the product

Waterfall model: Advantages:

• Disciplined approach

• Careful checking by the Software Quality Assurance Group at the end of each phase.

• Testing in each phase.

• Documentation available at the end of each phase.

Waterfall model problems:

• It is difficult to respond to changing customer requirements.

• Therefore, this model is only appropriate when the requirements are well-understood and changes will be

fairly limited during the design process.

• Few business systems have stable requirements.

• The waterfall model is mostly used for large systems engineering projects where a system is developed at

several sites.

• The customer must have patience. A working version of the program will not be available until late in the

project time-span

• Feedback from one phase to another might be too late and hence expensive.

The Prototyping Models:

• Often, a customer defines a set of general objectives for software but does not identify detailed input,

processing, or output requirements.

• In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating

system, or the form that human –machine interaction should take

• In this case prototyping paradigm may offer the best approach

• Requirements gathering

• Quick design

• Prototype building

• Prototype evaluation by customers

• Prototype may be refined

• Prototype thrown away and software developed using formal process{ it is used to define the requirement}

Prototyping



Strengths:

• Requirements can be set earlier and more reliably

• Customer sees results very quickly.

• Customer is educated in what is possible helping to refine requirements.

• Requirements can be communicated more clearly and completely

Weaknesses:

Requires a rapid prototyping tool and expertise in using it–a cost for the development organisation

Smoke and mirrors - looks like a working version, but it is not.

The RAD Model:

• Rapid Application Development is a linear sequential software development process model that emphasizes

an extremely short development cycle

• Rapid application achieved by using a component based construction approach

• If requirements are well understood and project scope is constrained the RAD process enables a development

team to create a ―fully functional system‖

• Prototype thrown away and software developed using formal process{ it is used to define the requirement}

Prototyping

Strengths:

• Requirements can be set earlier and more reliably

• Customer sees results very quickly.

• Customer is educated in what is possible helping to refine requirements.

Weaknesses:

Requires a rapid prototyping tool and expertise in using it–a cost for the development organisation

Smoke and mirrors - looks like a working version, but it is not.

The RAD Model:

• Rapid Application Development is a linear sequential software development process model that emphasizes

an extremely short development cycle

• Rapid application achieved by using a component based construction approach

• If requirements are well understood and project scope is constrained the RAD process enables a development

team to create a ―fully functional system‖

• Application generation

• Testing and turnover

Business modeling:

• What information drives the business process?

• What information is generated?

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

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

are defined



Process modeling:

• 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 4 generation techniques.

• Rather than creating software using conventional 3 generation programming languages, the RAD process

works to reuse existing program components (when possible) or created reusable components (when necessary)

Testing and Turnover:

• Since the RAD process emphasizes reuse, many of the program components have already been testing.

• This reduces over all testing time.

• However, new components must be tested and all interfaces must be fully exercised

Advantages &Disadvantages of RAD:

Advantages

• Extremely short development time.

• Uses component-based construction and emphasises reuse and code generation

Disadvantages

• Large human resource requirements (to create all of the teams).

• Requires strong commitment between developers and customers for “rapid-fire” activities.

• High performance requirements maybe can’t be met (requires tuning the components).

8. Textbook:



9. Application:

Business software, Data mining closely related to database

http://en.wikipedia.org/wiki/Business_software

http://en.wikipedia.org/wiki/Data_mining

http://en.wikipedia.org/wiki/Database






Subject Code CS6403



Lesson Plan for Life Cycle Model – Incremental model, Spiral model

Time: 50 Minutes


1.Content List: Life Cycle Models

2. Skill addressed:

o Understand the Concepts of Software Engineering Life Cycle Model


o To enable students to list the Life Cycle Model in Software Engineering

4.Outcome(s):

o Understand And Analyze the basic concepts of Software Engineering Life cycle

model

5. Link sheet:

1.What are the merits of incremental model?

2.What are the merits of spiral model

3.Define spiral model





Topics:

Introduction to incremental model

Spiral model

7.Lecture Notes

The Incremental Model

The Incremental development

• Combination of linear + prototype

• 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 though requirements for later

increments can continue to evolve

Incremental development advantages:

• The customer is able to do some useful work after release

• Lower risk of overall project failure

• The highest priority system services tend to receive the most testing

Spiral Model:

Spiral model sectors:

• Customer communication

Tasks required to establish effective communication between developer and customer

• Planning - The tasks required to define recourses, timelines, and project is reviewed and the next phase of

the spiral is planned

Risk analysis Risks are assessed and activities put in place to reduce the key

Risks engineering Tasks required to build one or more representations of the application

• Construction & release Tasks required to construct, test, install and provide user support (e.g documentation

and trainin

Spiral Model Advantages:

• Focuses attention on reuse options.

• Focuses attention on early error elimination.

• Puts quality objectives up front.

8.Textbook:

T1: Ian Sommerville, “Software engineering”, Seventh Edition, Pearson Education Asia, 2007.



9.Application: Software field






Subject Code CS6403



Lesson Plan for SPM-Estimation and Loc based Estimation

Time: 50 Minutes

Lesson. No Unit – I Lesson No: 4,5/9

1.Content List: Estimation and Loc based Estimation

2. Skill addressed:

Understand the Concepts of SPM Estimation and Loc based Estimation


To enable students to list the SPM Estimation and Loc based Estimation

4.Outcome(s):

Understandi And Analyse the basic concepts of SPM Estimation and Loc based Estimation

5.Link sheet:

1. Define SPM

2.What is meant by Loc based estimation?

6. Evocation: (5 Minutes




7.Lecture Notes

Project Planning

• Software project planning encompasses five major activities

– Estimation, scheduling, risk analysis, quality management planning, and change management

planning

• Estimation determines how much money, effort, resources, and time it will take to build a specific

system or product

• The software team first estimates

– The work to be done

– The resources required

– The time that will elapse from start to finish

• Then they establish a project schedule that

– Defines tasks and milestones

– Identifies who is responsible for conducting each task

– Specifies the inter-task dependencies

Estimation

• Planning requires technical managers and the software team to make an initial commitment

• Process and project metrics can provide a historical perspective and valuable input for generation of

quantitative estimates

• Past experience can aid greatly

• Estimation carries inherent risk, and this risk leads to uncertainty

• The availability of historical information has a strong influence on estimation risk

• When software metrics are available from past projects

• Estimates can be made with greater assurance

• Schedules can be established to avoid past difficulties

• Overall risk is reduced

• Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule,

and resources

• Nevertheless, a project manager should not become obsessive about estimation

• Plans should be iterative and allow adjustments as time passes and more is made certain

„ Estimation of resources, cost, and schedule for a software engineering effort requires experience

„ access to good historical information (metrics the courage to commit to quantitative predictions when

qualitative information is all that exists

„ Estimation carries inherent risk and this risk leads to uncertainty

Project Estimation

Project scope must be understood

Elaboration (decomposition) is necessary

Historical metrics are very helpful At least two different techniques should be used

Uncertainty is inherent in the process

Estimation Techniques

Past (similar) project experience

Conventional estimation techniques

task breakdown and effort estimates

size (e.g., FP) estimates

Empirical models

Automated tools



Estimation Accuracy

The degree to which the planner has properly estimated the size of the product to be built

the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the

availability of reliable

software metrics from past projects) the degree to which the project plan reflects the abilities of the

software team the stability of product requirements and the environment that supports the software

engineering effort.

Problem based Estimation

• In general, the LOC/pm and FP/pm metrics should be computed by project domain

Important factors are team size, application area, and complexity

• LOC and FP estimation differ in the level of detail required for decomposition with each value

For LOC, decomposition of functions is essential and should go into considerable detail (the more

detail, the more accurate the estimate)

For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment

factors

External inputs, external outputs, external inquiries, internal logical files, external interface files

Example of baseline productivity metrics are LOC/pm or FP/pm

Making the use of single baseline productivity metric is discouraged

In general, LOC/pm or FP/pm averages should be computed by project domain

Local domain averages should be used

Statistical approach – three-point or expected-value estimate

S = (sopt + 4sm + spess)/6

S = expected-value for the estimation variable (size)

sopt = optimistic value

sm = most likely value

spess = pessimistic value



Example Loc Based Estimation

Function Estimated LOC

User interface and control facilities (UICF)

Two-dimensional geometric analysis (2DGA)

Three-dimensional geometric analysis (3DGA)

Database management (DBM)

Computer graphics display facilities (CGDF)

Peripheral control function (PCF)

Design analysis modules (DAM)

2,300

5,300

6,800

3,350

4,950

2,100

8,400

Estimated lines of code 33,200

Estimated lines of code = W = 33,200

Let,

Average productivity = 620 LOC/pm = X

Labor rate = $8,000 per month = Y

So,

Cost per line of code = Z = Y/X = $13 (approx.)

Total estimated project cost = W*Z = $431,000 (approx.)

Estimated effort = W/X = 54 person-months (approx)

8.Textbook:








Subject Code CS6403



Lesson Plan for FP based Estimation

Time: 50 Minutes

Lesson. No Unit – I Lesson No:6,/9

1.Content List: FP based Estimation

2.Skill addressed:

Analyze and understanding the Concepts of FP based Estimation


To enable students to understand the FP based Estimation

4.Outcome(s):

Understand And Analyse the FP based Estimation

5.Link sheet:

1. What is meant by Estimstion?

2. What is ment by FB based estimation?





Topics:

Example FB Based Estimation

Information Domain

Value

Count Weighting factor

Simple Average Complex

External Inputs (EIS) 3 X 3 4 6 = 9

External Outputs (EOs) 2 X 4 5 7 = 8

External Inquiries (EQs) 2 X 3 4 6 = 6

Internal Logical Files

(ILFs)

1 X 7 10 15 = 7

External Interface Files

(EIFs)

4 X 5 7 10 = 20

Count Total 50



Fig.Value adjustment factor

Now,

FPestimated = count-total [0.65 + 0.01 (Fi)]

• Fi (i = 1 to 14 are value adjustment factors)

So,

FPestimated = W = 320 [0.65 + 0.01 52] = 375 (approx.)

Let,

Average Productivity = X = 6.5 FP/pm

Labor rate = Y = $8,000 per month

So,

Cost per FP = Z = Y/X = $1,230 (approx.)

Total estimated project cost = W*Z = $461,000 (approx.)

Estimated effort = W/X = 58 person-months (approx)

Empirical Estimation Models

Uses empirically derived formulas to predict effort as a function of LOC or FP

The empirical data are derived from a limited sample of projects

So, no estimation model is appropriate for all classes of s/w and in all development

environments

The results obtained from such models must be used judiciously

An estimation model should be calibrated to reflect local conditions

Structure of Estimation model

Derived using regression analysis on data collected from past s/w projects

Overall structure, E = A + B (ev)c

Here,

o A, B, and C are empirically derived constants

o E is effort in person-months



o ev is the estimation variable (either LOC or FP)

Some form of project adjustment component is also used

Example of a LOC-oriented estimation model (Bailey-Basili model)

o E = 5.5 + 0.73 (KLOC)1.16

Example of a FP-oriented estimation model (Kemerer model)

o E = -37 + 0.96 FP

Estimation models must be calibrated for local needs

8. Textbook:

T1: Roger S. Pressman, “Software Engineering – A practitioner’s Approach”, Sixth

Edition,McGraw-Hill International Edition, 2005






Subject Code CS6403



Lesson Plan for COCOMO Model ,Project scheduling

Time: 50 Minutes

Lesson. No Unit – I Lesson No: 7,8/9

1.Content List: COCOMO Model ,Project scheduling

2.Skill addressed:

Analyze the Concepts of COCOMO Model ,Project scheduling


To enable students to understand the COCOMO Model ,Project scheduling

4.Outcome(s):

Understand And Analyze the COCOMO Model , Project scheduling

5. Link sheet:

1. What is meant by COCOMO model?

2. Define Scheduling?



Topics:

COCOMO Model ,Project scheduling

7.Lecture Notes

COCOMO Model

• Stands for COnstructive COst MOdel

• Introduced by Barry Boehm in 1981 in his book “Software Engineering Economics”

• Became one of the well-known and widely-used estimation models in the industry

• It has evolved into a more comprehensive estimation model called COCOMO II

• COCOMO II is actually a hierarchy of three estimation models



• As with all estimation models, it requires sizing information and accepts it in three

forms: object points, function points, and lines of source code

• Application composition model - Used during the early stages of software

engineering when the following are important

• Prototyping of user interfaces

• Consideration of software and system interaction

• Assessment of performance

• Evaluation of technology maturity

• Early design stage model – Used once requirements have been stabilized and basic

software architecture has been established

• Post-architecture stage model – Used during the construction of the software

COCOMO Cost Drivers

• Personnel Factors

• Applications experience

• Programming language experience

• Virtual machine experience

• Personnel capability

• Personnel experience

• Personnel continuity

• Platform experience

• Language and tool experience

• Product Factors

• Required software reliability

• Database size

• Software product complexity

• Required reusability

• Documentation match to life cycle needs

• Product reliability and complexity

• Platform Factors

• Execution time constraint

• Main storage constraint

• Computer turn-around time

• Virtual machine volatility

• Platform volatility

• Platform difficulty

• Project Factors

• Use of software tools

• Use of modern programming practices

• Required development schedule

• Classified security application

• Multi-site development

• Requirements volatility

Project Scheduling

Split project into tasks and estimate time and resources required to complete each task

Organize tasks concurrently to make optimal use of workforce

Minimize task dependencies to avoid delays caused by one task waiting for another to

complete

Dependent on project managers intuition and experience

Scheduling Problem

Estimating the difficulty of problems and hence the cost of developing a solution is

hard



Productivity is not proportional to the number of people working on a task

Adding people to a late project makes it later because of communication overheads

The unexpected always happens. Always allow contingency in planning

8.Textbook:

T1: Roger S. Pressman, “Software Engineering – A practitioner’s Approach”, Sixth

Edition, McGraw-Hill International Edition, 2005






Subject Code CS6403



Lesson Plan for Risk Management

Time: 50 Minutes


1.Content List: Risk Management

2.Skill addressed:

Analyze the Concepts of Risk Management


To enable students to understand the Risk Management

4. Outcome(s):

Understand And Analyse the Risk Management

5. Link sheet:

1. What is meant by risk?

2. How to identify the risk?

6 .Evocation: (5 Minutes)


Topics:

Risk Management



7.Lecture Notes

Risk Management

Risks are potential problems that affect successful completion of project which involves

Uncertainty and potential lose Risk analysis and management helps the s/w team to overcome

the problems caused by the risks. The work product is called a Risk Mitigation, Monitoring

and Management Plan(RMMMP).

(a) risk strategies:

* Reactive strategies: also known as fire fighting, project team sets resources aside to deal

with the problem and does nothing until the risks became a problem.

* Pro active strategies: risk management begins long before technical works starts , risks are

Identified and prioritized by importance, the team lead builds a plan to avoid such risks.

(b) S/W risks:

* Project risk:

* Technical risk: threaten product quality and time line

* Business risk: threaten the validity of the s/w.

* Known risk: predictable from careful evaluation of current project plan and those

extrapolated from past project experience.

* Unknown risk: some problems simply occur without warning.

(c) Risk identification:

* Product – specific risk: the project plan and s/w statement of scope are examined to identify

any specific characteristics.

* Generic risk: Potential threads to any s/w products.

(d) Risk impact:

* Risk components: performance, cost, support, schedule

* Risk impact: negligible, marginal , critical, catastrophic.

The risk drivers affecting each risk component are classified according to their impact

category and potential consequence of each undetected s/w fault.

(e) Risk projection:

Establish a scale that reflects the perceived likelihood of each risks.

Delineate the consequence of the risk.

Estimate the impact of the risk on project and product.

(f) risk table construction:

* List all risks in the first column of the table

* Classify each risk and enter the category label in column 2

* Determine a probability for each risk and enter to third column.

* Enter the severity of the risk in column 4.

* Sort the table by probability and impact value.

* First priority concerns must be managing(RMMM in fifth column).

(g) assessing risk impact:

* Factors affecting risk consequences: nature, scope, and timing of the risk.

* If costs are associated with each risk table entry Halstead’s risk exposure can be

adopted and added to risk table. RE= probability * cost

(h) risk assessment:

* Defines referent levels for each project risk that can cause project termination.

* Attempt to develop a relationship between each risk triple.

* Predict the set of referent point that define a region of termination, bounded by a

curve or areas of uncertainties.



(i) risk refinement:

* process of restating the risks as set of more detailed risk that will be easier to

migrate, migrate, and manage.

* CTC format may be a good representation for the detailed risk( condition –

transition – consequence)

(J) RISK MITIGATION, MONITORING AND MANAGEMENT:

* Risk mitigation: proactive planning for risk avoidance

* risk monitoring: accessing whether predicted risks occur or not, collect information

for further risk analysis.

* Risk management and contingency planning : actions to be taken in the event that

mitigation step have failed and the risk become a life problem.

(k) safety risks and hazards:

Risks also associated with s/w failures that occur in the field after the development

project has ended.

Software safety and hazard analysis and quality assurance activity

(l) risk information sheets:

alternative to RMMM in which each risk is documented separately.

RIS are maintain using a database system

(m)Examples:

Pilot study

Market research – study of business impact risks

Training

(n) outline of risk management:

identification-define risks for the project

projection attempt to indicate quantitative likelihood that a risk will occur.

Assessment – evaluate the accuracy of projection and prioritize risks.

Management and monitoring: move to avert those risks that are of concern and

monitor all circumstance that may leave to risks.

1. risk identification:

A systematic attempt to specify thread to the project plan.

Both generic and product specific risks

Risk identification : check list

(i) people / staff

(ii) customer / user

(iii) business/business impact

(iv) application, product size, technology

(v) process maturity

2. risk projection:

establish a scale that reflects the perceived likelihood of the risks.

Define the consequence of the risks.

Estimate the impact of the risk on the project and or the product

3. risk assessment:

recording risks:

building the risk table

(i) estimate the probability of the occurrence

(ii) estimate the impact on the project

(iii) add RMMM plan



(iv) sort the table by probability and impact

4. risk mitigation, monitoring and management:

monitoring: what factors can be track that will enable us to determine the causes

of risks.

Management: what contingency plans do we have if the risks become a real

8. Textbook:



Sri Vidya College of Engineering & Technology-Virudhunagar · PDF fileSri Vidya College of Engineering & Technology-Virudhunagar CS6403 SOFTWARE ENGINEERING Page 3 Software...

Documents