Product Metrics | Software Engineering Product Metrics

Product Metrics

It describes the characteristics of the product such as size, complexity, design features, performance, efficiency, reliability, portability, etc.

Product metrics are concerned with characteristics of the software itself.

Classes of Product Metrics

Product metrics fall into two classes:

• Dynamic Metrics: These are collected by dimensions made of a program in execution. Dynamic metrics are usually rather directly related to software quality attributes. I t is fairly easy to measure the execution time required for particular functions and to evaluate the time required to start-up a system. These relate directly to the system’s efficiency. Similarly, the number of system failures and the type of failure can be logged and related directly to the consistency of the software.
• Static Metrics: These are collected by dimensions made of representations of the system such as the design, program or documentation. Static metrics, on the other hand, have an indirect relationship with quality attributes. A large number of these metrics have been proposed, and many experiments have tried to obtain and validate the relationship between these metrics and system complexity, understandability and maintainability.

Areas of Product Metrics

• Metrics for Analysis Model: These metrics address various aspects of the analysis model and include:

1. Functionality Delivered: Provides an roundabout measure of the functionality that is packaged within the software.
2. System Size: measure of the overall size of the system defined in terms of information available as part of the analysis model.

• Specification Quality: provides an indication of the specificity and completeness of a requirements specification.
• Metrics for Design Model: These metrics quantity design attributes in a manner that allows a software engineer to contact design quality. Metrics include:

1. Architectural Metrics: provide an indication of the quality of the architectural design.
2. Component-level Metrics: measure the complexity of software components and other characteristics that have a attitude on quality.

• Interface Design Metrics: focus primarily on usability.

1. Specialized OO Design Metrics: measure characteristics of classes and their communication and collaboration characteristics.

• Metrics for Source Code: These metrics measure the source code and can be used to access its complexity, maintainability, and testability, among other characteristics:

1. Halstead Metrics: Controversial but nonetheless attractive, these metrics provide unique measurements of a computer program.
2. Complexity Metrics: calculate the logical complexity of source code.

• Length Metrics: Provide an suggestion of the size of the software.
• Metrics for Testing: These metrics assist in the design of effective test cases and evaluate the efficacy of testing:

1. Statement and Branch Coverage Metrics: Lead to the design of test cases that provide program coverage.
2. Defect-Related Metrics: focus on bugs found, rather than on the tests themselves.

• Testing Effectiveness: present a real-time indication of the effectiveness of tests that have been performed.

1. In-Process Metrics: process related metrics that can be determined as a testing conducted.

 website designing company in Delhi

Software Engineering Measurements

Software measurement

Software measurement is concerned with deriving a numeric value for some attribute of a product or software processes.

Following are two ways in which software product measurements may be used:

• Make General Predictions about a System: By measuring the characteristics of system components and then aggregating these measurements, you can constrain a general estimate of some system attribute such as the number of faults in the system.
• Identify Anomalous Components: Measurements can identify individual components whose characteristics deviate from some norm. For example, you can compute components to notice those with the highest complexity and, assuming these are possibly to have errors, concentrate on these components during the review process.

The basic purpose of measurements in a project is to effectively monitor and control the project. Measurement is the act of determining a measure.

According to IEEE Standard Glossary, “A quantitative measure of the degree to which a system, component, or processes a given attribute”.

A software engineer collects measure and develops metrics so that indicators will be acquired. An indicator is a metric or combination of metrics that provides insight into the software processes, a software project, or the product itself. An indicator supply insight that enables the project manager or software engineers to adjust the process, the project to make things better.

Measurement Principles:

• Formulation: The derivation of software measures and metrics suitable for the illustration of the software that is being considered.
• Collection: The mechanism used to accrue data required to obtain the formulated metrics.
• Analysis: The computation of metrics and the application of mathematical tools.
• Interpretation: The appraisal of metrics in an effort to gain insight into the quality of the representation.
• Feedback: Recommendations derived from the interpretation of product metrics transmitted to the software team.

Measurement Process

Main stages in this process are:

• Choose Measurements to be made: The questions that the dimension is projected to answer should be formulated and the measurements required answering these questions distinct. Measurements that are not directly applicable to these questions need not be collected.
• Select Components to be assessed: It may not be required or enviable to assess metric values for all of the components in a software system. In some cases, you can choose a delegate selection of components that are particularly serious, such as core components that are in almost constant use, should be assessed.
• Measure Component Characteristics: The selected components are measured and the connected metric values calculated. This in general absorbs processing the component description using an automated data collection tool. This tool may be specially written or may already be incorporated in CASE tools that are used in an organization.
• Identify Anomalous Measurements: Once the component capacity have been made, you should compare them to each other and to previous measurements that have been recorded in a measurement database. You should look for unusually high or low values for every one metric, as these suggest that there could be problems with the component revealing these values.
• Analyze Anomalous Components: Once components that have anomalous values for particular metrics have been acknowledged, you should examine these components to choose whether the abnormal metric values mean that the quality of the component is compromised. An abnormal metric value for complexity does not necessarily mean a poor quality component. There may be some other reason for the high value and it may not mean that there are component quality problems.

Requirement Validation

Requirements Validation examines the requirement to ensure that all system requirements have been stated decidedly; that inconsistencies, oversight, and errors have been detected and corrected; and that the work products be conventional to the standards reputable for the process, the project, and the product.

Checks in Requirements Validation Process

During the requirements validation process, checks should be carried out on the requirements in the requirements document. These checks include following:

• Validity Checks: A user may think that a system is desirable to perform certain functions. However, further deliberation and analysis may classify additional or different functions that are required.
• Consistency Checks: Requirements in the document should not variance. That is, there should be no opposing constraints or descriptions of the same system function.
• Completeness Checks: The requirements document should include requirements, which define all functions, and constraints intended by the system user.
• Realism Checks: With the knowledge of available technology, the requirements should be checked to ensure that they could actually be implemented.
• Verifiability: To reduce the potential for argument between customer and contractor, system requirements should always be written so that they are verifiable.

A number of requirements validation techniques can be used in conjunction or individually:

• Requirements Reviews: The requirements are analyzed methodically by a team of reviewers.
• Prototyping: In this approach to validation, an executable model of the system is confirmed to end-users and customers. They can research with this model to see if it meets their real needs.
• Test-case Generation: Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems.

Tools for Requirements Validation

It is tremendously enviable to detect errors in the requirements before the design and development of the software begins. Various tools for requirements validations are as under:

1. Reading: Reading implies that someone other than the author of the requirements read the requirements specification document to identify potential problems. When requirements are read by another person who has a different interpretation of requirements, those requirements that cause misinterpretations or ambiguities can be identified.
2. Constructing Scenarios: Scenarios describe different situations of how the system will work once it is operational. Constructing scenarios is good for clarifying misunderstandings in the human-computer interaction area.

• Requirements Review: Requirements review is a review by a group of people to discover errors and point out other matters of apprehension in the requirements specifications of a system.

1. Automated Cross-referencing: Automated cross-referencing makes use of processors to verify some properties of requirements.
2. Prototyping: Prototypes are quite useful in verifying the possibility of some requirements and checking the user interface. It proves to be very useful for a clear understanding of requirements, removing misconceptions and helps in requirements analysis.

Project Planning

Software project planning involves identification of those activities that need to be done to complete the project successfully and plan the scheduling and resource allocation of these activities.
The input to software planning is the Software Requirements Specification (SRS) Document and the output is the software project management plan (SPMP) document.

The major issues involved in project plan are:

1) Project proposal writing.
2) Project cost estimation.
3) Scheduling
4) Project staffing
5) Project monitoring and control
6) Software configuration management
7) Sisk management
8) Managerial report writing and presentations, etc.

SPMP Document

1) Introduction ( Objectives, Major Functions, Performance Issues, Management and Technical Constraints).

2) Project Estimates ( Historical Data, Estimation Techniques, Effort, Cost, and Project Duration Estimates)

3) Project Resources Plan ( People, Hardware and Software, Special Resources)

4) Schedules ( Work Breakdown Structure, Task Network, Gantt Chart Representation, PERT Chart Representation)

