Algorithmic cost models:

1.Algorithmic cost models are bottom-up cost estimators.

Software cost estimation techniques:
Within most organizations, software cost estimates are
based onj past performance. The cost and productivity
data must be collected on current project in order to
estimate future ones.
The two top-down cost estimation technique which we
are going to discuss..
1. Expert Judgment 2. Delphi cost Estimation
Expert Judgment:
2.The Constructive Cost Model (CoCoMo) is an algorithmic
cost model described in BOE81.
3.CoCoMo to provide nominal estimates of programmer-
months and development schedule for a program, unit,
based on the estimated number of Delivered Source
Instructions (DSI) in the unit Effort.
4.The cocomo incorporates a number of assumptions.
The following example of algorithmic cost estimation using
cocomo is adapted from Boehm(BOE 81).

The most widely used cost estimation technique is 1.The product to be developed is a 10-KDSI embedded mode
expert judgment. It is an inherently top-down estimation software product (Systems programs).
technique.
2.The nominal estimates of programmer-months and
Expert judgment relies on the experience, background development schedule are got from the equations
and business sense of one or more key people in the
1.M = 2.8*(KDSI)** 1.20 = 2.8* (10)** 1.20 = 44.4
organization.
2. TDEV = 2.5 * (PM) * * 0.32 '= 2.5 * (44) * * 0.32 = 8.4
Delphi cost estimation:
3.Effort multipliers are used to adjust the estimate for off-
The Delphi technique can be adapted to software cost
nominal aspects of the project. The effort multipliers for this
estimation in the following manner.
project are presented in Table 3.5.
The following approach is a variation on the standard
4.Effort multipliers are used to adjust the estimate for off-
Delphi technique that increases communication while
nominal aspects of the project. The effort multipliers for this
preserving anonymity,
project are presented in Table 3.5.
1.The co-ordinator provides each estimator with a
System Definition and an estimation form.

2.The estimators study the definition and the co-

ordinator calls a group meeting so that estimators can Multiplier Rationale
discuss estimation issues with the co-ordinator and one-
another, Reliability . No serious recovery
problems(nominal)
3.Estimators complete their estimates anonymously. Data base 20,000 bytes (low)
4.The co-ordinator prepares a summary of the
Complexity very high)
estimates, but does not record/any rationales.

5.The co-ordinator calls a group meeting to focus on Timing high

