1

II YEAR V SEMESTER

Paper VI : Software Engineering

UNIT I

INTRODUCTION: Software Engineering Process paradigms - Project management -

Process and Project Metrics – software estimation - Empirical estimation models - Planning -
Risk analysis - Software project scheduling.

UNIT II
REQUIREMENTS ANALYSIS : Requirement Engineering Processes – Feasibility Study –
Problem of Requirements – Software Requirement Analysis – Analysis Concepts and
Principles – Analysis Process – Analysis Model

UNIT III
SOFTWARE DESIGN: Software design - Abstraction - Modularity - Software Architecture
- Effective modular design - Cohesion and Coupling - Architectural design and Procedural
design - Data flow oriented design.

UNIT IV
USER INTERFACE DESIGN AND REAL TIME SYSTEMS :User interface design -
Human factors - Human computer interaction - Human - Computer Interface design -
Interface design - Interface standards.

UNIT V
SOFTWARE QUALITY AND TESTING :Software Quality Assurance - Quality metrics -
Software Reliability - Software testing - Path testing – Control Structures testing - Black Box
testing - Integration, Validation and system testing - Reverse Engineering and Re-
engineering.
CASE tools –projects management, tools - analysis and design tools – programming tools -
integration and testing tool - Case studies.

Compiled By Mahesh MCA

 2

1. Explain the Software Engineering Process paradigms?

Software:

 Software is more than just a program code. A program is an executable code, which
serves some computational purpose. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.
 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 Paradigms:

Programming paradigm is a subset of Software design paradigm which is further a subset of

Software development paradigm.

1. Software Development Paradigm: It includes various researches and requirement

gathering which helps the software product to build.

 Requirement gathering
 Software design
 Programming
2. Software Design Paradigm: This paradigm is a part of Software Development and
includes

 Design
 Maintenance
 Programming
3. Programming Paradigm: This paradigm is related closely to programming aspect of
software development. This includes

Compiled By Mahesh MCA

 3

 Coding

 Testing
 Integration
1.WHAT IS SOFTWARE ENGINEERING?

Software Engineering: The practices that follow while developing an automated application
(or)

The technology encompasses (include) a process, a set of methods and array of tools that we
call software engineering.

 Software: Software is collection of programs.

 Program: Program is Set of related statements.

Characteristics of software:

1. Software is developed but not manufactured.

2. “Does not wear out” that is can’t be produced instantly. ie s/w does not degrade with
time as hardware does.

3. Failure curve of hardware (Bath tub problem)as a function of time

 Practices in software engineering is(list of the umbrella activities)

1. Writing program using code reusability

2. ER-Diagram (or) UML - Diagrams

3. Testing

Compiled By Mahesh MCA

 4

4. Quality Assurance

5. Deployment

6. Feedback

7 Risk management

8) Measurement

Note: Software transforms data into information.

2. Explain about Software Engineering Process Paradigms (Models)

Software Engineering: The practices that follow while developing an automated application.

Process models help in

 Software development
 Guides software engineer through a set of frame work activities

Models

Prescriptive Process Models:

1) The Waterfall Model

2) Incremental Process Models
3) Evolutionary Process Models

THE WATERFALL MODEL (OR) SYSTEM DEVELOPMENT LIFE CYCLE (OR)

CLASSICAL LIFE CYCLE (OR) LINEAR SEQUENTIAL

Communication:

 Project initiation : Feasibility of proposed system (system to be developed ) is

considered

Compiled By Mahesh MCA

 5

a. Economical feasibility: Whether there is economy to develop the developed system.

b. Technical feasibility: Whether there is technology resources to develop the proposed
system.
c. Operational feasibility: Whether day to day operations are possible.
d. Behavioral feasibility: Is the solutions to behavioral problems arises between the people.

Requirement gathering:
 Software engineer communicate with stack holder(client) to understand the
information domain(how to develop product) and formulates design specifications.
 Effective communication between the software engineer and stack holder is needed.

Planing:
a. Estimating: Resources need for software development is to be estimated.
b. Several techniques(methods) are adopted to monitor progress against plan
1. Work Breakdown Structures ( WBS )
2. PERT ( Program Evaluation and Review Technique )
3. GANTT Chart

WBS for Order Entry System

PERT chart for Order entry system

Modeling:

Compiled By Mahesh MCA

 6

It can be divided into two ways

1. Aalysis

2.Design

Analysis : System Analyst must understand

I. Information domain
II. Required functions
III. Behavior of information domain
IV. Performance
V. Requirements reviewed and documented
Design : Design is multi step process focused on
I. Data Dictionary (Tables, Attributes, Data types of attributes, Constraints on tables,
Relationships between the tables)
II. User interfaces ( Screens )
III. Algorithmetic details
IV. Data structures
V. DFD’ ( Data Flow Diagrams )
VI. UML (Uniform Modeling Language) Diagrams
VII. Flowcharts (System flowcharts, Program flowcharts, Control flow charts)

Construction:

Coding: The process of writing application programs to given specifications.

Testing: The process of verifying the application program for uncovered errors or
irregularities.

Deployment:

Deployment : Installing product to customer

a. Delivery
b. Support
c. Feed back
a. Delivery: Dispatching product to customer for usage

b. Support : Rectifying problems of end user

Compiled By Mahesh MCA

 7

 Software undergo for change after it is deliver to customer.

 Change will occur because

a) Errors has been uncounted.

b) To accommodate changes in its external environment.

c) Customer requires functional or performance enhancement.

c. Feedback: Details given by end user.

Feedback from end users can be collected using

i) Interviews
ii) Questionnaires
iii) Onsite observations
Limitations:

1. Difficult to state all requirements explicitly.