5) Project Tracking and Control Plan

6) Risk Management Plan ( Risk Analysis, Risk Identification, Risk Estimation, Abatement Procedures)

7) Miscellaneous Plans ( Process Tailoring, Quality Assurance)

Project Management in Software Engineering

Project Management

Project management involves the planning, monitoring and control of the people, process, and events that occur as software evolves from a prelude concept to an operational implementation.

There are 4 P’s of project management – people, product, process, and project. People must be organized to perform software work effectively. Communication with the customer must occur so that product scope and requirements are understood.

The goal of Project Management is to ensure that a software product that meets the quality specification of the requirements definition is produced on schedule and at on reasonably acceptable cost within planned resources.

Objectives of Project Management

A software development manager must keep in mind quality, productivity, and risk reduction throughout the planning and execution of product development:

• Quality: Quality is best achieved by careful observance to standards, effective development techniques and periodic technical review throughout the process.
• Productivity: Increased productivity lowers costs. In the current state of development technology, the most important productivity factors are the ability of the individual software engineers, the tools they work with, and the work environment.
• Risk Reduction: Managers should identify the most difficult parts of a particular development and methodically come to grips with sufficient solutions.

 

Management Activities

Activities in a software project encompass a combination of “engineering” and “management” activities.

Engineering activities are covered as part of the selected lifecycle model. Management activities on the other hand hold and manage the execution of the engineering activities.

Key elements of the management activities:

• Project Start-Up: At this stage the wide scope of the project is decided. A contract may be signed for the whole duration or an agreement may cover all activities till the end of requirements phase, with an understanding that another contract will cover the rest of the phases after requirements are completed.
• Estimation: Size, effort, schedule and cost of the project is typically estimated in parallel with the requirements definition phase. Size estimation involves predicting ‘how big’ the software will be.

Based on the size of the software, productivity related data and experience from past projects; the size is converted into Effort. Effort is estimated in terms of person-hours, person-days or person-months that need to be consumed to create the software.

Schedule is consequent of the effort estimate, the number of team members and the extent to which project lifecycle activities are independent of each other.

• Requirements Management: The end of the requirements phase is noticeable by a set of documented requirements being reviewed and decided to between the development team and the customer/end-user.

The requirements management activity is conscientious for ensuring that changes to the agreed requirements are handled in a controlled manner and that all agree requirements are implemented in the software as it is built through the various phases of the lifecycle.

• Project Planning, Execution and Control: These activities include engineering activities as well as management activities. Project planning and control persist all through the lifecycle of a project.

Planning typically involves:

1. Breaking-up of the engineering and management activities into smaller tasks.
2. Identifying the team to execute these activities.

• Defining the roles, responsibilities and reporting relationship between the team members.

1. Planning for the training required by the team to execute the activities.
2. Specifying the mechanism for tracking and controlling the project.

Project execution and control typically involves:

1. Allocating tasks to team members.
2. Collecting data on actual completion status, dates, and effort spent, size of items created and costs.

• Re-estimating and re-planning as required.

1. Managing and monitoring the risks.
2. Reporting the status of the project through meetings and documents.

• Configuration Management: Configuration management is essentially the inventory management, library management and change management of the items important to the project. Important tasks in configuration management include:

1. Identification of the items that are important to the project,
2. Establishing repositories where these items will be kept,

• Maintaining consistency across carious items.

1. Handling changes to the controlled items in a systematic manner.

• Project Quality Assurance: Quality assurance focuses on how the engineering and management activities will be done. Quality assurance activities for a project include:

1. Identification of the lifecycle model to be used by the project.
2. Planning for reviews.

• Defining the strategy to be used for testing.

1. Planning for and performing audits on the projects.

software development in Jaipur now possible with best software development company in Jaipur that also provide website designing, seo and website development in Delhi  and in Mumbai as well.

Prototyping Model and its Types

Types of Prototyping Model

These are of two types:

1. Exploratory Development
2. Throwaway Prototyping

• Exploratory development:

Objective of Exploratory Development is to work with the user to explore their requirements and convey a final system.

 

