Index

Sr. No. Contents Page No.

Annexure I– Micro Project Proposal 1-2

1.Aims/Benefits of the Micro-Project 1

2. Course Outcome Addressed 1

1 3.Proposed Methodology 1

4. Action Plan 1-2

5. Resources Required 2

6. Name of Team Members with Roll No.’s 2

Annexure II – Micro Project Report 3-20

1.Rationale 3

2.Aims/Benefits of the Micro-Project 3

3.Course Outcome Achieved 3

4. Literature Review 4-19

2

5.Actual Methodology Followed 19

6.Actual Resources Used 19

7.Outputs of Micro-Projects 20

8. Skill developed / Learning out of this Micro-Project 20

9. Applications of this Micro-Project 20

i
 Annexure I

Micro Project Proposal

Bouncing Ball Using Computer Graphics

1. Aims/Benefits of the Micro-Project:

1. Understand the implementation of graphics program.

2. To learned that how to bounce the ball using graphics function.

3. To understand the various functions and their uses.

2. Course Outcome Addressed:

1) CO1- Select suitable Software Process model for software development.

2) CO2- Prepare software requirement specifications.

3) CO3-Use Software modeling to create data designs.

4) CO4- Estimate size and cost of software product.

5) CO5-Apply project management and quality assurance principles in software development.

3. Proposed Methodology:

4.Action Plan:

Sr. Planned Planned Name of Responsible

Details of Activity
No. Start date Finish date Team Members
1 Search the topic 29/08/2022 5/09/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
2 Search the information 12/09/2022 19/09/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
3 Algorithm developing 26/09/2022 03/10/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
4 Flowchart developing 10/10/2022 15/10/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit

1
 5 Function making 31/10/2022 07/11/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
6 Coding developing 14/11/2022 21/11/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
7 Debugging 28/11/2022 05/12/2022 Bavge Prathmesh &
4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit
8 Finalizing Project with its 12/12/2022 19/12/2022 Bavge Prathmesh &
report 4:00pm-5:00pm 4:00pm-5:00pm Thakur Aditya &
Dhange Rohit

5. Resources Required:
Sr.
Name of resource / material Specification Quantity Remarks
No.
1 Computer WINDOWS 11,4 GB 1
RAM, 1 TB HDD
2 Operating System WINDOWS 11 1

3 Compiler Turbo C 1

4 Browser Chrome 1

6.Names of Team Members with Roll No.’s:

Sr.
Enrollment No. Name of Team Member Roll No.
No.
1 2110950062 Mr. Bavge Prathmesh Santosh 14
2 2110950065 Mr. Thakur Aditya Vithalrao 17
3 2110950068 Mr. Dhange Rohit Shivasharan 20

Ms.Kachare S.M.

Name and Signature of the Teacher

2
 Annexure – II

Micro-Project Report

Bouncing Ball Using Computer Graphics

1. Rationale:
Estimating the cost of the project using COCOMO and COCOMO-II.

2.Aims/Benefits of the Micro-Project:

1. Use relevant software process model for developing software products.

2. Helps in making decisions based on business and financial calculations of the project.

3. To understand the estimate size and cost of software product.

3. Course Outcomes Achieved:

1) CO1- Select suitable Software Process model for software development.

2) CO2- Prepare software requirement specifications.

3) CO3-Use Software modeling to create data designs.

4) CO4- Estimate size and cost of software product.

5) CO5-Apply project management and quality assurance principles in software development.

3
4. Literature Review:

COCOMO Model I

Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of

the most generally used software estimation models in the world. COCOMO predicts the efforts and
schedule of a software product based on the size of the software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of

delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying
factors i.e., multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used
in the static single variable models, using KDLOC as the measure of the size. To determine the
initial effort Ei in person-months the equation used is of the type is shown below

Ei=a*(KDLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1.Organic: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is reasonably
small, and the team members are experienced in developing similar methods of projects. Examples
of this type of projects are simple business systems, simple inventory management systems, and data
processing systems.

2. Semidetached: A development project can be treated with semidetached type if the

development consists of a mixture of experienced and inexperienced staff. Team members may have
finite experience in related systems but may be unfamiliar with some aspects of the order being
developed. Example of Semidetached system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory management system.

4
 3. Embedded: A development project is treated to be of an embedded type, if the software being
developed is strongly coupled to complex hardware, or if the stringent regulations on the operational
method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a
unit of person month)and development time from the size of estimation in KLOC(Kilo Line of code)
efforts estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks,
etc.

According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project
parameters. The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person months
(PMs).

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the
code size are shown below:

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

5
 Estimation of development time