2. Difficult to accommodate natural changes.

3. Customer must have patience.

4. If requirements are formulate poorly the entire system fails

Advantages of waterfall model

The waterfall model is simple and easy to understand, implement, and use.

 All the requirements are known at the beginning of the project, hence it is easy to
manage.
 It avoids overlapping of phases because each phase is completed at once.
 This model works for small projects because the requirements are understood very
well.
 This model is preferred for those projects where the quality is more important as
compared to the cost of the project.

Disadvantages of the waterfall model

 This model is not good for complex and object oriented projects.
 It is a poor model for long projects.
 The problems with this model are uncovered, until the software testing.
The amount of risk is high
When to use the water fall model
This model is used only when the requirements are very well known, clear and fixed
Technology is understood , the project is short, there are no ambiguous requirements
2.INCREMENTAL MODEL

Compiled By Mahesh MCA

 8

The incremental process model focuses on the delivery of an operational product with each

increment. Early increments are stripped-down versions of the final product, but they do

provide capability that serves the user and also provide a platform for evaluation by the user.

Objectives :
(a) Software development
(b) Guides software engineer through a set of frame work activities

Each increment is developed using water fall model

E.g. Entity: Bank

Increment 1: Automating teller operation
Increment 2: Automating ATM operation
Increment 3: Automating internet banking operation
Increment 4: Automating mobile banking operation
Each increment includes the following steps

Compiled By Mahesh MCA

 9

Communication:

Project initiation : Feasibility of proposed system (system to be developed ) is

considered
Economical feasibility: Whether there is economy to develop the developed system.
Technical feasibility: Whether there is a technology resource to develop the proposed
system.
Operational feasibility: Whether day to day operations are possible.
Behavioral feasibility: Is the solutions to behavioral problems arises between the people.

Requirement gathering:
Software engineer communicate with stack holder to understand the information domain
and formulates design specifications.
Effective communication between the software engineer and stack holder is need to
formulate better requirements.

Planning:

Estimating: Resources need for software development is estimated.

Several techniques are adopted to monitor progress against plan
1. Work Breakdown Structures ( WBS )
2. PERT ( Program Evaluation and Review Technique )
3. GANTT Chart

Modeling:

It can be divided in to two ways

a. Analysis and b.Design

Analysis : System Analyst must understand

 Information domain
 Required functions
 Behavior of information domain
 Performance
 Requirements reviewed and documented
Design : Design is multi step process focused on
 Data Dictionary (Tables, Attributes, Data types of attributes, Constraints on
tables, Relationships between the tables)

Compiled By Mahesh MCA

 10

 User interfaces ( Screens )

 Algorithmetic details
 Data structures
 DFD’s ( Data Flow Diagrams )
 UML (Uniform Modeling Language) Diagrams
 Flowcharts (System flowcharts, Program flowcharts, Control flow charts)

Construction:

Coding: The process of writing application programs to given specifications.

Testing: The process of verifying the application program for uncovered errors or
irregularities.

Deployment: Installing product to customer

a. Delivery
b. Support
c. Feed back
a. Delivery: Dispatching product to customer for usage

b. Support : Rectifying problems of end user

 Software undergo for change after it is deliver to customer.

 Change will occur because

 Errors have been uncounted.

 To accommodate changes in its external environment.

 Customer requires functional or performance enhancement.

c. Feedback: Details given by end user.Feedback from end users can be collected
using
 Interviews
 Questionnaires
 Onsite observations

Advantages:

1. Useful when staffing is unavailable.

Compiled By Mahesh MCA

 11

2. Each increment can be implemented with fewer people.

3. Core product can be developed & reviewed.
4. Increment can be planned to manage technical risks.

3 THE RAD MODEL (RAPID APPLICATION DEVELOPMENT)

 Objectives : (a) Software development in very short time period (b) Guides software
engineer through a set of frame work activities

 High speed adoption of linear sequence model.

 RAD approach support the following phases.

1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation
5. Testing & Turnover

Business modeling:

The information flow among business functions is modeled in a way that answers the
following questions.

Compiled By Mahesh MCA

 12

1. What information derives the business process?

2. What information is generated?
3. Who generates it?

Data modeling:

Database objects are defined.

a) Entities d) Relations
b) Attributes e) Constraints
c) Key Attributes

Process modeling:

Process description is created for (a) Retrieval of data (b) Deletion of data (c)
Addition of data (d) Modification of data

Application Generation:

 Forth generation techniques are adopted for writing application

 Reuse the existing programs
 Create re useable components when necessary
 Automated tools are used for the construction of S/W

Testing and Turnover

 Many of the components have already been tested. This reduces overall testing time.

 The new components are tested and variety of test cases of exercised.

Limitations :

1. Sufficient human resources is required.

2. Software engineers are committed to rapid fire activities.
3. If commitment is lacking entire project will fail.
4. If a system cannot be modularized RAD will be problematic.
5. RAD will not be appropriated & technical risks are high.
ADVANTAGES

An incremental software process model

Having a short development cycle

Compiled By Mahesh MCA

 13

High-speed adoption of the waterfall model using a component based construction

approach
Creates a fully functional system within a very short span time of 60 to 90 days
Multiple software teams work in parallel on different functions
Modeling encompasses three major phases: Business modeling, Data modeling and
process modeling
Construction uses reusable components, automatic code generation and testing
DIS-ADVANTAGES

Not all types of application are appropriate for RAD

Requires a number of RAD teams
Requires commitment from both developer and customer for rapid-fire completion of
activities otherwise it fails
If system cannot be modularized properly project will fail.
Not suited when technical risks are high

Evolutionary Process Models

1. PROTOTYPING

