Project management Size & Effort Estimation Project Scheduling Configuration Management Unified Process- Changing Trends In Software Development Software Testing Fundamentals Planning Software Testing Black Box Testing White Box Testing

1. SOFTWARE
ENGINEERING
Presenter: Miss Arti Gavas10/03/2014

2. GOAL
Software Engineering should focus on imparting to
students the knowledge and skills that are needed
to successfully execute a commercial project of
a few person-months effort while employing
proper practices and techniques.

3. THE SOFTWARE PROBLEM
 If a student is said to build a software system (academic project)
of 10000 LOC, it would take 1 to 3 months to complete with
productivity of 5000 LOC/month!
 If a software organization is said to build such a system on be
half of client, it would take 10 months to complete with 1000
LOC/month!!!
 Why this difference in productivity in the two scenarios?
 Why is it that the same students who can produce software at a
productivity of a few thousand LOC per month while in college
end up producing only about a thousand LOC per month when
working in a company?

4. THE SOFTWARE PROBLEM
Continued...
 The answer, of course, is that two different things are being built in the
two scenarios.
 In the first, a student system is being built which is primarily meant for
demonstration purposes, and is not expected to be used later.
 On the other hand, an industrial-strength software system is built to
solve some problem of a client and is used by the client’s organization
for operating some part of business.
 A malfunction of such a system can have huge impact in terms of
financial or business loss, inconvenience to users, or loss of property
and life.
 Consequently, the software system needs to be of high quality with
respect to properties like reliability, usability, portability, etc.

5. SOFTWARE ENGINEERING
The software industry is largely interested in developing industrial-
strength software, and the area of software engineering focuses on
how to build such systems. That is, the problem domain for software
engineering is
industrial strength software.

6. Industrial Strength Software
Software engineering is defined as the systematic approach to
the development, operation, maintenance, and retirement of
software

7. COST, SCHEUDLE AND
QUALITY
 COST is measured in Lines of code (LOC) or thousands of
lines of code (KLOC).
 SCHEDULE is about time to market of a product should be
reduced. i.e. the cycle time from concept to delivery should be
small.
 QUALITY is one of the main mantras, and business strategies
are designed around it.
Unreliability of software
The software often does not do what it is supposed to do or does something it
is not supposed to do. Clearly, developing high-quality software is another
fundamental goal of software engineering.

8. CONTENTS
 Project management
 Size & Effort Estimation
 Project Scheduling
 Configuration Management
 Unified Process- Changing Trends In Software Development
 Software Testing Fundamentals
 Planning Software Testing
 Black Box Testing
 White Box Testing

9. Project Management Process
 To meet the cost, quality, and schedule
objectives, resources have to be
properly allocated to each activity for
the project.
 And progress of different activities has
to be monitored and corrective actions
to be taken when needed.
 All these activities are part of the
project management process.
 The activities in the management
process for a project can be grouped
broadly into three phases: planning,
monitoring and control, and termination
analysis.

10. Size & Effort Estimation
 Overall effort and schedule estimates are essential prerequisites
for planning the project.
 Helps us to answer the questions like:
 “is the project late?”
 “are there cost overruns?”
 “when is the project likely to complete?”
 “what will be a staffing level for a project during different
phases?”
 Two approaches of effort estimation:
 Top-Down Estimation Approach

11. COCOMO MODEL
 A function for determining initial effort from size
 where a and b are constants, and project size is generally in KLOC.
 After determining the initial estimate, some other factors are
incorporated for obtaining the final estimate.
 COCOMO uses a set of 15 different attributes of a project called cost
driver attributes.
 Each cost driver has a rating scale, and for each rating, a multiplying
factor is provided.

12. COCOMO MODEL Continued…
 The multiplying factors for
all 15 cost drivers are
multiplied to get the effort
adjustment factor (EAF).
 The final effort estimate,
E, is obtained by
multiplying the initial
estimate (Ei) by the EAF.
E = EAF * Ei
To the Example

13. COCOMO MODEL EXAMPLE
 Consider a system being built
for supporting auctions in an
University.
 From the use cases and other
requirements, it is decided that
the system will comprise a few
different modules. The modules
and their expected sizes is
shown in table.
 The total size of this software is
