Metrics implementation and estimation start

Any discussion of metrics has to start with a foundation. Over the years, a consensus has arisen to describe at least a core set of four metrics. These are: size, time, effort, and defects as we have discussed it all in the last discussions. Now let’s have look at the guiding process body like Software Engineering Institute (SEI). The SEI has issued a useful publication that discusses the background to the core measures and offers recommendations for their use. There are several additional SEI documents available that go into further depth on the measures individually. And lastly, prior to the SEI, some of the first writings on the core set can be found in various web sites.

As discussed in last blog, this "minimum data nods / control points" links management's bottom line in a cohesive relationship. As project teams, we spend a certain amount of time (Days, weeks, months), expending a certain amount of work effort (person days, person-months). At the end of our hard work, the system is ready to be deployed. It represents a certain amount of functionality at a certain level of quality / user satisfaction. Anyone embarking on a measurement program should start with at least these four core measures as a foundation.

A good manager should be keeping these types of records. For projects that have been completed, size represents what has been built, as countable entities. Knowing what's been accomplished, at what speed, at what cost, and at what level of quality can tell us how well we did. This is what we call "benchmarking" or "knowing your what we achieved." And an extension to this can guide us for “what we can do” is stretched for our efficiencies.

For new projects the sizing issue becomes one of estimation. The best way of approximating what needs to be built is to have records about units you've built before, in order to help you scope the new job. Size estimation is a critical discipline. It represents a team's commitment as to what it will build. As Studies by the SEI indicate that the most common failing of ad hoc software organizations is an inability to make size estimates accurately. If you underestimate the size of your next project, common sense says that it doesn't matter which methodology you use, what tools you buy, or even what programmers you assign to the job.

Now let’s put some light on "NEW" trends in measurements of size for OO projects

Whenever software developers begin a project that involves a new technology (OO, SOA, etc.), there is great confusion as to how and what they should measure and what the appropriate "size" unit might be. The software development community has pondered questions like these since what seems to be the beginning of time. You name the technology, the language, the era. These questions often come down to size. Time we understand. Effort we understand. Defects we understand (yet very few tracks them or keeps good records!). That last measure of “size” is often where all these questions lead to.

For object-oriented development, useful measures of size have been shown to be units such as number of methods, objects, or classes. Common ranges seem to be about 175 to 250 lines of code (C++, Smalltalk, etc.) per object. Lines of code, function points, classes, objects, methods, processes, programs, Java scripts, and frames all represent various abstractions of system size.

Leveraging these size units means taking an inventory of past projects in order to better understand the building blocks of past systems. This also establishes the vocabulary of the organization in terms of the functionality that has been, and needs to be, built. It is the basis of negotiation when trying to decide what a team agrees to take on, within a given deadline.

New engineering way for estimation Function Points

Of all the followers of different size metrics, OO or otherwise, the "priests" of function points have been the most insistent in promoting that measure as the most important offering for all the benches.

There are still issues in FP thought process. In many organizations, function points seem to have served a useful purpose. Organizations are finally getting people to think about project size. It used to be that you'd ask the question, "How big is this application?" and someone might answer, "150 man-months," answering your question on size with a number for the effort (related to cost) spent building it.

That's like someone asking you, "How big is your house?" and you answer, "$250,000." You should have said something like, "It's a four-bedroom with 2 1/2 baths, for a total size of 2,400 square feet." High abstraction unit: rooms; low abstraction unit: square feet.

Size is a metric describing the bigness or smallness of the system. It can be broken into chunks of various descriptions. Function points can do this in certain applications. As previously mentioned, other units include programs, objects, classes, frames, modules, processes, computer software configuration items, subsystems, and others. All represent the building blocks of the projects / products from different levels of abstraction, or perspectives. They all ultimately translate to the amount of code that becomes compiled and built to run on a computer or embedded processor.

They translate down to a common unit just as the volume of fluid in a vessel might be described in terms of liters, gallons, quarts, pints, and ultimately, down to a common unit of either fluid ounces or milliliters. The key point to understand, though, is that all these units relate to each other in a proportional, scaling relationship.

So when questions like, "What new metrics should we use for . . . ?" arise, Direct it to what would make sense in the organization's vocabulary, if it comes down to project size. Remember that the objective is to communicate information about the system and maximize the flow of information by making sure everyone speaks a well-understood and familiar language. Have language fit the organization, not the other way around.