Objective: Software development when requirements are hazy (unclear).

The basic idea in Prototype model is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to understand the requirements.
This prototype is developed based on the currently known requirements. Prototype model is a
software development model. By using this prototype, the client can get an ―actual feel‖ of

Compiled By Mahesh MCA

 14

the system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system. Prototyping is an attractive idea for complicated and
large systems for which there is no manual process or existing system to help determining the
requirements.
Advantages of Prototype model:

 Users are actively involved in the development

 Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily

Disadvantages of Prototype model:

 Leads to implementing and then repairing way of building systems.

 Practically, this methodology may increase the complexity of the system as scope of
the system may expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was
designed Incomplete or inadequate problem analysis

When to use prototype model

1) It is used when the desired system needs to have a lot of interaction with the end
users.
2) Typically online system, web interfaces have a very high amount of interaction with
end users.
3) It is ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system.

THE SPIRAL MODEL

Objective: To develop effective and efficient system.

Effectiveness: The working program must satisfy the needs of the user.

Efficient: The working program must use minimum resources to produce throughput.

Compiled By Mahesh MCA

 15

Software is updated periodically according to the changing requirements of the

customer.

The Spiral model include the following phases

 Customer communication
 Planning
 Risk analysis
 Engineering
 Construction & release
 Customer evaluation

Customer communication:
Software engineer communicate with stack holder to understand the information
domain and formulates design specifications.
Effective communication between the software engineer and stack holder is need to
formulate better requirements.
Planning:
Estimating: Resources need for software development is estimated.
Several techniques are adopted to monitor progress against plan
a. Work Breakdown Structures ( WBS )
b. PERT ( Program Evaluation and Review Technique )
c. GANTT Chart

Risk analysis:
Asses both technical risks and management risks.

Compiled By Mahesh MCA

 16

Engineering:

Various software engineering techniques are adapted to develop the system

E.g. Top-down approach, Bottom-up approach, Physical design

Construction & release:

Coding: The process of writing application programs to given specifications.

Testing: The process of verifying the application program for uncovered errors or
irregularities.

Customer evaluation:
Feedback: Details given by end user.

Feed back from end users can be collected using

i) Interviews
ii) Questionnaires
iii) Onsite observations

CONCURRENT DEVELOPMENT MODEL (OR) CONCURRENT ENGINEERING

The concurrent development model, sometimes called concurrent engineering, allows a

software team to represent iterative and concurrent elements of any of the process models
described in this chapter. For example, the modelling activity defined for the spiral model is
accomplished by invoking one or more of the following software engineering actions:
prototyping, analysis, and design
For example, early in a project the communication activity (not shown in the figure)has
completed its first iteration and exists in the awaiting changes state. The modelling activity
(which existed in the inactive state while initial communication was completed,now makes a
transition into the under development state. If, however, thecustomer indicates that changes
in requirements must be made, the modeling activitymoves from the under development
state into the awaiting changes state.Concurrent modeling defines a series of events that will
trigger transitions fromstate to state for each of the software engineering activities, actions, or
tasks.

Compiled By Mahesh MCA

 17

Forexample, during early stages of design (a major software engineering action that occurs
during the modeling activity), an inconsistency in the requirements model isuncovered. This
generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes state.

SPECIALIZED PROCESS MODELS

1. THE FORMAL METHODS MODEL

 Formal method: Mathematical Specification

 Formal mathematical specifications enables a software engineer to specify

develop & verify computer based system.

 This notation is also called as ―clean room software engineering ―.

 Formal methods eliminating many problems that are difficult to overcome.

 Ambiguity, incompleteness and inconsistency can be discovered and corrected

more easily.

 Formal methods serve as basis for program verification.

 Formal methods offers promise of defect software

 Time consuming and expensive.

Compiled By Mahesh MCA

 18

 Extensive training is required for s/w engineering

 Few software developers have the necessary background to apply formal methods.

2. COMPONENT BASE DEVELOPMENT

 Component :Working program.

 Components are developed by the vendors.

 Developed using spiral model.

 Evolutionary in nature

Component based developed model incorporate the following steps:

1. Developer must understands the information domain.

2. S/W architecture is designed.

3. Comprehensive testing is conducted.

3. ASPECT ORIENTED SOFTWARE DEVELOPMENT

 Aspect : Software component.

 Complex software is developed.

 Complex software includes (a) Localized features (b) Functions (c) Information
content

Features:

1.User interfaces 2.Collaborative work

3.Distribution 4.Persistency

5.Memory management 6.Transaction processing 7.Security integrity

Types:

i) User interface aspects (Event based programming)

ii) Distribution aspects (Receiving and transporting)

iii) Persistency aspects (Storing, Retrieving and Indexing)

iv) Authentication aspect(Encoding and Decoding)

v) Transaction aspect (Atomicity, Concurrency control and Logging Strategy)

4. THE UNIFIED PROCESS

Compiled By Mahesh MCA

 19

Unified process: Attempt to draw on the best features and characteristics of

conventional software process.

Unified process has the following phases

 Inception
 Elaboration
 Construction
 Transaction

Compiled By Mahesh MCA

 20

2.PROJECT MANAGEMENT

1.Write about process management

Effective software project management focuses on the four P’s: people, product, process,
and project..

1) The People

The people management defines the following key practice areas for software people

 RECRUITING
 SELECTION
 PERFORMANCE MANAGEMENT
 TRAINING
 COMPENSATION
 CAREER DEVELOPMENT
 ORGANIZATION AND WORK DESIGN
 TEAM/CULTURE DEVELOPMENT.
 The Players( Stack holders):

The software process (and every software project) is populated by players who can be
categorized into one of five constituencies:

1. Senior managers: who define the business issues that influence on the project.
2. Project (technical) managers :who must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners who deliver the technical skills that are helps to develop a product or
application.
4. Customers who specify the requirements for the software to be engineered(developed)
5. End-users who interact with the software once it is released for Production use.

 Team Leaders:

 Project management is a people-intensive activity

 MOI model of leadership:

23
Page

Compiled By Mahesh MCA

 21

 Motivation. The ability to encourage (by ―push or pull‖) technical people to

produce to their best ability.

 Organization. The ability to mold existing processes (or invent new ones) that

will enable the initial concept to be translated into a final product.

 Ideas or innovation. The ability to encourage people for development of a

particular software product or application

 The Software Team:

 Many human organizational structures for software developmentas there are

organizations that develop software

 Project factors that should be considered when planning the structure of

software engineering teams:
 The difficulty of the problem to be solved.
 The size of the resultant program(s) in lines of code or function points
 The time that the team will stay together (team lifetime).
 The degree to which the problem can be modularized.
 The required quality and reliability of the system to be built
 The rigidity of the delivery date.
 Agile Team:
An Agile team is a self organizing team that has anatomy to plan and make technical
decisions.

 Coordination and Communication Issues:

 There are many reasons that software projects get into trouble.
 Interoperability has become a key characteristic of many systems.
 New software must communicate with existing software and conform to
predefined constraints imposed by the system or product.
 To deal with them effectively, a software engineering team must establish
effective methods for coordinating the people who do the work.
 Formal communicationis accomplished through ―writing, structured meetings, and
other relatively noninteractive and impersonal communication channels‖ .

Compiled By Mahesh MCA

 22

 Electronic communication encompasses electronic mail, electronic bulletinboards,

and by extension, video-based conferencing systems.
2)The Product: Before a project can be planned

 product objectives
 scope should be established,
 alternative solutions should be considered,
 technical and management constraintsshould be identified.
Without this information, it is impossible to estimates the cost.

Software Scope:

 The first software project management activity is the determination of software scope.
 Scope is defined by answering the following questions:
 Context. How does the software to be built fit into a larger system, product, or
business context and what constraints are imposed as a result of the context?

 Information objectives. What customer-visible data objects are produced as output

from the software? What data objects are required for input?
 Function and performance. What function does the software perform to transform
input data into output? Are any special performance characteristics to be addressed?
Problem Decomposition:

Problem decomposition, sometimes called partitioning or problem elaboration, is an

activity that sits at the core of software requirements analysis .

 Decomposition is applied in two major areas:

(1) The functionality that must be delivered and

(2) The process that will be used to deliver it.

 Software functions, described in the statement of scope, are evaluated and refined to
provide more detail prior to the beginning of estimation
3) The Process

 A software process provides the framework from which a comprehensive plan for
software development can be established..

Compiled By Mahesh MCA

 23

 umbrella activities—such as software quality assurance, software configuration

management,and measurement—overlay the process model
 A wide array of software engineering paradigms include:
• The linear sequential model

• The prototyping model

• The RAD model

• The incremental model

• The spiral model

 The project manager must decide which process model is most appropriate for
(1)The customers who have requested the product and the people who will do the
work.

(2) The characteristics of the product itself.

(3) The project environment in which the software team works.

Process Decomposition

 Once the process model has been chosen, the common process framework (CPF) is

adapted to it.

 ―How do we accomplish this CPF activity?‖

Compiled By Mahesh MCA

 24

 For example, a small,relatively simple project might require the following work tasks

for the customer communication activity:

1. Develop list of clarification issues.

2. Meet with customer to address clarification issues.

3. Jointly develop a statement of scope.

4. Review the statement of scope with all concerned.

5. Modify the statement of scope as required.

4)The Project

 In order to avoid project failure, a software project manager and the software
engineers who build the product must avoid a set of common warning signs that
lead to good project management.
 In order to manage a successful software project, we must understand what can go
wrong and how to do it right.
 In a software projects one defines ten signs that indicate that an information
systems project is in jeopardy:
1. Software people don’t understand their customer’s needs.

2. The product scope is poorly defined.

3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs change [or are ill-defined].

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost [or was never properly obtained].

9. The project team lacks people with appropriate skills.

10. Managers [and practitioners] avoid best practices and lessons learned.

Compiled By Mahesh MCA

 25

Write about the W5HH PRINCIPLES

 Barry Boehm [BOE96] states:

 ―you need an organizing principle that scales down to provide simple [project] plans

for simple projects.‖

 He calls it the WWWWWHH principle, after a series of questions that lead to a

definition of key project characteristics and the resultant project plan:

 Why is the system being developed?

The answer to this question enables all parties to assess the validity of
business reasons for the software work.

 What will be done, by when?

The answers to these questions help the team to establish a project schedule by

identifying key project tasks that are required by the customer.

 Who is responsible for a function?

The role and responsibility of each member of the software team must be defined.

 Where are they organizationally located?

Not all roles and responsibilities reside within the software team itself. The customer,

users, and other stakeholders also have responsibilities.

 How will the job be done technically and managerially?

Once productscope is established, a management and technical strategy for the project

mustbe defined.

 How much of each resource is needed?

The answer to this question is derived by developing estimates based on answers to

earlier questions

Compiled By Mahesh MCA

 26

PROCESS AND PROJECT METRICS

1 Write about Process and Project Metrics

 Metrics

• Software process and project metrics are quantitative measures

• They are a management tool

• They offer the effectiveness of the software process and the projects that are
conducted using the process as a framework.

• Basic quality and productivity data are collected

• These data are analyzed, compared against past averages, and assessed

• The goal is to determine whether quality and productivity improvements have

