1 of 41

SOFTWARE PROCESS AND PROJECT METRICS,ANALYSIS CONCEPTS AND PRINCIPLES

MRS.BHAGYASHRI RAHUL JOSHI

2 of 41

Introduction

S/W process and product metrics are quantitative measures that enable software people to gain insights into the efficacy of the software process and the project that are conducted using the process as a framework

The term software specifies to the set of computer programs, procedures and associated documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used.

3 of 41

A software process is the set of activities and associated outcome that produce a software product. Software engineers mostly carry out these activities.

These are four key process activities, which are common to all software processes. These activities are:

  1. Software specifications: The functionality of the software and constraints on its operation must be defined.

  • Software development: The software to meet the requirement must be produced.

  • Software validation: The software must be validated to ensure that it does what the customer wants.

  • Software evolution: The software must evolve to meet changing client needs.

4 of 41

Measures

A standard or unit of measurement; the extent, dimensions, capacity etc. Of anything, especially as determined by standard; an act or process of measuring, a result of measurement.

Measurement:

is the act or process of measuring. A figure, extent or amount obtained by measuring. Also result, such as a figure expressing the extent or value that obtained by measuring.

Software measurement is a quantified attribute (see also: measurement) of a characteristic of a software product or the software process. It is a discipline within software engineering. The process of software measurement is defined and governed by ISO Standard ISO 15939 (software measurement process).

5 of 41

S/W measurement plays important role in S/W/ Engineering

S/W metrics are proving to be very effective for building high –quality prediction system for large database projects for-

  • Understanding and improving s/w development and maintenance projects,
  • Assessing and maintain system quality in high problematic areas
  • Determing the best way to help practitioners and researchers in their work.

Commonly used Measures are-

  • Number of Defects found in system
  • Lines of Code
  • Number of Test Cases

6 of 41

Reasons to use measure in Software process

  • To Characterize in order to:

  • To evaluate in order to:

  • To Predict in order to:

  • To improve in order to:

7 of 41

Metric Indicators

Metric

A quantitative measure of the degree to which a system,component,or process possesses a given attribute.

  • Number of defect found per KLOC
  • Productivity,i.e. Size/Effort
  • Defect Density

  • Important attribute of a metric:

  • Simple
  • Objective
  • Measurable
  • Meaningful
  • Easy to collect
  • Easy to interpret
  • Hard to Misinterpret
  • Valid
  • Reliable

8 of 41

Indicator

A device or variable that can be set to a prescribed state based on the results of a process or the occurrence of a specified condition.

For e.g. a flag or semaphore. A metric that provides insight into software development processes and software process and improvement activities concerning goal attainment.

  • S/W process and project metrics are quantitative measures.

  • They are a management tool.

  • They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework.

  • Basic quality and productivity data are collected.

9 of 41

Dependency

Order

People

Product

Project

Process

Factors of management Dependency

10 of 41

Role of management in software development

1) People

Of course, the management has to deal with people in every stage of the software developing process. From the ideation phase to the final deployment phase,

including the development and testing phases in between, there are people involved in everything, whether they be the customers or the developers,

the designers or the salesmen. Hence, how they contact and communicate with each other must be managed so that all the required

information is successfully delivered to

the relevant person and hence there is no communication gap between the customers and the service providers.

2) Project

From the ideation phase to the deployment phase, we term the process as a project. Many people work together on a project to build a final product that can be delivered to

the customer as per their needs or demands. So, the entire process that goes on while working on the project must be managed properly so that we can get

a worthy result after completing the project and also so that the project can be completed on time without any delay.

11 of 41

3) Process

Every process that takes place while developing the software, or we can say while working on the project must be managed properly and separately. For example,

there are various phases in a software development process and every phase has its process like the designing process is different from the coding process, and similarly,

the coding process is different from the testing. Hence, each process is managed according to its needs and each needs to be taken special care of.

4) Product

Even after the development process is completed and we reach our final product, still, it needs to be delivered to its customers. Hence the entire process needs a separate

management team like the sales department.

12 of 41

  1. Metrics in the Process and Project Domains

Metrics in the Process and Project Domains Project indicators enable a software project manager to

1) assess the status of an ongoing project

2) track potential risks

3) Uncover problem areas before they go “critical”

4) Adjust work flow or tasks, and

5) Evaluate the project team’s ability to control quality of software work products

Process Metrics and Software Process Improvement

We measure the efficacy of a software process indirectly; we derive a set of metrics based on the outcomes that can be derived from the process.