Challenges in the Function Point World

For many organizations, the underlying concept of function points is a decent fit. That is, the metamodel of a system comprising two parts, a database structure and functions that access those structures, correctly describes what they build.

However, as we rightly observe, "You have a problem if your system does anything other than approved functionality. That's not necessarily saying anything bad about the function point, other than that it simply is not a size metric for all systems Also, organizations have found metrics programs to be very valuable in tracking and controlling projects already under way. Unfortunately, function points can represent difficult entities to track midstream. In ongoing projects, function point users have reported difficulty in counting "what function points have been built so far." (On the other hand, it's relatively easy for a configuration management system to report how much code has been added as new and what code has been changed.) In order to fill that void, many organizations respond by using alternate size measures for tracking, such as modules built, number of objects or programs under configuration management, number of integration builds, and yes, amount of code built and tested to date. The later size can be measured by a system of measuring Line of Code(LOC, KLOC)

So whether function points have met their early promise of consistency in counting is up for debate. They may not have proved immune to counting controversy after all. Nevertheless, function points serve a purpose as one type of size metric. And if your organization builds applications, it might pay to consider function points as a size metric.

Remember that any one measure has its limitations. Therefore, utilize multiple approaches where possible and note the sizing relationships (the proportionality) between them.

Additionally we can try DEFECT METRICS to check how re-building /re-work occurs

No metrics discussion would be complete without addressing the subject of software defects. It is the least-measured entity, yet the one that receives the worst press when software failures occur in the real world. That should tell us something in and of itself. What we are seeing with software defects is the direct correlation of schedule pressure and bad planning. This squarely points to the potential for management to influence software quality, both positively and negatively. Causality between software project deadlines and defect levels thus places the opportunity for good quality software squarely in normal management laps.

We can build two categories for defects (1) defects found during system testing to delivery (including severity), over time, and (2) defects after roll-out / implementation/ user reported defects. The two categories are indistinguishably related. The latter will enable you to determine software reliability. There is much to interpret from this raw data. At the heart of this is causal analysis; that is, finding out the drivers behind defect rates and defect densities and then doing something about them.

simple metrics to start from for typical IT project

Let's begin with the real world, complete with all its incredible deadline pressure. Let's talk about the implementation now, we can start with a dashboard or Charts,.Charts are prepared for the standard metrics. All charts require titles, legends, and labels for all axes. They should clearly and succinctly show the metrics of interest, with no excessive detail to detract the eye. Do not overuse different line types, patterns, or color, or added dimensionality unless used specifically to differentiate items. Overlayed data is preferable to multiple charts when the different data are related to each other and can be meaningfully depicted without obscuring other details.

The most common type of chart is the tracking chart. This chart is used extensively for the Progress indicator, and is used in similar forms for many of the other indicators. For task progress, it depicts the cumulative number of planned and actual task completions (or milestones) against time. For other indicators, it may show actual versus planned staffing profiles, actual versus planned software size, actual versus planned resource utilization or other measures compared over time.

There are many ways to modify the tracking chart. A horizontal planned line representing the cumulative goal can be drawn at the top, multiple types of tasks can be overlaid on a single tracking chart (such as design, code, and integration), or the chart can be overlaid with other types of data.

It is recommended that tracked quantities be shown as a line chart, and that replanned task progress be shown as a separate planning line. The original planned baseline is kept on the chart, as well as all replanning data if there is more than a single replan.

The following sections provide brief descriptions of the different metrics categories with samples of the required charts. Individual projects may enhance the charts for their situations or have additional charts for the categories. The sample charts are designed for overhead presentations and are available as templates from the professor.

Indicator Category	Management Insight	Indicators
Progress	Provides information on how well the project is performing with respect to its schedule.	Actual vs. planned task completions Actual vs. planned durations
Effort	Provides visibility into the contributions of staffing on project costs, schedule adherence, and product quality.	Actual vs. planned staffing profiles
Cost	Provides tracking of actual costs against estimated costs and predicts future costs.	Actual vs. planned costs Cost and schedule variances
Review Results	Provides status of action items from life-cycle review.	Status of action items
Trouble Reports	Provides insight into product and process quality and the effectiveness of the testing.	Status of trouble reports Number of trouble reports opened, closed, etc. during reporting period
Requirements Stability	Provides visibility into the magnitude and impact of requirements changes.	Number of requirements changes/clarifications Distribution of requirements over releases
Size Stability	Provides insight into the completeness and stability of the requirements and into the ability of the staff to complete the project within the current budget and schedule.	Size growth Distribution of size over releases
Computer Resource Utilization	Provides information on how well the project is meeting its computer resource utilization goals/requirements.	Actual vs. planned profiles of computer resource utilization
Training	Provides information on the training program and staff skills.	Actual vs. planned number of personnel attending classes

