SPM UNIT-IV

 

UNIT – IV

Process Automation: Automation Building Blocks, the Project Environment.

Project Control and Process instrumentation: The seven core Metrics, Management indicators, and quality indicators tailoring the Process: Process discriminates. Managing people and organizing teams.

 

PROCESS AUTOMATION

Process Automation is the use of software tools, scripts, platforms, and automated workflows to reduce manual effort in software project activities.

It aims to:

• Improve productivity
• Reduce human error
• Speed up development
• Ensure repeatability of tasks
• Improve quality and consistency

Automation bridges the gap between human activities and machine-executable processes.

Introductory Remarks:

·         The environment must be the first-class artifact of the process.

·         Process automation & change management is critical to an iterative process. If the change is expensive then the development organization will resist it.

·         Round-trip engineering & integrated environments promote change freedom & effective evolution of technical artifacts.

·         Metric automation is crucial to effective project control.

·         External stakeholders need access to environment resources to improve interaction with the development team & add value to the process.

The three levels of process which requires a certain degree of process automation for the corresponding process to be carried out efficiently.

·        Metaprocess (Line of business): The automation support for this level is called an infrastructure.

·        Macroproces (project): The automation support for a project’s process is called an environment.

·        Microprocess (iteration): The automation support for generating artifacts is generally called a tool.

 

AUTOMATION BUILDING BLOCKS:

 

THE PROJECT ENVIRONMENT:

Round trip Engineering

Change management

 

PROJECT CONTROL & PROCESS INSTRUMENTATION

INTERODUCTION:

Software metrics are used to implement the activities and products of the software development process. Hence, the quality of the software products and the achievements in the development process can be determined using the software metrics.

Need for Software Metrics: 

·         Software metrics are needed for calculating the cost and schedule of a software product with great accuracy. 

·         Software metrics are required for making an accurate estimation of the progress.

·         The metrics are also required for understanding the quality of the software product.

 INDICATORS:

An indicator is a metric or a group of metrics that provides an understanding of the software process or software product or a software project. A software engineer assembles measures and produce metrics from which the indicators can be derived.

Two types of indicators are:

(i)                 Management indicators.

(ii)               Quality indicators.

Management Indicators The management indicators i.e., technical progress, financial status and staffing progress are used to determine whether a project is on budget and on schedule. The management indicators that indicate financial status are based on earned value system.

Quality Indicators The quality indicators are based on the measurement of the changes occurred in software.

 

THE SEVEN CORE METRICS:

Software metrics instrument the activities and products of the software development/integration process. Metrics values provide an important perspective for managing the process. The most useful metrics are extracted directly from the evolving artifacts.

There are seven core metrics that are used in managing a modern process.

Seven core metrics related to project control:

Management Indicators

·         Work and Progress

·         Budgeted cost and expenditures

·         Staffing and team dynamics

Quality Indicators

·         Change traffic and stability

·         Breakage and modularity

·         Rework and adaptability

·         Mean time between failures (MTBF) and maturity

 

MANAGEMENT INDICATORS:

Work and progress:

This metric measure the work performed over time. Work is the effort to be accomplished to complete a certain set of tasks. The various activities of an iterative development project can be measured by defining a planned estimate of the work in an objective measure, then tracking progress (work completed overtime) against that plan.

The default perspectives of this metric are:

Software architecture team: - Use cases demonstrated.

Software development team: - SLOC under baseline change management, SCOs closed

Software assessment team: - SCOs opened, test hours executed and evaluation criteria meet.

Software management team: - milestones completed. The below figure shows expected progress for a typical project with three major releases

The below figure shows expected progress for a typical project with three major releases

 

Budgeted cost and expenditures:

This metric measures cost incurred over time. Budgeted cost is the planned expenditure profile over the life cycle of the project. To maintain management control, measuring cost expenditures over the project life cycle is always necessary. Tracking financial progress takes on an organization - specific format. Financial performance can be measured by the use of an earned value system, which provides highly detailed cost and schedule insight. The basic parameters of an earned value system, expressed in units of dollars, are as follows:

·         Expenditure Plan - It is the planned spending profile for a project over its planned schedule. Actual progress - It is the technical accomplishment relative to the planned progress underlying the spending profile.

·         Actual cost: It is the actual spending profile for a project over its actual schedule.

·         Earned value: It is the value that represents the planned cost of the actual progress.

·         Cost variance: It is the difference between the actual cost and the earned value.

·         Schedule variance: It is the difference between the planned cost and the earned value. Of all parameters in an earned value system, actual progress is the most subjective

·         Assessment: Because most managers know exactly how much cost they have incurred and how much schedule they have used, the variability in making accurate assessments is cantered in the actual progress assessment. The default perspectives of this metric are cost per month, full-time staff per month and percentage of budget expended.

 

Staffing and team dynamics:

This metric measure the personnel changes over time, which involves staffing additions and reductions over time. An iterative development should start with a small team until the risks in the requirements and architecture have been suitably resolved. Depending on the overlap of iterations and other project specific circumstances, staffing can vary. Increase in staff can slow overall project progress as new people consume the productive team of existing people in coming up to speed. Low attrition of good people is a sign of success. The default perspectives of this metric are people per month added and people per month leaving.

These three management indicators are responsible for technical progress, financial status and staffing progress

 