Advantages of Exploratory development

1. The system is delivered quickly.
2. Users are implicated with the complete system development, and so are likely to feel a commitment to the success of the system.

• Throwaway Prototyping:

Objective of Throwaway Prototyping is to understand user’s constraint and develop a better requirements definition for the system. It concentrates on poorly understood components.

 

Advantages of Throwaway Prototyping:

1. Excellent for gathering and refining requirements.
2. Useful for assessing and reducing risks.

• Because the prototype will be discarded, “quick and dirty” programming techniques can be used.

Limitations of Throwaway Prototyping

1. Once an executable prototype exists, management or clients may want the prototype to be delivered as the final system.
2. since prototype may be different from the final system, users may not interact with the prototype in the same way, and so feedback based on the prototype may not apply to the final system.

What is Software Engineering ?

The term first appeared in the 1968 and was meant to provoke though regarding the “software crisis” at the time.

Software Engineering deals with cost effective solutions to practical problems and is the application of methods and scientific knowledge to generate practical cost-effective solutions for the design, construction, operation and maintenance of software.

Meaning and Definitions of Software Engineering

The term Software Engineering refers to a movement, methods and techniques aimed at constructing software development more systematic.

According to IEEE,  “Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintained of software, i.e., the application of engineering to software”.

According to Sommerville, “Software Engineering is connected with the theories, methods and that are needed to develop the software products in a cost effective way”.

Need of Software Engineering

• The deep concern for ‘software crisis’ has led to adaptation of Software Engineering practices.
• To give better quality to programs.
• Moreover the need of Software Engineering has evolved as early programmers used exploratory programming style.

Software Engineering Focuses on:

• Improving the productivity of the program/development process.
• Controlling and preceding the cost of software development.
• Producing what the customer wants.
• Producing software that have features like reliability, clarity, extensible.
• Summer Training 2016 in jaipur, seo training in jaipur

Software Myths

There are many myths associated with software development community. Some of them really affect the way of software development.

• Software is Easy to Change:

It is easy to edit source code file, but that is different than saying that software is easy to change. Making change   without introducing errors is extremely difficult, mostly with poor process development. Every change requires that the complete system be re-verified. Without proper care, this will be an extremely tedious and expensive process.

• Computers Provide Greater Reliability than the Device they Replace:

It is true that software does not fail in the traditional sense. There are no limits to how many times a given piece of code can be executed before it “wears out”. In any occurrence, the simple appearance of this myth is that user common ledgers are still not totally perfect, even though they have been computerized. Earlier in the days of manual accounting systems, human error was a fact of life. Now, we have software error as well.

• Testing Software or “Proving” Software Correct Can Remove all the Errors:

Testing always shows presence of errors it never shows absence of errors. The aim is to design effective test cases in order to find maximum possible errors. The more we test, the more we are confident about our design.

• Re-Using Software increase Safety:

This myth is particularly troubling because of the false sense of security that code re-uses can create. Code re-use is a very powerful tool that can yield dramatic improvement in development sufficiency, but it still requires analysis to determine its suitability and testing to determine if it works.

• Software can Work right the First Time:

If we ask to an aeronautical engineer to build a jet fighter craft, he will quote us a price. If we demand that it is to be put in production without building a prototype, he will laugh and possibly will refuse the job. however software engineers are often asked to do specifically this sort of work, and they often accept the job.

• Software Can be Designed thoroughly Enough to Avoid Most Integration Problems:

There is an old saying among software designers: “Too bad, there is no complier for specifications”: This point out the original difficulty with complete stipulation. They always have inconsistencies, and there is no computer tool to perform consistency checks on these. Therefore, special care is required to understand the specifications, and if there is an uncertainty, that should be resolved before proceeding for design.

• Software with more Features is Better Software:

This is, of course, almost the opposite of the truth. The best, most enduring programs are those which do one thing well.

• Addition of more Software Engineers will Make-Up the Delay:

• Aim is to Develop Working Programs

Software development company in jaipur provide complete software development solution to there clients in india and UK as well.

Hello world!

This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Happy blogging!