Sad Lec22 - Notes - Cocomo, Cmmi and Case Tool

Capability Maturity Model Integration
Capability Maturity Model Integration (CMMI) is a process improvement approach whose goal is to help organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. CMMI in software engineering and organizational development is a process improvement approach that provides organizations with the essential elements for effective process improvement. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide
CMM

developed by the Software Engineering Institute to help

organizations which develop software
to improve their software processes to assess the quality of their contractors
organizations which acquire software
Immature

organization
processes are improvised during the course of a project to resolve unanticipated crises products often delivered late and their quality is questionable
Mature
organization
organization-wide standard approach to software processes, known and accepted by all engineers focus on continuous improvement both in performance and product quality
The organization
Does
not have an environment for developing and maintaining software.

At
the time of crises, projects usually stop using all planned procedures and revert to coding and testing.
Effective management process having established which can be Practiced Documented Enforced Trained Measured Improvised
Standard
defined software engineering and management process for developing and maintaining software.
These
processes are put together to make a coherent
whole.
Quantitative
goals set for both software products and
processes.
The
organizational measurement plan involves determining the productivity and quality for all important software process activities across all projects.
Emphasis laid on
Process
improvement Tools to identify weaknesses existing in their processes Make timely corrections
Level 5 Optimizing
Focus Continuous Process Improvement
Process Areas
Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis and Resolution Organizational Environment for Integration Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Quality Productivity
4 Quantitatively Quantitative Managed Management
3 Defined
Process Standardization
2 Managed
Basic Project Management
1 Initial
None
11
Risk, Rework
COCOMO
is one of the most widely used software estimation models in the world was developed by Barry Boehm in 1981
It
COCOMO
predicts the effort and schedule for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity
COCOMO
has three different models that reflect the complexity:

the the
Basic Model
Intermediate Model the Detailed Model
and
Organic
Mode Relatively small, simple software projects Small teams with good application experience work to a set of less than rigid requirements Similar to the previously developed projects relatively small and requires little innovation
Semidetached
Mode Intermediate (in
size
and
Embedded
Mode
Software projects that must be developed within a set of tight hardware, software, and operational constraints.
Primary
cost driver is the number of Delivered Source Instructions (DSI) / Delivered Line Of Code developed by the project
COCOMO
estimates assume that the project will enjoy good management by both the developer and the customer
the requirements specification is not substantially
Assumes
Basic
COCOMO is good for quick, early, rough order of magnitude estimates of software costs
does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on software costs, which limits its accuracy
It
E=ab (KLOC or KDSI) bb D=cb (E) db P=E/D where E is the effort applied in personmonths, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.
Software project cb db Organic 2.5 0.38 Semi-detached 2.5 0.35 Embedded 2.5 0.32
ab
bb
2.4
3.0 3.6
1.05
1.12 1.20
Mode Organic
Effort
Schedule
E=2.4*(KDSI)1.05 TDEV=2.5*(E)0.38
Semidetached E=3.0*(KDSI)1.12 TDEV=2.5*(E)0.35 Embedded E=3.6*(KDSI)1.20 TDEV=2.5*(E)0.32
Its
accuracy is necessarily limited because of its lack of factors which have a significant influence on software costs Basic COCOMO estimates are within a factor of 1.3 only 29% of the time, and within a factor of 2 only 60% of the time
The
We
have determined our project fits the characteristics of Semi-Detached mode We estimate our project will have 32,000 Delivered Source Instructions. Using the formulas, we can estimate:
= 3.0*(32) 1.12 months Schedule = 2.5*(146) 0.35 Productivity 146 MM
Effort Average
= 146 man-
= 14 months = 32,000 DSI /

= 219 DSI/MM = 146 MM /14
Staffing
months
Software
engineering tools consisted solely of translators, compilers, assemblers, linkers, loaders, etc. the software NEEDED to build code. werent yet to powerful enough or support higher-level
Computers
advanced functioning
Software
engineering often follows specific standardized methods

are lots of documentation involved diagrams and
There
So
now computers can be used to deal with the higher-level aspects of software engineering
What
is a CASE Environment? CASE is the use of computer-based support in the software development process.
is a CASE Tool? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.
What
Supply basic functionality, do routine tasks automatically Be able to support editing of code in the particular programming language, supply refactoring tools
Enhance productivity Generate code pieces automatically
Increase software quality

Intuitive use
Integration with other tools For example, code editor works with code repository
Project
management software System design tools Code storage Compilers Translation tools Test software
Code
generation tools (Visual Studio .NET) Code analysis (Borland Audits) Development of data models (UML editors) Cleaning up code (refactoring tools) Bug tracker
CASE
tools do more than just output
code Can be used to generate SE documents Database schema Data flow diagrams Entity relationship diagrams Program specifications User documentation
Upper
CASE: Tools for the analysis and design phase of the software development lifecycle (diagramming tools, report and form generators, analysis tools) CASE: Tools to support implementation, testing, configuration management
Lower

Sad Lec22 - Notes - Cocomo, Cmmi and Case Tool

Uploaded by

Copyright:

Available Formats

Sad Lec22 - Notes - Cocomo, Cmmi and Case Tool

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sad Lec22 - Notes - Cocomo, Cmmi and Case Tool

Uploaded by

Copyright:

Available Formats

Capability Maturity Model Integration

developed by the Software Engineering Institute to help

to improve their software processes to assess the quality of their contractors

organizations which acquire software

not have an environment for developing and maintaining software.

processes are put together to make a coherent

goals set for both software products and

Focus Continuous Process Improvement

4 Quantitatively Quantitative Managed Management

Basic Project Management

has three different models that reflect the complexity:

Mode Intermediate (in

Semidetached E=3.0(KDSI)1.12 TDEV=2.5(E)0.35 Embedded E=3.6(KDSI)1.20 TDEV=2.5(E)0.32

= 14 months = 32,000 DSI /

engineering often follows specific standardized methods

Increase software quality

tools do more than just output

You might also like