1. Software Planning

2. Problem Projects: Needs quantitative estimates and organized plan.
Requirement changes as the project proceeds
Important to define
1. Definition of problem
2. Scope of problem
3. Decomposition of problem

3. Software Scope First activity in Project Management
It can be the answers of
1. Context:
How to make the system fit for all levels?
What are the constraints for the same?
2. Information Objectives:
What visible objects are projected as output.
What input is required for the same.
3. Function and Performance:
Regular functions (Input to Output)
Special functions

4. Problem Decomposition
Defined as Partitioning
Sits at the core of Requirement analysis.
Two major areas:
1. Functionality – needs to be delivered.
2. The process – to deliver the same.
Software functions – evaluated in the beginning
Cost, Schedule estimation – based on decomposition
Some degree of decomposition – always good.

5. Software Metrics
Measurement can be applied • to the software process with the intent of improving • to assist in estimation, quality control, productivity assessment, and project control • to help assess the quality of technical work products and to assist in tactical decision making as a project proceeds

6. MEASURES , METRICS , AND INDICATORS
a measure provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some attribute of a product or process. a metric as " a quantitative measure of the degree to which a system, component, or process possesses a given attribute”. an indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself . A software engineer collects measures and develops metrics so that indicators will be obtained .

7. Project indicators enable a software project manager to assess the
status of an ongoing project
track potential risks
uncover problem areas before they "go critical“
adjust work flow or tasks
evaluate the project team's ability to control quality of software engineering work products.

8. Cont…

9. Project Metrics Used for strategic purposes
by a project manager and a software team to adapt project work
flow and technical activities .
Project metrics on estimation
effort and time duration estimates
Production rates
–pages of documentation,
–review hours,
–function points,
–delivered source lines

10. Con.. The intent of project metrics is twofold :
–to minimize the development schedule,
–to assess product quality on an ongoing basis and when
necessary, modify the technical approach to improve quality.
Every project should measure:
Inputs - measures of the resources (e.g., people, environment) required to do the work
Outputs - measures of the deliverables or work products
created during the software engineering process
Results - measures that indicate the effectiveness of the
deliverables

11. SOFTWARE MEASUREMENT
Direct measures (e.g., the length of a bolt) Indirect measures (e.g., the "quality" ) Direct measures –lines of code (LOC) –execution speed –memory size –defects reported over some set period of time Indirect measures ·functionality, quality, complexity, efficiency, reliability, ·maintainability and many other "abilities"

12. Size-Oriented Metrics Derived by normalizing quality and or productivity measures by considering the "size" of the software

13. Con..
A set of simple size -oriented metrics can be developed for each project:
errors per KLOC (thousand lines of code)
defects per KLOC
$ per LOC
pages of documentation per LOC
other interesting metrics:
errors/person-month
LOC per person-month
$/page of documentation

14. Function-Oriented Metrics
Use a measure of the functionality delivered by the application as a
normalization value. Function-oriented metrics were first proposed
by Albrecht.

15. Con..
Number of user inputs. Each user input that provides distinct application oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.
Number of user outputs. Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, and so on. Individual data items within a report are not counted separately.
Number of user inquiries. An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.
Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file), is counted.
Number of external interfaces. All machine readable interfaces (e.g., data files on tape or disk) that are used to transmit information to another system are counted.

16. COMPUTING FUNCTION POINTS
Once the above data have been collected, a complexity value is associated with each count. For determining whether a particular entry, –simple, –average, –complex. To compute function points (FP), FP = count-total x [ x SFi] The Fi ( i = 1 to 14) are "complexity adjustment values"

17. Con…

18. Con.. 2. Are data communications required?
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 on-line data entry require the input transaction 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 designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease o f use by the user?

19. Feature point metrics
FP doesn’t solve algorithmic complexity of a software.
It implies that developing efforts of two functionally same programs are same.
To resolve the same, feature point is proposed.
It includes additional parameter – algorithmic complexity.
More complexity of the function – greater efforts to develop it.
These are language independent and easily computed from SRS document.

20. Software Estimation
Determine size of the product. From the size estimate, determine the effort needed. From the effort estimate, determine project duration, and cost.

21. Software Cost Estimation

22. Three approaches
Empirical
Heuristic
Analytical

23. Cost Estimation Techniques
Empirical techniques: An educated guess based on past experience. Heuristic techniques: Assume that the characteristics to be estimated can be expressed in terms of some Mathematical expression. Analytical techniques: Derive the required results starting from certain simple assumptions.

