Number of Lines of Code: Problem Testing ??????

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

COCOMO ??????????

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of
Lines of Code. It is a procedural cost estimate model for software projects and often
used as a process of reliably predicting the various parameters associated with making
a project such as size, effort, cost, time and quality. It was proposed by Barry Boehm in
1970 and is based on the study of 63 projects, which make it one of the best-
documented models.
The key parameters which define the quality of any software products, which are also
an outcome of the Cocomo are primarily Effort & Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in person-months
units.
 Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put. It is measured in the units of time such as weeks, months.
Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required. All of these
models can be applied to a variety of projects, whose characteristics determine the
value of constant to be used in subsequent calculations. These characteristics
pertaining to different system types are mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is adequately
small, the problem is well understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming environment
lie in between that of organic and Embedded. The projects classified as Semi-Detached are
comparatively less familiar and difficult to develop compared to the organic ones and require more
experience and better guidance and creativity. Eg: Compilers or different Embedded Systems can
be considered of Semi-Detached type.
3. Embedded – A software project with requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than the
other two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.

Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and accurate forms.
Any of the three forms can be adopted according to our requirements. These are types of COCOMO
model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model

Problem testing ??????


 Poor Requirements – if requirements are unclear, incomplete, too general, and not
testable, there may be problems.

 Unrealistic Schedule – if too much work is crammed in too little time, problems are
inevitable.

 Inadequate Testing – no one will know whether or not the software is any good until
customers complain or systems crash.

 Featuritis – requests to add on new features after development goals are agreed on.

 Miscommunication – if developers don’t know what’s needed or customer’s have


erroneous expectations, problems can be expected.

What is Functional Testing?


Functional Testing is the type of testing done against the business
requirements of application. It is a black box type of testing.

It involves the complete integration system to evaluate the system’s


compliance with its specified requirements. Based on the functional
specification document this type of testing is to be carried out. In actual
testing, testers need to verify a specific action or function of the code. For
functional testing either manual testing or automation tools can be used but
functionality testing would be easier using manual testing only. Prior to non
Functional testing the Functional testing would be executed first.

Five steps need to be keeping in mind in the Functional testing:

1. Preparation of test data based on the specifications of functions


2. Business requirements are the inputs to functional testing
3. Based on functional specifications find out of output of the functions
4. The execution of test cases
5. Observe the actual and expected outputs

To carry out functional testing we have numerous tools available, here is the
list of Functional testing tools.

In the types of functional testing following testing types should be cover:

 Unit Testing
 Smoke testing
 Sanity testing
 Integration Testing
 Interface Testing
 System Testing
 Regression Testing
 UAT

What is non Functional Testing?


The non Functional Testing is the type of testing done against the non
functional requirements. Most of the criteria are not consider in functional
testing so it is used to check the readiness of a system. Non-functional
requirements tend to be those that reflect the quality of the product,
particularly in the context of the suitability perspective of its users. It can be
started after the completion of Functional Testing. The non functional
tests can be effective by using testing tools.

The testing of software attributes which are not related to any specific
function or user action like performance, scalability, security or behavior of
application under certain constraints.

Non functional testing has a great influence on customer and user


satisfaction with the product. Non functional testing should be expressed in a
testable way, not like “the system should be fast” or “the system should be
easy to operate” which is not testable.

Basically in the non functional test is used to major non-functional


attributes of software systems. Let’s take non functional
requirements examples; in how much time does the software will take to
complete a task? or how fast the response is.

Following testing should consider in non functional testing types:

 Availability Testing
 Baseline testing
 Compatibility testing
 Compliance testing
 Configuration Testing
 Documentation testing
 Endurance testing
 Ergonomics Testing
 Interoperability Testing
 Installation Testing
 Load testing
 Localization testing and Internationalization testing
 Maintainability Testing
 Operational Readiness Testing
 Performance testing
 Recovery testing
 Reliability Testing
 Resilience testing
 Security testing
 Scalability testing
 Stress testing
 Usability testing
 Volume testing

Types of Project Resources


OCTOBER 26, 2017 BY JON HARTNEY LEAVE A COMMENT

A project manager that fails to allocate project resources is like a carpenter without a hammer.

That’s why estimating task resources is an integral step in project planning. It also happens to be
one of the most fundamental aspects of project management, one of the steps that the project
manager utilizes on a day to day basis.

Types of Resources

Each task on the task list must be assigned the resources necessary to perform the task.

For small projects there are three major types of resources:


1. Labor
2. Tools & equipment
3. Material & supplies
Labor

Labor is not all created equal. If you try to assign an electrician to install a toilet, you might get some
flooding as well as an unhappy employee.

Likewise, if you assign an electrician to design the power plant, you might find your project costs
escalating out of control as you try to find more qualified labor during the project.

Thus, in order to correctly define labor you must identify two things:

1. Type
2. Class
Labor is usually estimated in hours, but can range all the way up to years for megaprojects. In fact,
when I was a junior engineer I was involved in a large oil sands project where budgeting and
scheduling happened in man-years.

Tools & Equipment

This category generally includes all of the items that do not go into the finished product. Things like
drill bits that are used up during a project, or the addition of new tools that the company doesn’t
already own. It also includes equipment such as forklifts, vehicles and software.

Often the tools and equipment will be used over multiple projects. In this case it is important to
divide the cost over a conservative amount of projects to get a realistic idea of how much the project
is “paying” for it.

Most tools and equipment have an ongoing maintenance cost which must be factored into its project
cost.

Materials & Supplies

This includes the items that become part of the finished product, like timber for a log home or gravel
for the driveway. Often these items are quoted by the unit, such as per foot of timber. Normally you
have to order more quantity than will be used in the finished product, because:

 The material is not produced in the exact lengths required.


 The project will generate some waste.
A contingency factor can also be used on the overall quantity to account for unexpected issues
during the course of the project.

When there are many small supplies that are too small to track individually it is generally
recommended to include a catch-all item, for example “Landscaping Supplies.”

Other Resources

For larger projects, or where greater project management effort is justified, the following resources
can also be used.

1. Organizational/Administration. The portion of the organization’s administration cost that the


project must pay for.
2. Subcontractors. These can be tracked as a fixed cost item within a task.
3. Facilities. The purchase or rental of buildings to perform the work.
4. Financing costs. The interest cost for loans required to carry out the project.
5. Contingencies. Where the complexity of the project justifies contingencies as separate
resource items, they can be tracked separately.
6. Overtime pay. This applies to people as well as to equipment where the rate increase after a
certain point in time.

You might also like