QUALITY INDICATORS:

Change traffic and stability:

This metric measures the change traffic over time. The number of software change orders opened and closed over the life cycle is called change traffic. Stability specifies the relationship between opened versus closed software change orders. This metric can be collected by change type, by release, across all releases, by term, by components, by subsystems, etc.

The below figure shows stability expectation over a healthy project’s life cycle

Breakage and modularity:

 This metric measures the average breakage per change over time. Breakage is defined as the average extent of change, which is the amount of software baseline that needs rework and measured in source lines of code, function points, components, subsystems, files or other units. Modularity is the average breakage trend over time. This metric can be collected by rewoke SLOC per change, by change type, by release, by components and by subsystems.

Rework and adaptability:

This metric measures the average rework per change over time. Rework is defined as the average cost of change which is the effort to analyze, resolve and retest all changes to software baselines. Adaptability is defined as the rework trend over time. This metric provides insight into rework measurement. All changes are not created equal. Some changes can be made in a staff- hour, while others take staff-weeks. This metric can be collected by average hours per change, by change type, by release, by components and by subsystems.

MTBF and Maturity:

This metric measures defect rate over time. MTBF (Mean Time between Failures) is the average usage time between software faults. It is computed by dividing the test hours by the number of type 0 and type 1 SCOs. Maturity is defined as the MTBF trend over time.

Software errors can be categorized into two types deterministic and nondeterministic. Deterministic errors are also known as Bohr-bugs and nondeterministic errors are also called as Heisen-bugs.

Bohr-bugs are a class of errors caused when the software is stimulated in a certain way such as coding errors. Heisen-bugs are software faults that are coincidental with a certain probabilistic occurrence of a given situation, such as design errors. This metric can be collected by failure counts, test hours until failure, by release, by components and by subsystems.

These four quality indicators are based primarily on the measurement of software change across evolving baselines of engineering data.

TAILORING THE PROCESS:

 

 

 

PROCESS DISCRIMINATES:

   

 

 

Examples for small scale Project vs.  Large scale Project

 

  

MANAGING PEOPLE AND ORGANIZING TEAMS:

I. Managing People in Software Projects

Software development is a people-oriented activity. Effective management of human resources ensures project success.

1. Staffing

Staffing involves selecting and assigning suitable personnel to project roles.

Activities:

• Identify required skills
• Recruit suitable candidates
• Assign roles and responsibilities

Common Roles:

• Project Manager
• System Analyst
• Designer
• Developer/Programmer
• Tester
• Maintenance Engineer

Staffing Considerations:

• Technical expertise
• Experience
• Communication skills
• Team compatibility
• Problem-solving ability

 

2. Motivations

Motivation improves productivity and job satisfaction.

Maslow’s Hierarchy of Needs

1. Physiological Needs (salary)
2. Safety Needs (job security)
3. Social Needs (team belonging)
4. Esteem Needs (recognition)
5. Self-Actualization (career growth)

Herzberg’s Two-Factor Theory

• Hygiene Factors: salary, working conditions, job security
• Motivators: achievement, recognition, responsibility, growth

 

3. Leadership

Leadership influences team performance and morale.

Leadership Styles:

• Autocratic – Leader makes decisions alone
• Democratic – Team participates in decision-making
• Laissez-faire – Minimal supervision
• Transactional – Reward and punishment based
• Transformational – Inspires and motivates team

 

4. Communication

Effective communication reduces project risks.

Types:

• Formal (meetings, reports)
• Informal (casual discussions)
• Verbal / Written

Communication Channels Formula:

n(n-1)/2

Where n = number of team members

More team members → More communication overhead.

 

5. Conflict Management

Conflicts may arise due to:

• Technical disagreements
• Resource allocation
• Schedule pressure
• Personality clashes

Conflict Resolution Techniques:

• Avoiding
• Compromising
• Collaborating (most effective)
• Forcing
• Smoothing

 

II. Organizing Teams in SPM

Team organization defines reporting relationships and communication structure.

1. Team Organizational Structures

 Democratic Decentralized (DD)

• No permanent leader
• Decisions by group consensus
• Horizontal communication
• Suitable for research projects

 

Controlled Decentralized (CD)

• Leader present
• Group-based problem solving
• Both horizontal and vertical communication
• Most commonly used structure

 

Controlled Centralized (CC)

• Strong leader
• Top-down decision-making
• Mainly vertical communication
• Suitable for small/simple projects

 

III. Team Development Stages (Tuckman Model)

1. Forming – Team members get introduced
2. Storming – Conflicts and disagreements occur
3. Norming – Cooperation and coordination improve
4. Performing – High productivity and efficiency
5. Adjourning – Project completion and team dissolution

 

IV. Team Size Considerations

• Small teams → Better coordination
• Large teams → Increased communication overhead
• Ideal team size → 5 to 10 members (depends on project size)

 

V. Factors Affecting Team Performance

• Clear project goals
• Strong leadership
• Proper training
• Effective communication
• Motivation
• Trust among members
• Adequate resources

 

VI. Role of Project Manager

The Project Manager is responsible for:

• Planning and scheduling
• Assigning tasks
• Monitoring progress
• Risk management
• Conflict resolution
• Motivating the team
• Ensuring timely delivery

 

 

 

*********END of UNIT IV*********