occurred

• The data can also be used to pinpoint problem areas

• Remedies can then be developed and the software process can be improved

 Metrics in the Process Domain

• Process metrics are collected across all projects and over long periods of time.

• They are used for making strategic decisions.

• The only way to know how/where to improve any process is to

Compiled By Mahesh MCA

 27

– Measure specific attributes of the process.

– Develop a set of meaningful metrics based on these attributes.

– Use the metrics to provide indicators that will lead to a strategy for
improvement.

• We measure the effectiveness of a process by deriving a set of metrics based on

outcomes of the process such as

– Errors uncovered before release of the software

– Defects delivered to and reported by the end users

– Work products delivered

– Human effort expended

– Calendar time expended

– Conformance to the schedule

– Time and effort to complete each generic activity

Etiquette of Process Metrics

• Use common sense and organizational sensitivity when interpreting metrics data

• Provide regular feedback to the individuals and teams who collect measures and
metrics

• Don’t use metrics to evaluate individuals

• Work with practitioners and teams to set clear goals and metrics that will be used
to achieve them

• Never use metrics to threaten individuals or teams

 Metrics in the Project Domain

• Project metrics enable a software project manager to

– Assess the status of an ongoing project

– Track potential risks

– Uncover problem areas before their status becomes critical

– Adjust work flow or tasks

– Evaluate the project team’s ability to control quality of software work

products

Compiled By Mahesh MCA

 28

• Many of the same metrics are used in both the process and project domain

• Project metrics are used for making tactical decisions

– They are used to adapt project workflow and technical activities

Use of Project Metrics

• The first application of project metrics occurs during estimation

– Metrics from past projects are used as a basis for estimating time and
effort

– As a project proceeds, the amount of time and effort expended are

compared to original estimates

• Project metrics are used to

– Minimize the development schedule by making the adjustments necessary

to avoid delays and mitigate potential problems and risks

– Assess product quality on an ongoing basis and, when necessary, to

modify the technical approach to improve quality

2 .What are the Categories of Software Measurement

There are the two Categories of Software Measurement

– Direct measures of the

• Software process (cost, effort, etc.)

• Software product (lines of code produced, execution speed, defects

reported over time, etc.)

– Indirect measures of the

• Software product (functionality, quality, complexity, efficiency,

reliability, maintainability, etc.)

Project metrics can be consolidated to create process metrics for an organization by using

 Size-oriented Metrics

• Derived by normalizing quality and/or productivity measures by considering the

size of the software produced

• Thousand lines of code (KLOC) are often chosen as the normalization value

Compiled By Mahesh MCA

 29

• Metrics include

– Errors per KLOC - Errors per person-month

– Defects per KLOC - KLOC per person-month

– Dollars per KLOC - Dollars per page of documentation

– Pages of documentation per KLOC

• Size-oriented metrics are not universally accepted as the best way to measure the
software process

• Opponents argue that KLOC measurements

– Are dependent on the programming language

– Penalize well-designed but short programs

– Cannot easily accommodate nonprocedural languages

– Require a level of detail that may be difficult to achieve

 Function-oriented Metrics

 Function-oriented metrics use a measure of the functionality delivered by the

application as a normalization value

 Most widely used metric of this type is the function point:

FP = count total * [0.65 + 0.01 * sum (value adj. factors)]

Compiled By Mahesh MCA

 30

 Function point values on past projects can be used to compute, for example, the
average number of lines of code per function point (e.g., 60)

 LOC Per Function Point

Language Average Median Low High

Ada 154 -- 104 205

Assembler 337 315 91 694

C 162 109 33 704

C++ 66 53 29 178

COBOL 77 77 14 400

Java 55 53 9 214

PL/1 78 67 22 263

Visual Basic 47 42 16 158

Web Engineering Project Metrics :

Measures that can be collected are