so these are nine implementations to start with you can use the suitable combination which ever you feel the need for. Feel free to share comments / feedbacks

Simplified Software Metrics - For starters 001

Software metrics are an integral part of the modernization in software engineering. More and more customers are specifying software and/or quality metrics reporting as part of their contractual requirements. Many Industry standards like ISO 9000 and industry models like the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI®) include measurement. So organizations are defining & using these metrics to better track, control and predict software projects, processes and products.

The term software metrics means different things to different people. When we buy a book or pick up an article on software metrics, the topic can vary from project cost and effort prediction and modeling, to defect tracking and root cause analysis, to a specific test coverage metric, to computer performance modeling. As software engineers prefer the activity based view taken by Goodman. He defines software metrics as, "The continuous application of measurement-based techniques to the software development process and its products to supply meaningful and timely management information, together with the use of those techniques to improve that process and its products." an expansion of this definition to include software-related services such as installation and responding to customer issues. Software metrics can provide the information needed by engineers for technical decisions as well as information required by management.

If a metric is to provide useful information, everyone involved in selecting, designing, implementing, collecting, and utilizing it must understand its definition and purpose. Let's ponder on steps to selecting, designing, and implementing software metrics in order to insure this understanding.

Some Basic Measurement Theory The use of measurement is common. We use measurements in everyday life to do such things as weigh ourselves in the morning or when we check the time of day or the distance we have traveled in our car. These repetitive measurements are used extensively in most areas of production and manufacturing to estimate costs, calibrate equipment, assess quality, and monitor inventories. Science and engineering disciplines depend on the rigor that measurements provide.

According to Fenton, "measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world

in such a way as to describe them according to clearly defined rules". In this statement an entity is a person, place, thing, event or time period. An attribute is a feature or property of the entity. To measure, we must first determine the entity. For example, we could select a car as our entity. Once we select an entity, we must select the attribute of that entity that we want to describe. For example, the car’s speed or the pressure in its tires would be two attributes of a car. Finally, we must have a defined and accepted mapping system. It is meaningless to say that the car’s speed is 65 or its tire pressure is 75 unless we know that we are talking about miles per hour and pounds per square inch, respectively.

We will use the basic process model of input - process - output to discuss software entities. Software entities of the input type include all of the resources used for software research, development, and production. Examples of input entities include resources (people), materials, tools, and methods. Software entities of the process type include software-related activities and events and are usually associated with a time factor. Examples of process entities include defined activities such as developing a software system from requirements through delivery to the customer, the inspection of a piece of code, or the first 6 months of operations after delivery. Process entities also include time periods, which do not necessarily correspond to specific activities. An example would be the period between 1/1/10 and 2/1/11. Software entities of the output type are the products of the software process. These include all the artifacts, deliverable, and documents that are produced. Examples of software output entities include requirements documentation, design specifications, code (source, object & executable), test documentation (plans, scripts, specifications, cases, reports), project plans, status reports, budgets, problem reports, and software metrics.

Each of these software entities has many properties or features that we might want to measure. We might want to examine a computer's price, performance, or usability. We could look at the time or effort that it took to execute a process, the number of incidents that occurred during the process, its cost, controllability, stability, or effectiveness. We might want to measure the complexity, size, modularity, testability, usability, reliability, or maintainability of a piece of source code.

One of the challenges of software metrics is that few standardized mapping systems exist. Even for seemingly simple metrics like the number of lines of code / Kilo line of code (KLOC) no standard counting method followed across the organizations.

Do we count physical or logical lines of code?

Do we count comments or data definition statements?

Do we expand macros before counting and do we count the lines in those macros more than once?

Another example is engineering hours for a project – besides the effort of software engineers, do we include the effort of testers, managers, secretaries, and other support personnel?