For the three classes of software products, the formulas for estimating the development time
based on the effort are given below:

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

Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes. Fig shows a plot of estimated effort versus product size.
From fig, we can observe that the effort is somewhat superliner in the size of the software product.
Thus, the effort required to develop a product increases very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be
observed that the development time is a sub linear function of the size of the product, i.e. when the
size of the product increases by two times, the time to develop the product does not double but rises
6
moderately. This can be explained by the fact that for larger products, a larger number of activities
which can be carried out concurrently can be identified. The parallel activities can be carried out
simultaneously by the engineers. This reduces the time to complete the project. Further, from fig, it
can be observed that the development time is roughly the same for all 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.

From the effort estimation, the project cost can be obtained by multiplying the required effort by
the manpower cost per month. But, implicit in this project cost computation is the assumption that
the entire project cost is incurred on account of the manpower cost alone. In addition to manpower
cost, a project would incur costs due to hardware and software required for the project and the
company overheads for administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the COCOMO
model are called a nominal effort estimate and nominal duration estimate. The term nominal implies
that if anyone tries to complete the project in a time shorter than the estimated duration, then the cost
will increase drastically. But, if anyone completes the project over a longer period of time than the
estimated, then there is almost no decrease in the estimated cost value.

7
 Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has
average experience on similar type of projects. The project schedule is not very tight. Calculate the
Effort, development time, average staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the size,
schedule and experience of development time.

Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

P = 176 LOC/PM
8
 2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of
the number of lines of code and some constants calculated according to the various software systems.
The intermediate COCOMO model recognizes these facts and refines the initial estimates obtained
through the basic COCOMO model by using a set of 15 cost drivers based on various attributes of
software engineering.

Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -

o Run-time performance constraints

o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

9
The cost drivers are divided into four categories:

10
 Intermediate COCOMO equation:

E=ai (KLOC) bi*EAF

D=ci (E)di

Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard

version with an assessment of the cost driver?s effect on each method of the software engineering
process. The detailed model uses various effort multipliers for each cost driver property. In detailed
cocomo, the whole software is differentiated into multiple modules, and then we apply COCOMO in
various modules to estimate effort and then sum the effort.

1. The Six phases of detailed COCOMO are:

2. Planning and requirements
3. System structure
4. Complete structure
5. Module code and test
6. Integration and test
7. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given
according to every phase of the software lifecycle.

11
 COCOMO Model II

1. Introduction

COCOMO 2 is tuned to modern software life cycles. The original COCOMO model has been
very successful, but it doesn't apply to newer software development practices as well as it does to
traditional practices. COCOMO II targets the software projects of the 1990s and 2000s, and will
continue to evolve over the next few years.

The primary objectives of the COCOMO 2 effort are:

• To develop a software cost and schedule estimation model tuned to the life cycle
practices of the 1990's and 2000's.
• To develop software cost database and tool support capabilities for continuous model
improvement.
• To provide a quantitative analytic framework, and set of tools and techniques for
evaluating the effects of software technology improvements on software life cycle costs
and schedules.

COCOMO 2 is really three different models:

• The Application Composition Model

Suitable for projects built with modern GUI-builder tools. Based on new Object Points.

• The Early Design Model

You can use this model to get rough estimates of a project's cost and duration before you've
determined it's entire architecture. It uses a small set of new Cost Drivers, and new
estimating equations. Based on Unadjusted Function Points or KSLOC.

• The Post-Architecture Model

This is the most detailed COCOMO 2 model. You'll use it after you've developed your
project's overall architecture. It has new cost drivers, new line counting rules, and new
equations.

12
2. Application Composition : Object points

Object Point estimation is a relatively new software sizing approach, but it is wellmatched
to the practices in the Applications Composition sector. It is also a good match to associated
prototyping efforts, based on the use of a rapid-composition Integrated Computer Aided
Software Environment (ICASE) providing graphic user interface builders, software development
tools, and large, composable infrastructure and applications components. In these areas, it has
compared well to Function Point estimation on a nontrivial (but still limited) set of applications.

Baseline Object Point Estimation Procedure

13
Definitions of terms in Figure are as follows:

• NOP: New Object Points (Object Point count adjusted for reuse)
• srvr: number of server (mainframe or equivalent) data tables used in conjunction with the
SCREEN or REPORT.
• clnt: number of client (personal workstation) data tables used in conjunction with the
SCREEN or REPORT.
• %reuse: the percentage of screens, reports, and 3GL modules reused from previous
applications, pro-rated by degree of reuse.

3. Function Count Procedure

14
4. Converting Function Points to Lines of Code