MODULE SIZE IN
LOC
Login 200
Payment 200
Administrator
interface
600
Seller functions 200
Buyer functions 500
View and
bookkeeping
300

14. COCOMO MODEL EXAMPLE
 We should estimate the
value of the different cost
drivers.
 Suppose we expect that:
 the complexity of the
system is high,
 the programmer capability is
low,
 and the application
experience of the team is low.
 All other factors have a
COCOMO ESTIMATION
Effort adjustment factor (EAF):
EAF = 1.15 * 1.17 * 1.13 = 1.52
Initial effort estimate (Ei):
Ei = 3.9 * 2 ^ .91 = 7.3 PM
Final adjusted effort estimate (E):
E = 1.52 * 7.3 = 11.1 PM
Different Cost Drivers

15. FUNCTION POINT (FP)
 FP based estimation use a measure of functionalities delivered by the
application.
 FPs are derived using an empirical relationship based on countable measures
of software information domain and assessment of software complexity.
 The project planner estimates:
 Inputs : user inputs.
 Outputs : system outputs like error messages, output screens, reports.
 Inquiries : queries to the system
 Internal files : internal database files etc.
 External interfaces : Network interfaces or interfaces of other applications.
 There are 14 complexity weighting factors those needs to be evaluated.

16. FUNCTION POINT Continued…
 Complexity
weighting factors
can be defined with
complexity values:
simple, average, or
complex.
 Determination of
complexity is
somewhat
subjective.
1 Does the system require reliable backup and recovery?
2 Are data communications required?
3 Are there distributed processing functions?
4 Is performance critical?
5 Will the system run in an existing, heavily utilized operational
environment?
6 Does the system require on-line data entry?
7 Does the data entry to be built over multiple screens or operations?
8 Are the master files updated on-line?
9 Are the inputs, outputs, files or inquiries complex?
10 Is the internal processing complex?
11 Is the code design to be reusable?
12 Are conversion and installation included in the design?
13 Is the system designed for multiple installations in different
organizations?

17. FUNCTION POINT EXAMPLE
 CAD software
 Lets assume the complexity weighting factor to be average.
 Computing function points:
Measurement parameter count simple average comple
x
total
Number of inputs 24 3 4 6 96
Number of outputs 16 4 5 7 80
Number of inquiries 22 3 4 6 88
Number of files 4 7 10 15 40
Number of external interfaces 2 5 7 10 14
Count TOTAL 318

18. FUNCTION POINT Example
Continued…
 Complexity weighting factors:
 ∑ (Fi) = 52
 FP_estimated
=count_total*[0.65 + 0.01* ∑ (Fi) ]
=318*[0.65+0.01*52]
FP_estimated = 373
 The organizational average productivity for
systems of this type is 6.5 FP/pm.
 Based on a burdened labor rate of $8000
per month, the cost per FP is
approximately $1230.
 Based on LOC estimates and historical
productivity data, the total estimated
project cost is $461,250 and the estimated
1 reliable backup and recovery 4
2 data communications 2
3 distributed processing 0
4 performance critical 4
5 existing operational environment 3
6 on-line data entry 4
7 Input transactions over multiple screens 5
8 master files updated 3
9 Information domain values complex 5
10 internal processing complex 5
11 code design for reuse 4
12 conversion and installation in design 3
13 multiple installations 5
14 application designed to facilitate change 5

19. Project Scheduling
Three methods:
Building WBS
Use of Gantt chart
PERT/CPM chart

20. WBS (WORK BREAKDOWN
STRUCTURE)

21. GANTT CHART

22. PERT(Program Evaluation Review Technique)/
CPM (Critical Path Method) CHART
 A PERT chart presents a graphic
illustration of a project as a network
diagram consisting of numbered nodes
representing events, or milestones in the
project linked by labeled directional lines
representing tasks in the project.
 The direction of the arrows on the lines
indicates the sequence of tasks. In the
diagram, for example, the tasks between
nodes 1, 2, 4, 8, and 10 must be
completed in sequence. These are called
dependent or serial tasks.
 The tasks between nodes 1 and 2, and
nodes 1 and 3 are not dependent on the
completion of one to start the other and
can be undertaken simultaneously. These
tasks are called parallel or concurrent

23. Configuration Management
 Changes continuously takes place in a software due to:
 Evolution of work products as project proceeds
 Bugs found
 Changes in requirement specifications
 All the changes must be reflected to the files containing