Number of static Web pages the end-user has no control over the content displayed
on the page
Number of dynamic Web pages end-user actions result in customized content
displayed on the page
Number of internal page links (internal page links are pointers that provide a
hyperlink to some other Web page within the WebApp
Number of persistent data objects As the number of persistent data objects grows
the complexity of webapps also grows
Number of external systems interfaced As the requirement for interfacing grows,
system complexity and development effort also increases

Compiled By Mahesh MCA

 31

Number of static content objects They encompass graphical,audio,video

information incorporated into the webapp
Number of dynamic content objects Generated based on end-user actions
Number of executable functions An executable function provides some
computational service to end-user. As number of functions grows construction effort
increasesWe can define a metric that reflects degree of end-user customization for
webapp to effort expended on web-project
Nsp=number of static pages

Ndp=number of dynamic pages

Customization index C=Ndp/(Ndp+Nsp)

Object-oriented Metrics

 The set of metrics for oo projects are

 Number of scenario scripts (i.e., use cases)

• This number is directly related to the size of an application and to the

number of test cases required to test the system

 Number of key classes (the highly independent components)

• Key classes are defined early in object-oriented analysis and are central to
the problem domain

• This number indicates the amount of effort required to develop the

software

 Number of support classes

• This number indicates the amount of effort and potential reuse

 Average number of support classes per key class

• Estimation of the number of support classes can be made from the number
of key classes

• GUI applications have between two and three times more support classes
as key classes

• Non-GUI applications have between one and two times more support
classes as key classes

 Number of subsystems

Compiled By Mahesh MCA

 32

• A subsystem is an aggregation of classes that support a function that is

visible to the end user of a system

3.Metrics for Software Quality Correctness

These are the measures of software quality

Correctness. A program must operate correctly or it provides little value to its users.
Correctness is the degree to which the software performs its required function.
Maintainability. Software maintenance and support accounts for more effort than any
other software engineering activity. Maintainability is the ease with which a program can
be corrected if an error is encountered, adapted if its environment changes, or enhanced if
the customer desires a change in requirements.
A simple time-oriented metric is mean-time-to-change (MTTC), the time it takes to
analyze the change request
Integrity. Software integrity has become increasingly important in the age of cyber
terrorists and hackers. This attribute measures a system’s ability to withstand attacks
(both accidental and intentional) to its security.
To measure integrity, two additional attributes must be defined: threat and
security.
Threat is the probability (which can be estimated or derived from empirical evidence)
that an attack of a specific type will occur within a given time. Security is the probability
(which can be estimated or derived from empirical evidence) that the attack of a specific
type will be repelled.

The integrity of a system can then be defined as:

Defect Removal Efficiency

• Defect removal efficiency provides benefits at both the project and process level.

• It indicates the percentage of software errors found before software release

• It is defined as DRE = E / (E + D)

– is the number of errors found before delivery of the software to the end
user

– is the number of defects found after delivery

Compiled By Mahesh MCA

 33

4 .Integrating Metrics within the Software Process

To be an effective aid in process improvement and/or cost and effort estimation, baseline data
must have the following attributes:
(1) Data must be reasonably accurate—―guestimates‖ about past projects are to be avoided,
(2) Data should be collected for as many projects as possible
(3) Measures must be consistent (for example,a line of code must be interpreted consistently
across all projects for which data are collected)
(4) Applications should be similar to work that is to be estimated—it makes little sense to use
a baseline for batch information systems work to estimate a real-time, embedded application.
Metrics Collection, Computation, and Evaluation:

The process for establishing a metrics baseline is illustrated in below diagram. Ideally,
data needed to establish a baseline have been collected in an ongoing manner.

Compiled By Mahesh MCA

 34

SOFTWARE ESTIMATION AND ESTIMATION MODELS

Write about software estimation

 Estimating is important activity need not be conducted in a haphazard manner.

 Estimation risk is measured by the degree of uncertainty in the quantitative estimates

established for resources, cost, and schedule.

 If project scope is poorly understood or project requirements are subject to change,

uncertainty and risk become dangerously high.

 project manager should not become obsessive about estimation.

 The Project Planning Process

 The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule.

 These estimates are made within a limited time frame at the beginning of a software
project and should be updated regularly as the project progresses.

Software scope and feasibility

 Software scope describes the functions and features that are to be delivered to end
users.

 Scope is defined by using one of the two techniques:

1. A narrative description of software scope is developed after communication with

all stakeholders.
2. A set of use-cases is developed by end-users

 Functions described in the statement of scope are evaluated prior to the beginning of
estimation.

 Because both cost and schedule estimates are functionally oriented,

Resources

 The second software planning task is estimation of the resources required to

accomplish the software development effort. Figure

Compiled By Mahesh MCA

 35

1. Human Resources

 The planner begins by evaluating scope and selecting the skills required to complete
development.

 Both organizational position (e.g., manager, senior software engineer) and specialty
(e.g., telecommunications, database, and client/server) are specified.

 The number of people required for a software project can be determined only after
an estimate of development effort (e.g., person-months) is made.

2 .Reusable Software Resources

 Component-based software engineering (CBSE)5 emphasizes reusability—that is, the

creation and reuse of software building blocks.

 Off-the-shelf components. Existing software that can be acquired from a third party
or that has been developed internally for a past project.

 Full-experience components. Existing specifications, designs, code, or test data

developed for past projects that are similar to the software to be built for the current
project.

Compiled By Mahesh MCA

 36

 Partial-experience components. . Software components that must be built by the

soft-ware team specifically for the needs of the current project.

3.Environmental Resources

 The environment that supports the software project, often called the software
engineering environment (SEE), incorporates hardware and software.

 Hardware provides a platform that supports the tools (software) required to produce
the work products that are an outcome of good software engineering practice

Software Project Estimation

To achieve reliable cost and effort estimates, a number of options arise:

1. Delay estimation until late in the project (obviously, we can achieve100% accurate
estimates after the project is complete!).

2. Base estimates on similar projects that have already been completed.

3. Use relatively simple decomposition techniques to generate project cost and

Effort estimates.

4. Use one or more empirical models for software cost and effort estimation.

DECOMPOSITION TECHNIQUES

 Software project estimation is a form of problem solving.

 We decompose the problem, from two different points of view:

 Decomposition of the problem

 Decomposition of the process.

 Estimation uses one or both forms of partitioning.

 But before an estimate can be made, the project planner must understand the
scope of the software to be built and generate an estimate of its ―size.‖

Software Sizing

 The accuracy of a software project estimate is predicated on a number of things:

(1) The degree to which the planner has properly estimated the size of the product to
be built;

(2) The ability to translate the size estimate into human effort, calendar time,

 Problem-Based Estimation

Compiled By Mahesh MCA

 37

 LOC and FP data are used in two ways during software project estimation:

(1) As an estimation variable to "size" each element of the software

(2) As baseline metrics collected from past projects with estimation variables
to develop cost and effort projections.

 LOC and FP estimation are distinct estimation techniques

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

 That is, projects should be grouped by team size, application area, complexity, and
other relevant parameters.

An Example of LOC-Based Estimation

 As an example of LOC and FP problem-based estimation techniques,

 let us consider a software package to be developed for a computer-aided design application

for mechanical components.

 Using the System Specification as a guide, a preliminary statement of software scope can be
developed:

For our purposes, we assume that further refinement has occurred and that the following
major software functions are identified:

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

Following the decomposition technique for LOC, an estimation table, shown in Figure 5.3,
is developed. A range of LOC estimates is developed for each function. For example, the
range of LOC estimates for the 3D geometric analysis function is optimistic 4600 LOC,
most likely—6900 LOC, and pessimistic—8600 LOC.

Compiled By Mahesh MCA

 38

An Example of FP-Based Estimation

 Decomposition for FP-based estimation focuses on information domain values

rather than software functions.

 Referring to the function point calculation table presented in Figure

 The project planner estimates inputs, outputs, inquiries, files, and external
interfaces for the CAD software.

 For the purposes of this estimate, the complexity weighting factor is assumed to be average.

 Process-Based Estimation

 The process is decomposed into a relatively small set of tasks and the effort required
to accomplish each task is estimated.

 Like the problem-based techniques, process-based estimation begins with a

delineation of software functions obtained from the project scope.

 A series of software process activities must be performed for each function.

 Functions and related software process activities may be represented as part of a

table similar to the one presented in Figure.

Compiled By Mahesh MCA

 39

-----------------------------------

Explain EMPIRICAL ESTIMATION MODELS

 An estimation model for computer software uses empirically derived formulas to

predict effort as a function of LOC or FP.

The Structure of Estimation Models

A typical estimation model is derived using regression analysis on data collected from
past software projects. The overall structure of such models takes the form .

where A, B, and C are empirically derived constants,

E is effort in person-months,

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

Among the many LOC-oriented estimation models proposed in the literature are

Compiled By Mahesh MCA

 40

The COCOMO II Model (COnstructive COst MOdel)

Application composition model. Used during the early stages of software engineering,
when prototyping of user interfaces, consideration of software and system interaction,
assessment of performance, and evaluation of technology maturity are paramount.

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.

The Software Equation

The software equation [PUT92] is a dynamic multivariable model that assumes a specific
distribution of effort over the life of a software development project.

where E = effort in person-months or person-years

t = project duration in months or years

Compiled By Mahesh MCA

 41

B = ―special skills factor‖16

P = ―productivity parameter‖ that reflects:

• Overall process maturity and management practices

• The extent to which good software engineering practices are used

• The level of programming languages used

• The state of the software environment

• The skills and experience of the software team

Compiled By Mahesh MCA

 42

RISK MANAGEMENT

Definition of Risk

 A risk is a potential problem – it might happen and it might not

(or)
 Risk concerns future happenings
 Risk involves change in mind, opinion, actions, places, etc.
 Risk involves choice and the uncertainty that choice entails
Two characteristics of risk
 Uncertainty – the risk may or may not happen, that is, there are no 100% risks
(those, instead, are called constraints)
 Loss – the risk becomes a reality and unwanted consequences or losses occur
 Types of Risk (Risk Categorization)

 Project risks
 They threaten the project plan
 If they become real, it is likely that the project schedule will slip and that costs
will increase
Technical risks
 They threaten the quality and timeliness of the software to be produced
 If they become real, implementation may become difficult or impossible
Business risks
 They threaten the viability of the software to be builtIf they become real, they
jeopardize the project or the product

Sub-categories of Business risks

 Market risk – building an excellent product or system that no one really
wants
 Strategic risk – building a product that no longer fits into the overall business
strategy for the company
 Sales risk – building a product that the sales force doesn't understand how to
sell
 Management risk – losing the support of senior management due to a change
in focus or a change in people

Compiled By Mahesh MCA

 43

 Budget risk – losing budgetary or personnel commitment

 Known risks
 Those risks that can be uncovered after careful evaluation of the project plan.

Predictable risks
 Those risks that are extrapolated from past project experience (e.g., past
turnover)
Unpredictable risks
 Those risks that can and do occur, but are extremely difficult to identify in
advance.
 RISK STRATAGIES

 Reactive risk strategies

 "Don't worry, I'll think of something"

 The majority of software teams and managers rely on this approach

 Nothing is done about risks until something goes wrong
 Crisis management is the choice of management techniques
 Proactive risk strategies
 Primary objective is to avoid risk and to have a contingency plan in
place to handle unavoidable risks in a controlled and effective manner
 Steps for Risk Management

1. Identify possible risks; recognize what can go wrong

2. Analyze each risk to estimate the probability that it will occur and the impact

(i.e., damage) that it will do if it does occur

3. Rank the risks by probability and impact

- Impact may be negligible, marginal, critical, and catastrophic

4. Develop a contingency plan to manage those risks having high probability and

high impact

 Risk Identification:

 Risk identification is a systematic attempt to specify threats to the project plan

 By identifying known and predictable risks, the project manager takes a first step
toward avoiding them when possible and controlling them when necessary

Compiled By Mahesh MCA

 44

 Generic risks
 Risks that are a potential threat to every software project
Product-specific risks
 Risks that can be identified only by those a with a clear understanding of the
technology, the people, and the environment that is specific to the software that
is to be built
 This requires examination of the project plan and the statement of scope
 "What special characteristics of this product may threaten our project plan?"
 Risk Projection/Estimation Steps :
1. Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low,

10-high)