To determine the nominal person months for the Early Design model, the unadjusted
function points have to be converted to source lines of code in the implementation language
(assembly, higher order language, fourth-generation language, etc.) in order to assess the relative
conciseness of implementation per function point.

15
 5. Development Effort Estimates

In COCOMO II effort is expressed as Person Months (PM). person month is the amount of
time one person spends working on the software development project for one month.

The inputs are the Size of software development, a constant, A, and a scale factor, B. The size is
in units of thousands of source lines of code (KSLOC).

The constant, A, is used to capture the multiplicative effects on effort with projects of increasing
size.

The scale (or exponential) factor, B, accounts for the relative economies or diseconomies of
scale encountered for software projects of different sizes.

If B < 1.0, the project exhibits economies of scale. If the product's size is doubled, the project
effort is less than doubled. The project's productivity increases as the product size is increased. Some
project economies of scale can be achieved via projectspecific tools (e.g., simulations, testbeds) but
in general these are difficult to achieve. For small projects, fixed start-up costs such as tool tailoring
and setup of standards and administrative reports are often a source of economies of scale.

If B = 1.0, the economies and diseconomies of scale are in balance. This linear model is often
used for cost estimation of small projects. It is used for the COCOMO 2 Applications Composition
model.

If B > 1.0, the project exhibits diseconomies of scale. This is generally due to two main factors:
growth of interpersonal communications overhead and growth of largesystem integration overhead.
Larger projects will have more personnel, and thus more interpersonal communications paths
consuming overhead. Integrating a small product as part of a larger product requires not only the
effort to develop the small product, but also the additional overhead effort to design, maintain,
integrate, and test its interfaces with the remainder of the product.

A project's numerical ratings W are summed across all of the factors, and used to determine a
scale exponent B via the following formula:

16
 Rating Scheme for the COCOMO 2.0 Scale Factors

The form of the Process Maturity scale is being resolved in coordination with the SEI. The intent
is to produce a process maturity rating as a weighted average of the project's percentage compliance
levels to the 18 Key Process Areas in Version 1.1 of the Capability Maturity Model-based [Paulk et
al. 1993] rather than to use the previous 1-to-5 maturity levels. The weights to be applied to the Key
Process Areas are still being determined.

6. Cost Factors: Effort-Multiplier Cost Drivers

COCOMO 2.0 uses a set of effort multipliers to adjust the nominal person-month estimate
obtained from the project’s size and exponent drivers:

Early Design and Post-Architecture Cost Drivers

17
ACAP Analyst Capability

AEXP Applications Experience

CPLX Product Complexity

DATA Database Size

DOCU Documentation to match lifecycle needs

FCIL Facilities

LTEX Language and Tool Experience

PCAP Programmer Capability

PCON Personnel Continuity

PDIF Platform Difficulty

PERS Personnel Capability

PEXP Platform Experience

PREX Personnel Experience

PVOL Platform Volatility

RCPX Product Reliability and Complexity

RELY Required Software Reliability

RUSE Required Reusability

SCED Required Development Schedule

STOR Main Storage Constraint

TIME Execution Time Constraint

TOOL Use of Software Tools

18
 7. Development Schedule Estimates

The initial baseline schedule equation for all three COCOMO 2.0 models is:

where TDEV is the calendar time in months from the determination of its requirements
baseline to the completion of an acceptance activity certifying that the product satisfies its
requirements. PM is the estimated person-months excluding the SCED effort multiplier, and
SCEDPercentage is the schedule compression / expansion percentage in the SCED cost driver
rating. Future versions of COCOMO 2.0 will have a more extensive schedule estimation model,
reflecting the different classes of process model a project can use; the effects of reusable and
COTS software; and the effects of applications composition capabilities.

5 Actual MethodologyFollowed:

6. Actual Resources Used:

Sr. Name of resource /

Specification Quantity Remarks
No. material

1 Computer WINDOWS 11,4GB 1

RAM, 1TB HDD
2 Operating System WINDOWS 11 1

3 Compiler Turbo C 1

4 Browser Chrome 1

7.Outputs of Micro-Projects:

19
8.Skill developed / Learning out of this Micro-Project:
There are so many thing that we learn from this project of

1. We learn that how to make the project in computer graphics program.

2. How to do the testing of program in turbo c.
3. How to collect the information and how to make the presentation that we learn from this
project.
4. We develop our logic implementation for programing and coding.
5. We learn to use functions in computer graphics.
7. We learn some keywords from ‘graphics.h’ header file.
8. This all thing we learn from this project.

9. Applications of this Micro-Project:

1. It can be used to learn code of Bouncing Ball.

2. It can also be used to learn some computer graphics terms like circle(),flood-fill() and other
functions.
3. For Fun.

*********

20