issues where the estimates vary widely.
Storage high
6.Estimators complete another estimate, again
anonymously. The process is iterated for as many rounds Machine (nominal
as necessary.
Turnaround (nominal
7.After each round of estimation, the co-ordinator
discussed with each estimator in order to resolve the Analysts high
differences.
Programmers high
8.These discussions are necessary as it is required to
arrive at a consensus estimate at least after several
rounds of estimates.

Multiplier Rationale
Experience nominal
Experience loco
Experience nominal
Practices high
Tools loco
Schedule nominal
The cocomo incorporates a number of assumptions for
example, the nominal application programs equations
apply in the following types of situations.
1.Small to medium size projects (2k to 32k DSI)
2.Familiar application area
3.Stable, well- understood virtual machine
4.In-house development effort
5.Effort multipliers are used to modify these assumptions
6.The following activities are covered by the estimates.
7.Covers design through acceptance testing.
Cost estimation procedure using COCOMO:
1.Identify all subsystems and modules in the product.
2.Estimate the size of each module and calculate the size
of each subsystem and total system.
1.Specify module - level effort multipliers for each
module.
2.The module - level multipliers are product complexity,
programmer capability, virtual machine
3.experience and programming language experience.
4.Compute the module effort and development time
estimates for each module using the nominal estimator
equations and the module-level effort multipliers.
1. Specify the remaining 11 effort multipliers for
each subsystem.
Unit 2 chp 2
Software Requirements:
1.There are two sub phases in the analysis phase. They are
planning and software requirements definition.
2.The outcome of planning are the system definition, the
project Plan and the preliminary User's Manual. The
outcome of the software requirements definition activity is
recorded in the Software requirements Specification.
3.Formal notations are used as appropriate. Depending on
the size and complexity of the product, the size of the
software requirements document may vary from few pages
to several volumes.
The Software Requirements Specification:
Section 1: Product overview and summary
Section 2: Development, Operating and Maintenance
Environments
Section 3: External Interfaces and data flow
Section 4: Functional Requirements
Section 5: Performance Requirements
Section 6: Exception Handling
Section 7: Early subsets and Implementation Priorities
Section 8: Foreseeable Modifications and Enhancements
Section 9: Acceptance criteria
Section 10: Design Hints and Guidelines
Section 11: Cross-Reference Index
Section 12: Glossary of terms
The Software Requirements Specification:
● There are a number of desirable properties that a
Software Requirements Specification should
process.
1.Correct 2.Complete 3.Consistent 4. unambiguous
5.Functional 6. Verifiable 7. Traceable 8. Easily changed
● If the requirements specification is incorrect and
incomplete then the resultant software product will
satisfy the requirements but not the customers
need.
1.An inconsistent specification states contradictory
requirements in different parts of the document.
2.Software requirements should be functional in nature, i.e.
what is required is specified without specifying the
implementations details. This provides maximum flexibility
for the product designers.
3.Enhancements to the desirable properties of the Software
Requirements Specification can be done using the formal
notations and automated tools.
Formal Specification Techniques:
1.Formal notations are used to specify the functional
characteristics of a software product in the requirements
document.
2.The requirements document will be concise and the
functional characteristics can be expressed in an
unambiguous manner by using the formal notations.
3.These notations support formal reasoning about the
functional specifications and they provide a basis for
verification of the resulting software product.
Unit 5
SOFTWARE QUALITY ASSURANCE:
1.Software quality assurance is simply a way to assure
quality in the software.
2.SQA is a process which works parallel to development of
software.
3.SQA produce high quality software and those are benifical.
4.High quality application means short development time.
5.High quality application saves time and cost.
SQA ACTIVITIES:
PREPARES AN SQA PLAN FOR A PROJECT:
1.The plan identifies.
2.Evaluation to be performed.
3.Audits and reviews to be performed.
4.Procedure for error reporting and tracking.
5.Documents to be produced by the SQA group.
6.Amount of feedback provided to the software project
team.
SOFTWARE REVIEWS:
1.Software reviews are filter for the software process.
2.Purifies software engineering work products.
3.Applied at various point of software engineering activities to
detect and remove errors.
COST IMPACT OF SOFTWARE DEFECTS:
1.Defect imply a quality problem that is discovered after the
software has been released to end user.
2.Error is a quality problem discovered before software has
been delivered to end user .
3.Using review techniques the large percentage of errors can
be detected and removed so that cost can be reduced.
DEFECTS AMPLIFICATION AND REMOVAL:
A Defect amplification model can be used to illustrate the
generation detection of errors during the design and code
generation actions of a software process.
Formal technical review :
Formal Technical Review (FTR) is a software quality control
activity performed by software engineers.
It is an organized, methodical procedure for assessing and
raising the standard of any technical paper, including software
objects.
Finding flaws, making sure standards are followed, and
improving the product or document under review’s
overallquality are the main objectives of a fault tolerance
review (FTR). Although FTRs are frequently utilized in software
development, other technical fields can also employ the
concept.
THE REVIEW MEETING:-
1.Between 3, 4, and 5 people should be involved in the review.
2.preparation should occur, but it should be very short that is
at the most 2 hours of work for every person.
3.The short duration of the review meeting should be less than
two hours. Giventhese constraints, it should be clear that an
FTR focuses on specific (and small) parts of the overall
software.
At the end of the review, all attendees of FTR must Because the IOS 9001 :2000 standard is applicable
decide what to do. to all engineering discipline a special set of IOS
1.Accept the product without any modification. guidelines ( ISO 9000 -3) have been developed to
2.Reject the project due to serious error (once corrected, help interpret the standard for use in the software
another app needs to be reviewed), or
process.
3.Accept the product provisional (minor errors are
encountered and should be corrected, but no additional review IOS 9001 :2000 ADDRESS TOPIC SUCH AS;
will be required).
1.Quality System 2. Design Control
Review reporting and record-keeping:
3.Data Control 4.Traceability
1.during the ftr, the reviewer actively records all issues that
5.Corrective 6.Control The Quality Records
have been raised.
7.Document 8.Product Identification
2. at the end of the meeting all these issues raised are
consolidated and a review list is prepared. 9.Process Control 10.Testing

3.finally, a formal technical review summary report is prepared. 11.Contract Review 12.Preventive Action

A review summary report answers three questions: 13.Management Responsibility

1.What was reviewed?

2.Who reviewed it? For the software organization to become

3.What were the findings and conclusions? registered to ISO 9001 :2000.

THE ISO 9000 QUALITY STANDARDS

1.Iso stand for International Standard Organization.

2.iSo 9000 series of standards, development and published by

the ISo that defines, establish and maintain an effective “

Quality Assurance System” for manufacturing and service

industries.

3.A Quality Assurance System may be defined as the

organizational structures , responsibilities , procedures,

processes and resources for implementing Quality Assurance.

4.IOS 9000 describes a Quality Assurance System is a “

genetic term “ that can be applied to any business regardless

of the products or services offered.

ISO 9000:2000

1.ISO 9001 : 2000 is the Quality Assurance standards

that applies to Software Engineering.

2.The standard contains 20 requirements that must be

present for an effective Quality Assurance.