source, data or documentation.
 Software Configuration Management (SCM) is the
discipline for systematically controlling the changes that
take place during the development.

24. CM FUNCTIONALITIES &
MECHANISMS
 CM Functionalities:
 Give the latest version of a program
 Undo a change or revert back to a specified version
 Prevent unauthorized changes or deletions
 Gather all sources, documents and other information for the current
system
 CM Mechanisms:
 Configuration identification and base-lining
 Version control and version management
 Access control

25. CMM (CAPABILITY MATURITY
MODEL)
 Introducing changes in small increments based on the
current state of the process is captured through CMM
framework.
 CMM framework provides a general roadmap for process
improvement.
 CMM provides characteristics of each level, which can be
used to assess the current level of the process of an
organization.
 The movement from one level to the next level also
suggest the areas in which the process should be

26. CMM (CAPABILITY MATURITY
MODEL)
 Initial process (level 1)
 Ad-hoc, informal methods
 Repeatable process (level 2)
 Mgmt policies, cost & schedules are
tracked
 Defined level (level 3)
 Standardize software process
 Managed level (level 4)
 Predictable management
 Optimizing level(level 5)

27. Unified Process- Changing Trends In Software
Development
 Iterative process model
 designed for object-oriented development using the
Unified Modeling Language (UML)
Unified Process proposes that development of software be
divided into cycles, each cycle delivering a fully working
system.
 Each cycle is executed as a separate project whose goal is to
deliver some additional capability to an existing system.
 Hence, for a project, the process for a cycle forms the overall
process.

28. Unified Process Continued…
 Each cycle is broken into four consecutive
phases:
 Inception phase
 Elaboration phase
 Construction phase
 Transition phase
Each phase has a distinct purpose,
and completion of each phase is a
well defined milestone in the project
with some clearly defined outputs.

29. Unified Process Continued…
Phase Purpose Output
Inception
phase
Establish the goals and scope of the
project
Lifecycle objectives
milestone - VISION
Elaboration
phase
The architecture of the system is
designed
Lifecycle architecture
milestone
Construction
phase
The software is built and tested Initial operational
capability milestone
Transition
phase
Move the software from the
development environment to the
client’s environment
Product release
milestone

30. Software Testing Fundamentals
 To ensure quality of the final delivered software, software
defects will have to be removed.
 Though errors are detected after each phase by techniques
like inspections, some errors remain undetected.
 final code is likely to have some requirements errors and
design errors, in addition to errors introduced during the coding
activity.
 Two types of approaches for identifying defects in the software:
 Static: code is not executed but evaluated through some process or tools for locating
defects.

31. TESTING PROCESS
 The basic goal of the software development process is to
produce software that has no errors or very few errors.
 Testing is a quality control activity which focuses on identifying
defects (which are then removed).
 The testing process for a project consists of three high-
level tasks:
 test planning
 test case design
 test execution

32. TEST PLAN
 A test plan is a general document
for the entire project.
 Defines the scope, approach to be
taken, and the schedule of testing,
also identifies the test items for
testing and the personnel
responsible for the different
activities of testing.
 The inputs of test plan are:
 project plan
 requirements document
TEST PLAN
Test unit specification
Features to be tested
Approach for testing
Test deliverables
Schedule and task
allocation

33. TEST CASE DESIGN
 Details of testing a unit.
 Based on the approach specified in the test plan, and the
features to be tested, the test cases are designed and
specified for testing the unit.
 A test case specification in a document looks like:
Requirement
Number
Condition to
be tested
Test data and
settings
Expected
output

34. BLACK BOX TESTING
 The structure of the program is not considered.
 Test cases are decided solely on the basis of the requirements
or specifications of the program or module
 The tester only knows the inputs that can be given to the
system and what output the system should give.
 Also called functional or behavioral testing.
 Exhaustive testing is not possible, However, there are a
number of techniques or heuristics that can be used to select
test cases that have been found to be very successful in
detecting errors.

35. BLACK BOX TESTING
TECHNIQUES
 Equivalence class partitioning
 Divide the input domain into a set of equivalence classes
 If the program works correctly for a value, then it will work correctly
for all the other values in that class.
 If we can indeed identify such classes, then testing the program