2. Delineate the consequences of the risk

3. Estimate the impact of the risk on the project and product

4 .Note the overall accuracy of the risk projection so that there will be no

misunderstandings

Risk Risk Probability Impact (1- RMMM

Summary Category 4)

Contents of a Risk Table

An effective strategy for dealing with risk must consider three issues

Risk mitigation (i.e., avoidance) Risk monitoring

Risk management and contingency planning

Compiled By Mahesh MCA

 45

Risk Mitigation Monitoring and Management

Its goal is to assist project team in developing a strategy for dealing with risk

If a software team adopts a proactive approach to risk, avoidance is always the best strategy.
This is achieved by developing a plan for risk mitigation. For example, assume that high staff
turnover is noted as a project risk, r1. Based on past history and management intuition, the
likelihood, l1, of high turnover is estimated to be 0.70 percent, and the impact, x1, is
projected at level 2.

To mitigate this risk, project management must develop a strategy for reducing turnover.
Among the possible steps to be taken are

 Meet with current staff to determine causes for turnover

 Mitigate those causes that are under your control before the project starts.
 Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 Organize project teams so that information about each development activity is
widely dispersed.
 Define work product standards and establish mechanisms to be sure that all
models and documents are developed in a timely manner.
 Conduct peer reviews of all work
 Assign a backup staff member for every critical technologist.