24. Empirical Estimation Techniques
Expert Judgement: A guess made by an expert. Suffers from individual bias. Delphi Estimation: Overcomes some of the problems of expert judgement.

25. Expert Judgment Technique
Experts divide a software product into component units:
e.g. GUI, database module, data communication module, billing module, etc.
Add up the guesses for each of the components.
Subject to human errors and individual bias.
Experts may overlook some factors.
Understanding all the aspects would be difficult.

26. Delphi Estimation Team of Experts and a coordinator.
Experts carry out estimation independently.
Mention the rationale behind their estimation.
Coordinator notes down any extraordinary rationale.
Circulates among experts.
Experts re-estimate.
Experts never meet each other
To discuss their viewpoints.

27. Heuristic – COCOMO Model
COCOMO (COnstructive COst MOdel) proposed by Boehm.
Divides software product developments into 3 categories:
Organic
Semidetached
Embedded

28. Con.. Elaboration of Product classes
Organic:
Development of well understood appl. Program.
Size is very small.
Team members develop similar applications.
Semidetached:
If it contains the mix of experienced and inexperienced staff.
Embedded:
The software is strongly coupled to complex hardware, or real-time systems.

29. Con.. Software cost estimation is done through three stages:
Basic COCOMO,
Intermediate COCOMO,
Complete COCOMO.

30. Basic COCOMO Model Gives only an approximate estimation:
Effort = a1*(KLOC)a2
Tdev = b1*(Effort)b2
KLOC is the estimated kilo lines of source code,
a1,a2,b1,b2 are constants for different categories of software products,
Tdev is the estimated time to develop the software in months,
Effort estimation is obtained in terms of person months (PMs).

31. Development Effort Estimation
Organic :
Effort = 2.4*(KLOC)1.05 PM
Semi-detached:
Effort = 3.0*(KLOC)1.12 PM
Embedded:
Effort = 3.6*(KLOC)1.20 PM

32. Development Time Estimation
Organic:
Tdev = 2.5*(Effort)0.38 Months
Semi-detached:
Tdev = 2.5*(Effort)0.35 Months
Embedded:
Tdev = 2.5*(Effort)0.32 Months

33. Con. Development time sub linear function of product size.
When product size increases two times,
development time does not double.
Time taken:
almost same for all the three product categories.

34. Con.. Development time is roughly the same for
all the three categories of products:
For example, a 60 KLOC program can be
developed in approximately 18 months
regardless of whether it is of organic, semidetached, or embedded type.
There is more scope for parallel activities for
system and application programs,
than utility programs.

35. Intermediate COCOMO Basic COCOMO model assumes
effort and development time depend on product size alone.
However, several parameters affect effort
and development time:
Reliability requirements
Availability of CASE tools and modern facilities to the developers
Size of data to be handled

36. Con.. For accurate estimation,
the effect of all relevant parameters must be considered:
Intermediate COCOMO model recognizes this fact:
refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers).

37. Con.. If modern programming practices are used,
initial estimates are scaled downwards.
If there are stringent reliability requirements on the product :
initial estimate is scaled upwards.
Rate different parameters on a scale of one to three:
Depending on these ratings, multiply cost driver values with the estimate obtained using the basic COCOMO

38. Computer: Execution time, storage requirements, etc.
Cost driver classes:
Product: Inherent complexity of the product, reliability requirements of the product, etc.
Computer: Execution time, storage requirements, etc.
Personnel: Experience of personnel, etc.
Development Environment: Sophistication of the tools used for software development.

39. Shortcomings of two models
Both models:
consider a software product as a single homogeneous entity:
However, most large systems are made up of several smaller sub-systems.
Some sub-systems may be considered as organic type, some may be considered embedded, etc.
for some the reliability requirements may be high, and so on.

40. Complete COCOMO A Management Information System (MIS) for an
organization having offices at several places
across the country:
Database part (semi-detached)
Graphical User Interface (GUI) part (organic)
Communication part (embedded)
Costs of the components are estimated separately:
Summed up to give the overall cost of the system.

41. Con.. A Management Information System (MIS) for an
organization having offices at several places
across the country:
Database part (semi-detached)
Graphical User Interface (GUI) part (organic)
Communication part (embedded)
Costs of the components are estimated
separately:
summed up to give the overall cost of the system.