This are improving like a few metrics, which do have standardized counting criteria include McCabe’s Cyclomatic Complexity and the Function Point Counting Standard from the International Function Point User Group (IFPUG).

However, the selection, definition, and consistent use of a mapping system within the organization for each selected metric are critical to a successful metrics program.

For a thumb rule all IT companies follow three types basic matrices line cost matrix, Schedule matrix & quality matrices. We will ponder on these & types of matrices in next discussions. Share your thoughts at ravindrapande@gmail.com.

public, private and hybrid clouds

As we know keeping up with data growth is the top challenge of IT managers. In today's Internet Era, the emphasis is on cost-effectively managing multiple peta bytes of storage and a more stringent compliance landscape. Traditional networked storage technologies alone are no longer able to scale and perform at the demanding levels needed to keep pace with punishing data growth rates and requirements using existing budgets and resources. More data storage usually means additional CAPEX for infrastructure and floor space. In turn, operating OPEX climb between four and eight dollars for every dollar spent on capital equipment for: power and cooling, the administrative cycles to manage aging systems and manual processes; and time-consuming backup, recovery, migration and upgrades. So in a nut shell keeping up with data growth will be the top challenge of both mid-market and enterprise IT managers in the next two years.1 Data held in content depots, large repositories of digital content amassed and organized for information sharing or distribution, are consuming disk storage space in rapid volume.

three main cloud models: private, hybrid and public. Each model may offer varying levels of security, services, access, SLAs and value to end users.

In a private cloud, all components reside within the firewall of an organization. The infrastructure is either managed internally by the IT department and is deployed to create an agile data center or may be managed and delivered as a service by a cloud provider. Behind the security of the firewall, private cloud embraces high levels of automation to virtualize the infrastructure, including servers, networks and storage, and to deliver services to business units or other branches. With private cloud, security of the data and physical premises are determined and monitored by the IT team, and its high quality service level agreements remain intact. The organization maintains its own strong security practices of both the data and the physical location, such as key codes, passwords etc. Access to data is determined internally and may resemble existing role-based access controls or grant separate administration and data permissions based on data types and security practices. The values of private cloud to the end user are quick and easy resource sharing, rapid deployment, self service and the ability to perform ROI. The value to the service provider, or in this case,
the organization, is an ability to initiate for usage while maintaining control over data access and security.

The hybrid cloud model consists of a combination of internal and external cloud infrastructures whereby selected data, infrastructure or applications are allowed to "punch through" the corporate firewall and be provided by a trusted cloud provider. Here, the multitenant infrastructure outside the firewall delivered by a trusted cloud provider is leveraged for further cost reduction. The subscriber and the hybrid cloud provider are bound together by standardized or proprietary technologies that enable data and application portability. The IT organization makes decisions regarding what types of services and data can live outside the firewall to be managed by a trusted third-party partner
With Hybrid cloud usually provides an attractive alternative to the enterprise when internal processes can no longer be optimized: for example, when the organization's cost infrastructure can only be amortized across business units or a small customer base. By moving certain data and applications to a hybrid cloud, the enterprise is able to significantly reduce the costs of providing services by taking advantage of the multitenant capabilities and economies of scale.

In a public cloud model, all major components are outside the enterprise firewall, located in a multitenant infrastructure. Applications and storage are made available over the Internet via secured IP, and can be free or offered at a pay-per-usage fee paid with credit cards. This type of cloud supplies easy-to-use consumer-type services, such as: Amazon and Google on-demand web applications or capacity; Yahoo mail; and Facebook or LinkedIn social media providing free storage for photographs. The elasticity, low entry costs and ease of use of public cloud seem well suited to supporting applications that follow web design, service oriented architecture or virtual server environments. While public clouds are inexpensive and scale to meet needs, they typically provide "consumer level" or lower SLAs and may not offer the guarantees against data loss or corruption found with private or hybrid cloud offerings. Public cloud is appropriate for consumers and entities not requiring the same levels of service that are expected within the firewall.Also, the public clouds do not provide for restrictions and compliance with privacy laws, which remain the responsibility of end user.

Now priority wise for private clouds, the service delivery layer sits on top of enterprise IT infrastructure. In hybrid or public clouds, the enterprise's existing infrastructure can be used efficiently for core data, freed up or retired as needed. As a result, less infrastructure equates to lower data center power, cooling, facility and maintenance costs.