13 of 41

  1.  Process Metrics and Software Process Improvement A software metrics etiquette:
  2. • Use common sense an organizational sensitivity when interpreting metrics data
  3. • Provide regular feedback to the individuals and teams who collect measures and metrics
  4. • Don’t use metrics to appraise individuals • Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Cont..
  5.  Process Metrics and Software Process Improvement A software metrics etiquette (cont.):
  6. • Never use metrics to threaten individuals or teams • Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement. • Don’t obsess on a single metric to the exclusion of other important metrics.

14 of 41

  1. Process Metrics and Software Process Improvement A more rigorous approach: statistical software process improvement (SSPI):
  2. 1. All errors and defects are categorized by origin (flaw in spec, flaw in logic, nonconformance to standards).
  3. 2. The cost to correct each error and defect is recorded.
  4. 3. The number of errors and defects in each category is counted and ranked in descending order.

15 of 41

  1.  Process Metrics and Software Process Improvement SPPI :
  2. 4. The overall cost of errors and defects in each category is computed.
  3. 5. Resultant data are analyzed to uncover the categories that result in the highest cost to the organization.
  4. 6. Plans are developed to modify the process with the intent of eliminating (or reducing the frequency of) the class of errors and defects that is most costly.
  5. 4. Project Metrics • Project metrics are used by a project manager and a software team to adapt project work flow and technical activities. • Occurred during: • estimation  monitor and control progress. • production rates: pages of documentation, review hours, function points, and delivered source lines. • errors • technical metrics  quality
  6.  

16 of 41

  1. Project Metrics The intent of project metrics are two folds: - to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems. - to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.
  2. 15. Project Metrics Another model of project metrics suggests that every project should measure: • Inputs – measures of the resources required to do the work • Outputs – measures of the deliverables or work products created during the software engineering process • Results – measures that indicate the effectiveness of the deliverables

17 of 41

  1. Software Measurement

• Direct measures of SE process include cost and effort. Direct measures of product include LOC produced, execution speed, memory size, and defects reported over some set period of time.

• Indirect measures of product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other “-abilities”

  1. Size-oriented Metrics • Derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced.

 Size-oriented Metrics Then we can develop a set of simple size-oriented metrics: • Errors per KLOC • Defects per KLOC • $ per LOC • Page of documentation per KLOC And other interesting metrics can be computed: • Errors per person-month, LOC per person-month, $ per page of documentation.

18 of 41

  1. Function-Oriented Metrics Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity

Function-Oriented Metrics • Use a measure of the functionality delivered by the application as a normalization value. • Functionality can not be measured directly, it must be derived indirectly using other direct measures. • A measure called the function point.

19 of 41

Metric for Software Quality

Correctness

A Program must operate correctly.

Maintainability:

S/W maintains account for more effort than any other S/W engineering Activity.

Integrity:

This measures a system ability to withstand attacks to its security.

Defect Removal Efficiency(DRE):

A quality metric that provides benefit at both the project and process level is DRE

DRE= E/(E+D)

E- number of errors found before delivery of the software to end user

D-number of defect found after work product delivery

20 of 41

Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. It ensures that developed software meets and complies with the defined or standardized quality specifications. SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired quality measures.

21 of 41

Following activities are performed by an independent SQA group:

  1. Prepares an SQA plan for a project: 

The program is developed during project planning and is reviewed by all stakeholders. The plan governs quality assurance activities performed by the software engineering team and the SQA group. The plan identifies calculation to be performed, audits and reviews to be performed, standards that apply to the project, techniques for error reporting and tracking, documents to be produced by the SQA team, and amount of feedback provided to the software project team.

2.Participates in the development of the project's software process description: 

The software team selects a process for the work to be performed. The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g. ISO-9001), and other parts of the software project plan.

3.Reviews software engineering activities to verify compliance with the defined software process:

 The SQA group identifies, reports, and tracks deviations from the process and verifies that corrections have been made.

22 of 41

4.Audits designated software work products to verify compliance with those defined as a part of the software process: 

The SQA group reviews selected work products, identifies, documents and tracks deviations, verify that corrections have been made, and periodically reports the results of its work to the project manager.

5.Ensures that deviations in software work and work products are documented and handled according to a documented procedure:

 Deviations may be encountered in the project method, process description, applicable standards, or technical work products.

6.Records any noncompliance and reports to senior management:

 Non- compliance items are tracked until they are resolved.

23 of 41

CMMI(Capability Maturity Model Integration)

CMMI stand for Capability Maturity Model Integration. It is a process improvement approach that provide companies with the essential element of an effective process.

C Capability

M Maturity

M Model

I Integration

System Engineering