with one value from each equivalence class is equivalent to doing
an exhaustive test of the program.
 Boundary value analysis
 programs that work correctly for a set of values in an equivalence
class fail on some special values. These values often lie on the
boundary of the equivalence class.

36. EQUIVALENCE CLASS
PARTITIONING
 Equivalence classes are usually formed by considering each
condition specified on an input as specifying a valid
equivalence class and one or more invalid equivalence
classes.
 For example,
 If an input condition specifies a range of value (say, 0 <
count < Max), then form a valid equivalence class with that
range and two invalid equivalence classes, one with values
less than the lower bound of the range (i.e., count < 0) and
the other with values higher than the higher bound (count >
Max).

37. BOUNDARY VALUE ANANLYSIS
 Select the boundary elements of the range and an invalid value
just beyond the two ends (for the two invalid equivalence
classes).
 For example,
 if the range is 0.0<=x<=1.0, then the test cases are 0.0, 1.0
(valid inputs), and −0.1, and 1.1 (for invalid inputs).
 Similarly, if the input is a list, attention should be focused on
the first and last elements of the list.
If an integer range is min to max,
then the six values are min−1, min, min+1, max−1, max,
max+1.

38. WHITE BOX TESTING
 Concerned with testing the implementation of the program.
 The intent of this testing is not to exercise all the different input
or output conditions but to exercise the different programming
structures and data structures used in the program.
 Also called structural testing.
 Test cases will force the desired coverage of different
structures.
 Unlike the criteria for functional testing, which are frequently
imprecise, the criteria for structural testing are generally quite
precise as they are based on program structures.

39. WHITE BOX TESTING
TECHNIQUES
 Statement Coverage:
 test case is executed in such a way that every statement of
the code is executed at least once.
 Branch/Decision Coverage:
 Test coverage criteria requires enough test cases such that
each condition in a decision takes on all possible outcomes
at least once, and each point of entry to a program
or subroutine is invoked at least once. That is, every branch
(decision) taken each way, true and false. It helps in
validating all the branches in the code making sure that

40. WHITE BOX TESTING TECHNIQUES
CONTINUED…
 Path Coverage:
 In this the test case is executed in such a way that every
path is executed at least once.
 All possible control paths taken, including all loop paths
taken zero, once, and multiple (ideally, maximum) items in
path coverage technique, the test cases are prepared
based on the logical complexity measure of a procedural
design. In this type of testing every statement in the
program is guaranteed to be executed at least one time.
Flow Graph, Cyclomatic Complexity and Graph Metrics

41. CYCLOMATIC COMPLEXITY
 Cyclomatic Complexity for a flow graph is computed in one of three ways:
 The numbers of regions of the flow graph correspond to the Cyclomatic
complexity.
 Cyclomatic complexity, V(G), for a flow graph G is defined as
V(G) = E – N + 2
where E is the number of flow graph edges and N is the number of flow
graph nodes.
 Cyclomatic complexity, V(G), for a graph flow G is also defined as
V(G) = P + 1

42. CYCLOMATIC COMPLEXITY
EXAMPLE
 Region, R= 6
 Number of Nodes = 13
 Number of edges = 17
 Number of Predicate Nodes = 5
 Cyclomatic Complexity, V( C) :
 V( C ) = R = 6;
Or
 V(C) = Predicate Nodes + 1
=5+1 =6
Or
 V( C)= E-N+2
= 17-13+2

43. FLOW GRAPH EXAMPLE
Read P
Read Q
IF P+Q > 100
THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF
Statement Coverage (SC):
 To calculate Statement
Coverage, find out the
shortest number of paths
following which all the nodes
will be covered.
 Here by traversing through
path 1A-2C-3D-E-4G-5H
all the nodes are covered.
So by traveling through only
one path all the nodes 12345
are covered,
 So the Statement coverage
in this case is 1.

44. FLOW GRAPH EXAMPLE
Read P
Read Q
IF P+Q > 100
THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF
Path Coverage (PC):
 Path Coverage ensures
covering of all the paths
from start to end.
 All possible paths are-
 1A-2B-E-4F
 1A-2B-E-4G-5H
 1A-2C-3D-E-4G-5H
 1A-2C-3D-E-4F
 So path coverage is 4.

45. Any Questions?
THANK YOU!