As the project proceeds, risk monitoring activities commence

In the case of high staff turnover, the following factors can be monitored:

 General attitude of team members based on project pressures.

 The degree to which the team has jelled.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
In addition to monitoring these factors, the project manager should monitor the effectiveness
of risk mitigation steps. For example, a risk mitigation step noted here called

Compiled By Mahesh MCA

 46

Risk management and contingency planning assumes that mitigation efforts have failed
and that the risk has become a reality. Continuing the example, the project is well underway
and a number of people announce that they will be leaving. If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team.

In addition, the project manager may temporarily refocus resources to those functions that are
fully staffed, enabling newcomers who must be added to the team to ―get up to speed.‖ Those
individuals who are leaving are asked to stop all work and spend their last weeks in
―knowledge transfer mode.‖

It is important to note that RMMM steps incur additional project cost. For example, spending
the time to "backup" every critical technologist costs money.

RMMM PLAN

1)Risk Avoidance(mitigation) Proactive planning for risk avoidance. This is achieved by

developing a plan for risk mitigation.

2)Risk Monitoring what factors can we track that will enable us to determine if the risk is
becoming more or less likely?

 Assessing whether predicted risk occur or not

 Ensuring risk aversion steps are being properly applied
 Collection of information for future risk analysis
 Determine which risks caused which problems

Compiled By Mahesh MCA

 47

PROJECT SCHEDULING

What is project scheduling? Explain different techniques for project scheduling?

Project Scheduling

 Project scheduling is concerned with the techniques that can be employed to

manage the activities that need to be undertaken during the development of a
project.

Basic Principles:
Like all other areas of software engineering, a number of basic principles guide software
project scheduling:
Compartmentalization. The project must be compartmentalized into a number of manageable
activities and tasks. To accomplish compartmentalization, both theproduct and the process
are refined.
Interdependency. The interdependency of each compartmentalized activity ortask must be
determined. Some tasks must occur in sequence, while others can occur in parallel. Some
activities cannot commence until the work product produced by another is available. Other
activities can occur independently.
Time allocation. Each task to be scheduled must be allocated some number of work units
(e.g., person-days of effort). In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies and whether work will be
conducted on a full-time or part-time basis.
Effort validation. Every project has a defined number of people on the software team. As
time allocation occurs, you must ensure that no more than the allocated number of people has
been scheduled at any given time.
Defined responsibilities. Every task that is scheduled should be assigned to a specific team
member.
Defined outcomes. Every task that is scheduled should have a defined outcome.
For software projects, the outcome is normally a work product (e.g., the design of a
component) or a part of a work product. Work products are often combined in deliverables.
Defined milestones. Every task or group of tasks should be associated with a
project milestone.

Compiled By Mahesh MCA

 48

DEFINING A TASK NETWORK:

A task network, also called an activity network, is a graphic representation of the
task flow for a project.

Scheduling of a software project does not differ greatly from scheduling of any
multitask engineering effort.
Program evaluation and review technique (PERT) and the critical path method (CPM)
are two project scheduling methods that can be applied to software development.
Interdependencies among tasks may be defined using a task network. Tasks,sometimes called
the project work breakdown structure (WBS), are defined for the product as a whole or for
individual functions.
Both PERT and CPM provide quantitative tools that allow you to
(1) Determine the critical path—the chain of tasks that determines the duration of the project
(2) Establish ―most likely‖ time estimates for individual tasks by applying statistical models
(3) Calculate ―boundary times‖ that define a time ―window‖ for a particular task

Compiled By Mahesh MCA

 49

Time-Line Charts (or) Gantt charts

The use of Gantt charts started during the industrial rev-olution of the late 1800's. An early
industrial engineer named Henry Gantt developed these charts to improve factory efficiency.
Gantt charts are developed using bars to represent each task. The length of the bar shows how
long the task is expected to take to complete. Duration is easily shown on Gantt charts.

Once the information necessary for the generation of a time-line chart has been input, the
majority of software project scheduling tools produce project tables—a tabular listing of all
project tasks, their planned and actual start and end dates, and a variety of related information

CPM models the activities and events of a project as a network. Activities are shown as
nodes on the network and events that signify the beginning or ending of activities are shown
as arcs or lines between the nodes
Steps in CPM Project Planning
1.Specify the individual activities.
2.Determine the sequence of those activities.
3.Draw a network diagram.
4.Estimate the completion time for each activity.

Compiled By Mahesh MCA

 50

5.Identify the critical path (longest path through the network)

6.Update the CPM diagram as the project progresses
PERT
The Program Evaluation and Review Technique.(PERT) is a network model that allows for
randomness in activity completion times.PERT is typically represented as an activity on arc
network, in which the activities are rep-resented on the lines and milestones on the nodes.

Steps in the PERT Planning Process

PERT planning involves the following steps:
1.Identify the specific activities and milestones.
2.Determine the proper sequence of the activities.
3.Construct a network diagram.
4.Estimate the time required for each activity.
5.Determine the critical path.6.Update the PERT chart as the project progresses.

Compiled By Mahesh MCA