Software Engineering

Integrated Product

Training

Software Acquisition

CMMI(Capability Maturity Model Integration

24 of 41

System Engineering: This cover development of total Systems. System engineers concentrate on converting customer needs to product solution and support them throughout the product lifecycle.

Software Engineering: Software engineers concentrate on the application of systematic, disciplined, and quantifiable approaches to the development, operation and maintenance of software.

�Integrated Product and Process Development (IPPD): Integrated Product and Process Development PPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs expectations, and requirements.

This section mot concentrates on the integration part of the project for different processes. For instance, it's possible that your project is using services of some other third party component. In such situations the integration is a big task itself, and approached in a systematic manner, can be handed with ease.

Software Acquisition: Many times an organization has to acquire products from other organizations. Acquisition is itself a big step for any organization and handled in a proper manner means a disaster is sure to happen.

25 of 41

Six Sigma:

Sigma is a accurate and proven business methodology that uses

data and status to improve business performance With the goal

of increasing profits by eliminate waste, and rework Six Sigma provides

a means to dry and prevent pro or defects to improve predictability and

success of business processes

Sigma certification confirms a level of training, practice, and capability with reaper competencies. Though requirements for each Six Sigma certification level

26 of 41

IS0 9000

ISO 9000 series of standards, developed and published by the International Organization for Standardization, that define, establish, and maintain an effective quality assurance system for manufacturing and service industries.

The 1SO 9000 standard is the most widely known and has perhaps had the most impact of the 13,000 standards published by the IS0. It serves many different industries and organizations as a guide quality products, service, and management.

An organization can be 150 9000-Cartiled If it successfully follows the ISO 9000 standards for its industry. In order to be certified, the organization must submit to an examination by an outside assessor. The assessor interviews staff members to ensure that ,they understand their part in complying with the 1SO 9000 standard.

  • examines the organization paperwork to ensure 1SO 9000
  • prepares a detailed report that describes the parts of the
  • The organization then agrees to correct any problems w
  • ����

27 of 41

Requirement Analysis

Requirements analysis is the first stage in the systems engineering process

and software development process.

Requirements analysis in systems engineering and

software engineering, encompasses those tasks that

go into determining the needs or conditions meet for

a new or altered product taking account of the possibly

conflicting requirement the various stakeholders, such

as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must be actionable, measures testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional.

28 of 41

Overview conceptually, requirements analysis includes three types of activity

Eliciting requirements: The task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements

Gathering.

Analyzing requirements: Determining whether the stated requirements are unclear

Incomplete, ambiguous, of contradictory, and then resolving these issues.

Recording requirements: Requirements might be documented in various forms, such as Natural language documents, use cases, user stories, or process specifications.

�Requirements analysis can be a long and difficult process during which many delicate psychological skills are involved.

New systems change the environment and relation between people, so it is important to identify all the stakeholders, take into account a needs and ensure they understand the implications of the new systems.

Analysts can employ several techniques to elicit the requirements from the customer.

29 of 41

Historically, this has included such things as holding interviews, or holding focus groups (more aptly nan this context as requirements workshops) and creating requirements lists More m techniques include prototyping, and use cases. Where necessary, the analyst will employ combination of these methods to establish the exact requirements of the stakeholder that a system that meets the business needs is produced.

Requirements analysis:

This is a process of discovery, refinement, modeling and specification.

During the process, both the developers and customers take an active role

This process focus on: "what" instead of "how

�Input of the requirements analysis process - Software Project Plan and specification

�Output: Software requirements specification document

�o Provides the software engineer with models that can be translated into a architectural, interface, and procedure design

�Customer and developer can check the quality of the software and prov

��

30 of 41

Analysis Principles

 

Over the past two decades, a large number of analysis modeling methods have been developed. Investigators have identified analysis problems and their causes and have developed a variety of notations and corresponding sets of heuristics to overcome them. Each analysis method has a unique point of view.

 

  • The information domain of a problem must be represented and understood.
  • The functions that the software is to perform must be defined.
  • The behavior of the software must be represented.
  • The models that depict information function and behavior must be partitioned in a manner that uncovers details in a layered fashion.
  • The analysis process should move from essential information toward implementation detail.

 

31 of 41

Communication Techniques

Reasons of Trouble for software Projects

  • Scale
  • Uncertainty
  • Interoperability

Types Of Communication

  • Formal Communication
  • Informal Communication

32 of 41

Tips to become a better communicator in software engineering

  • Be brief

  • Share information and improve communication

  • Listen carefully

  • Ask questions

  • Understand customer requirements

  • Attack the problem but not the person

  • Communication channel

33 of 41

What is Software Prototyping?

Prototype is a working model of software with some limited functionality. The prototype does not always hold the exact logic used in the actual software application and is an extra effort to be considered under effort estimation.

Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps understand the requirements which are user specific and may not have been considered by the developer during product design.

The Software Prototyping refers to building software application prototypes which display the functionality of the product under development but may not actually hold the exact logic of the original software.

Software prototyping is becoming very popular as a software development model, as it enables to understand customer requirements at an early stage of development.

It helps get valuable feedback from the customer and helps software designers and developers understand about what exactly is expected from the product under development.

34 of 41

Following is the stepwise approach to design a software prototype:

Basic Requirement Identification:

This step involves understanding the very basics product requirements especially in terms of user interface. The more intricate details of the internal design and external aspects like performance and security can be ignored at this stage.

Developing the initial Prototype:

The initial Prototype is developed in this stage, where the very basic requirements are showcased and user interfaces are provided. These features may not exactly work in the same manner internally in the actual software developed and the workarounds are used to give the same look and feel to the customer in the prototype developed.

Review of the Prototype:

The prototype developed is then presented to the customer and the other important stakeholders in the project. The feedback is collected in an organized manner and used for further enhancements in the product under development.

Revise and enhance the Prototype:

The feedback and the review comments are discussed during this stage and some negotiations happen with the customer based on factors like , time and budget constraints and technical feasibility of actual implementation. The changes accepted are again incorporated in the new Prototype developed and the cycle repeats until customer expectations are met.

35 of 41

Software Prototyping - Pros and Cons

Software prototyping is used in typical cases and the decision should be taken very carefully so that the efforts spent in building the prototype add considerable value to the final software developed. The model has its own pros and cons discussed as follows.

The advantages of the Prototyping Model are as follows −

  • Increased user involvement in the product even before its implementation.

  • Since a working model of the system is displayed, the users get a better understanding of the system being developed.

  • Reduces time and cost as the defects can be detected much earlier.

  • Quicker user feedback is available leading to better solutions.

  • Missing functionality can be identified easily.

  • Confusing or difficult functions can be identified.

36 of 41

The Disadvantages of the Prototyping Model are as follows −

  • Risk of insufficient requirement analysis owing to too much dependency on the prototype.

  • Users may get confused in the prototypes and actual systems.

  • Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

  • Developers may try to reuse the existing prototypes to build the actual system, even when it is not technically feasible.

  • The effort invested in building prototypes may be too much if it is not monitored properly.

37 of 41

Software Prototyping Types There are different types of software prototypes used in the industry. Following are the major software prototyping types used widely:

Throwaway/Rapid Prototyping:

Throwaway prototyping is also called as rapid or close ended prototyping.

This type of prototyping uses very little efforts with minimum requirement analysis to build a prototype. Once the actual requirements are understood, the prototype is discarded and the actual system is developed with a much clear understanding of user requirements.

38 of 41

Evolutionary Prototyping:

Evolutionary prototyping also called as breadboard prototyping is based on building actual functional prototypes with minimal functionality in the beginning. The prototype developed forms the heart of the future prototypes on top of which the entire system is built. Using evolutionary prototyping only well understood requirements are included in the prototype and the requirements are added as and when they are understood.

39 of 41

Incremental Prototyping:

Incremental prototyping refers to building multiple functional prototypes of the various sub systems and then integrating all the available prototypes to form a complete system

40 of 41

. Extreme Prototyping : Extreme prototyping is used in the web development domain. It consists of three sequential phases. First, a basic prototype with all the existing pages is presented in the html format. Then the data processing is simulated using a prototype services layer. Finally the services are implemented and integrated to the final prototype. This process is called Extreme Prototyping used to draw attention to the second phase of the process, where a fully functional UI is developed with very little regard to the actual services. Software Prototyping Application Software Prototyping is most useful in development of systems having high level of user interactions such as online systems. Systems which need users to fill out forms or go through

41 of 41

Important Questions

    • What is software metrics?
    • Define the term LOC.
    • What is Software quality assurance (SQA) ?
    • Define the term metrics

4 marks

  1. Describe types of requirement in detail.
  2. Write on advantages and disadvantages of prototyping model.
  3. Write on Role of Requirement Analysis in Software Process.
  4. Write on Complexity metrics in detail.
  5. Describe software quality assurance in detail.
  6. Explain communication techniques used in software development process.
  7. Write a short note on analysis principles in software process.
  8. Write down the pros and cons in software prototyping.
  9. Describe Software Quality Management in detail.