Unit-2 Project Management

Que 1. Explain the concept of project management in brief.

Explain the importance of process in software project management.

Explain 4P’s software project management.

Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the definition, development, and support of computer software. Effective software project management focuses on the four P’s: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management.

This following are the 4 P’s in software project management:

People

1) In fact, the “people factor” is so important to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability.

2) The following key practice areas for software people: recruiting, selection, performance management, training. organization and work design, and team/culture compensation, development.

Product

1) Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints should be identified.

2) The software developer and customer must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or business process engineering.

3) Product scope and objectives must be defined. 4) Product Scope identifies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner.

Process

1) A software process provides the framework from which a comprehensive plan for software development can be established.

2) A small number of framework activities are applicable to all software projects, regardless of their size or complexity.

3) A number of different tasks set tasks, milestones, work products, and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.

4) Finally, umbrella activities such as software quality assurance, software configuration management, and measurement overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process.

Project

1) In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right.

2) Project Manager has to develop a commonsense approach for planning, monitoring and controlling the project.

3) In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management.

Que 2. What do you mean by metrics for software measurement?

Software Measurement

 A measurement is a manifestation of the size, quantity, amount, or dimension of a particular attribute of a product or process.Software measurement is a titrate impute of a characteristic of a software product or the software process. It is an authority within software engineering. The software measurement process is defined and governed by ISO Standard.

Software Measurement Principles: 

The software measurement process can be characterized by five activities:

1. Formulation: The derivation of software measures and metrics appropriate for the representation of the software that is being considered.
2. Collection: The mechanism used to accumulate data required to derive the formulated metrics.
3. Analysis: The computation of metrics and the application of mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into the quality of the representation.
5. Feedback: Recommendation derived from the interpretation of product metrics transmitted to the software team.

Need for Software Measurement: 

Software is measured to: 

• Create the quality of the current product or process.
• Anticipate future qualities of the product or process.
• Enhance the quality of a product or process.
• Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement: In direct measurement, the product, process, or thing is measured directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality to be measured is measured using related parameters i.e. by use of reference.

Metrics: 

A metric is a measurement of the level at which any impute belongs to a system product or process. Software metrics will be useful only if they are characterized effectively and validated so that their worth is proven.

There are 4 functions related to software metrics: 

1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics: 

1. Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed in values.
2. Understandable: Metric computation should be easily understood, and the method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the development of the software.
4. Repeatable: The metric values should be the same when measured repeatedly and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming language.

Classification of Software Metrics:

There are 3 types of software metrics:  

1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and undercover prospective problem areas. The ability of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term process of the team or organization.
3. Project Metrics: The project matrix describes the project characteristic and execution process. 
   • Number of software developer
   • Staffing patterns over the life cycle of software
   • Cost and schedule
   • Productivity

Advantages of Software Metrics :

1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,.
6. It helps to determine the complexity of the code and to test the code with resources.
7. It helps in providing effective planning, controlling and managing of the entire product.

Disadvantages of Software Metrics:

1. It is expensive and difficult to implement the metrics in some cases.
2. Performance of the entire team or an individual from the team can’t be determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

Que 3. Explain the object oriented metrics.

Lines of code and functional point metrics can be used for estimating object-oriented software projects. However, these metrics are not appropriate in the case of incremental software development as they do not provide adequate details for effort and schedule estimation. Thus, for object-oriented projects, different sets of metrics have been proposed. These are listed below.

• Number of scenario scripts: Scenario scripts are a sequence of steps, which depict the interaction between the user and the application. A number of scenarios is directly related to application size and number of test cases that are developed to test the software, once it is developed. Note that scenario scripts are analogous to use-cases.
• Number of key classes: Key classes are independent components, which are defined in object -oriented analysis. As key classes form the core of the problem domain, they indicate the effort required to develop software and the amount of ‘reuse’ feature to be applied during the development process.
• Number of support classes: Classes, which are required to implement the system but are indirectly related to the problem domain, are known as support classes. For example, user interface classes and computation class are support classes. It is possible to develop a support class for each key class. Like key classes, support classes indicate the effort required to develop software and the amount of ‘reuse’ feature to be applied during the development process.
• Average number of support classes per key class: Key classes are defined early in the software project while support classes are defined throughout the project. The estimation process is simplified if the average number of support classes per key class is already known.
• Number of subsystems: A collection of classes that supports a function visible to the user is known as a subsystem. Identifying subsystems makes it easier to prepare a reasonable schedule in which work on subsystems is divided among project members.

The afore-mentioned metrics are collected along with other project metrics like effort used, errors and defects detected, and so on. After an organization completes a number of projects, a database is developed, which shows the relationship between object-oriented measure and project measure. This relationship provides metrics that help in project estimation.

Also Read – Mojo🔥 Programming Language: Empowering the Revolution in AI Development in 2023

Que 4. Explain Indicators.

Indicators are used to provide insight into the software quality and can be based on metrics or qualitative data. Indicators are often expressed as subjective statements or qualitative observations and are used to provide a general indication of the quality of software products or processes.

For example, the defect density is a metric used to measure the number of defects in a software product per unit of code. A low defect density may be an indicator of good software quality, but it is not a guarantee of high-quality software, as other factors such as usability, reliability, and maintainability also contribute to overall software quality.

Similarly, user satisfaction may be an indicator of software quality, but it is not a metric, as it cannot be expressed in terms of quantitative measurements. User satisfaction may be measured through surveys or feedback, and can provide insight into the user experience and overall quality of the software product.

Both metrics and indicators are important for evaluating software quality, and they are often used together to provide a comprehensive view of the quality of software products or processes.

Que 5. Explain Measuring Software Quality using Quality Metrics. (Metrics for software quality)

In Software Engineering, Software Measurement is done based on some Software Metrics where these software metrics are referred to as the measure of various characteristics of a Software. 

In Software engineering Software Quality Assurance (SAQ) assures the quality of the software. Set of activities in SAQ are continuously applied throughout the software process. Software Quality is measured based on some software quality metrics. 

There is a number of metrics available based on which software quality is measured. But among them, there are few most useful metrics which are most essential in software quality measurement. They are – 

1. Code Quality
2. Reliability
3. Performance
4. Usability
5. Correctness
6. Maintainability
7. Integrity
8. Security

Now let’s understand each quality metric in detail –

1. Code Quality – Code quality metrics measure the quality of code used for the software project development. Maintaining the software code quality by writing Bug-free and semantically correct code is very important for good software project development. In code quality both Quantitative metrics like the number of lines, complexity, functions, rate of bugs generation, etc, and Qualitative metrics like readability, code clarity, efficiency, maintainability, etc are measured. 
2. Reliability – Reliability metrics express the reliability of software in different conditions. The software is able to provide exact service at the right time or not is checked. Reliability can be checked using Mean Time Between Failure (MTBF) and Mean Time To Repair (MTTR). 
3. Performance – Performance metrics are used to measure the performance of the software. Each software has been developed for some specific purposes. Performance metrics measure the performance of the software by determining whether the software is fulfilling the user requirements or not, by analyzing how much time and resource it is utilizing for providing the service. 
4. Usability – Usability metrics check whether the program is user-friendly or not. Each software is used by the end-user. So it is important to measure that the end-user is happy or not by using this software. 
5. Correctness – Correctness is one of the important software quality metrics as this checks whether the system or software is working correctly without any error by satisfying the user. Correctness gives the degree of service each function provides as per developed. 
6. Maintainability – Each software product requires maintenance and up-gradation. Maintenance is an expensive and time-consuming process. So if the software product provides easy maintainability then we can say software quality is up to mark. Maintainability metrics include time requires to adapt to new features/functionality, Mean Time to Change (MTTC), performance in changing environments, etc. 
7. Integrity – Software integrity is important in terms of how much it is easy to integrate with other required software’s which increases software functionality and what is the control on integration from unauthorized software’s which increases the chances of cyberattacks. 
8. Security – Security metrics measure how much secure the software is? In the age of cyber terrorism, security is the most essential part of every software. Security assures that there are no unauthorized changes, no fear of cyber attacks, etc when the software product is in use by the end-user. 

Que 6. Compare and contrast the process metrics and the project metrics for software quality.

Process Metrics

Process metrics are a type of software quality metric that measure the efficiency and effectiveness of the software development process. These metrics are used to monitor and improve the development process and help software development teams identify areas for improvement.

Some common process metrics include:

1. Defect density: This measures the number of defects found in a unit of code or product. It is usually calculated as the number of defects found divided by the size of the code or product.
2. Cycle time: This measures the time it takes for a software development team to complete a task or a set of tasks. It includes the time spent on planning, coding, testing, and deployment.
3. Lead time: This measures the time it takes for a software development team to complete a task or a set of tasks, from the time it was requested to the time it was delivered.
4. Code churn: This measures the amount of code that is changed during a development cycle, and can be an indicator of how much effort is being spent on refactoring or debugging.
5. Test coverage: This measures the percentage of the code or product that is covered by automated tests. It can be an indicator of how well the product is being tested and how many defects are being caught.

By measuring and analyzing these process metrics, software development teams can identify areas for improvement and make changes to improve the efficiency and effectiveness of their development process.

Project Metrics

Software process metrics are used for strategic purposes. Software project measures are tactical. That is, project metrics and the indicators derived from them are used by a project manager and a software team to adapt project work flow and technical activities.

The first application of project metrics on most software projects occurs during estimation. Metrics collected from past projects are used as a basis from which effort and time estimates are made for current software work. As a project proceeds, measures of effort and calendar time expended are compared to original estimates (and the project schedule). The project manager uses these data to monitor and control progress.

As technical work commences, other project metrics begin to have significance.

Production rates represented in terms of pages of documentation, review hours, function points, and delivered source lines are measured.

Comparision

Process metrics and project metrics are two types of metrics used to measure software quality.

Process metrics focus on the software development process itself and are used to monitor and improve the efficiency and effectiveness of the development process. Examples of process metrics include the number of defects found during development, the time taken to fix defects, and the number of code changes made during development.

On the other hand, project metrics are used to evaluate the overall quality of the software project, including its end product. Examples of project metrics include the number of defects reported by end-users, the number of crashes or failures experienced by users, and the response time of the software.

The main difference between process metrics and project metrics is that process metrics are focused on measuring the software development process, while project metrics are focused on measuring the quality of the software product itself. Process metrics are used to monitor and improve the development process, while project metrics are used to assess the quality of the final product.

Both process metrics and project metrics are important for software quality assurance. Process metrics can help identify areas of the development process that need improvement, while project metrics can help identify areas of the software product that need improvement. By using both types of metrics, software development teams can ensure that they are producing high-quality software efficiently and effectively.

Que 7. Explain W5HH principle in detail.

Barry Boehm states: “We need an organizing principle that scales down to provide simple plans for simple projects.”

Boehm suggests an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches, and required resources. He calls it the W5HH principle, after a series of questions that lead to a definition of key project characteristics and the resultant project-plan:

Why is the system being developed?

The answer to this question enables all parties to assess the validity of business reasons for the software work. Stated in another way, does the business purpose justify the expenditure of people, time, and money?

What will be done, by when?

The answers to these questions help the team to establish a project schedule by identifying key project tasks and the milestones that are required by the customer.

Who is responsible for a function?

The role and responsibility of each member of the software team must be defined. The answer to this question helps accomplish this.

Where are they organizationally located?

Not all roles and responsibilities reside within the software team itself. customer, users, and other stakeholders also have responsibilities.

How will the job be done technically and managerially?

Once product scope is established, a management and technical strategy for the project must be defined.

How much of each resource is needed?

The answer to this question is derived by developing estimates based on answers to earlier questions.

Boehm’s WSHH principle is applicable regardless of the size or complexity of a software project. The questions noted provide an excellent planning outline for the project manager and the software team.

Que 8. What are critical software practices?

The critical software practices for performance based management are “consistently used by, and considered critical by, highly successful software projects and organizations whose ‘bottom line’ performance is consistently much better than industry averages”,

In an effort to enable a software organization to determine whether a specific project has implemented critical practices are as-

Formal Risk Management:

What are the top ten risks for this project?

For each of the risks, what is the chance that the risk will become a problem and what is the impact if it does?

Empirical Cost and Schedule Estimation:

What is the current estimated size of the application software (excluding system software) that will be delivered into operation?

How was it derived?

Metric-based Project Management:

Do you have in place a metrics program to give an early indication of evolving problems?

If so, what is the current requirements volatility?

Earned Value Tracking:

Do you report monthly earned value metrics?

If so, are these metrics computed from an activity network of tasks for the entire effort to the next delivery?

Defect Tracking against Quality Targets:

Do you track and periodically report the number of defects found by each inspection (formal technical review) and execution test from program inception and the number of defects currently closed and open?

People-aware Program Management:

What is the average staff turnover for the past three months for each of the suppliers or developers involved in the development of software for this system?

If a software project team cannot answer these questions or answers them inadequately, a thorough review of project practices is indicated.

Que 9. Explain risk management in brief.

Risk management is a sequence of steps that help a software team to understand, analyze and manage uncertainty. Risk management consists of

• Risk Identification
• Risk analysis
• Risk Planning
• Risk Monitoring 

Following are the categories of the risk:

1. Project risk

• If the project risk is real then it is probable that the project schedule will slip and the cost of the project will increase.
• It identifies the potential schedule, resource, stakeholders and the requirements problems and their impact on a software project.

2. Technical risk

• If the technical risk is real then the implementation becomes impossible.
• It identifies potential design, interface, verification and maintenance of the problem.

3. Business risk

• This type of risk embodies the risks of building a superb product that nobody needs, losing monetary funds or personal commitments, etc. 

Risk identification

Some of approaches for risk identification are given below:

1. Checklist Analysis

Checklist Analysis is type of technique generally used to identify or find risks and manage it. The checklist is basically developed by listing items, steps, or even tasks and is then further analyzed against criteria to just identify and determine if procedure is completed correctly or not. It is list of risk that is just found to occur regularly in development of software project. Below is the list of software development risk by Barry Boehm- modified version.

2. Brainstorming

This technique provides and gives free and open approach that usually encourages each and everyone on project team to participate. It also results in greater sense of ownership of project risk, and team generally committed to managing risk for given time period of project. It is creative and unique technique to gather risks spontaneously by team members. The team members identify and determine risks in ‘no wrong answer’ environment. This technique also provides opportunity for team members to always develop on each other’s ideas. This technique is also used to determine best possible solution to problems and issue that arises and emerge.

3. Casual Mapping

Causal mapping is method that builds or develops on reflection and review of failure factors in cause and effect of the diagrams. It is very useful for facilitating learning with an organization or system simply as method of project-post evaluation. It is also key tool for risk assessment.

4. SWOT Analysis

Strengths-Weaknesses-Opportunities-Threat (SWOT) is very technique and helpful for identifying risks within greater organization context. It is generally used as planning tool for analyzing business, its resources, and also its environment simply by looking at internal strengths and weaknesses and opportunities and threats in external environment. It is technique often used in formulation of strategy. The appropriate time and effort should be spent on thinking seriously about weaknesses and threats of organization for SWOT analysis to more effective and successful in risk identification.

5. Flowchart Method

This method allows for dynamic process to be diagrammatically represented in paper. This method is generally used to represent activities of process graphically and sequentially to simply identify the risk.

RMMM palnning

Risk Mitigation, Monitoring, and Management Plan (RMMM).

In some software teams, risk is documented with the help of a Risk Information Sheet (RIS). This RIS is controlled by using a database system for easier management of information i.e creation, priority ordering, searching, and other analysis. After documentation of RMMM and start of a project, risk mitigation and monitoring steps will start. 

Risk Mitigation

It is an activity used to avoid problems (Risk Avoidance). 
Steps for mitigating the risks as follows. 

1. Finding out the risk. 
2. Removing causes that are the reason for risk creation. 
3. Controlling the corresponding documents from time to time. 
4. Conducting timely reviews to speed up the work.

Risk Monitoring : 

It is an activity used for project tracking. 
It has the following primary objectives as follows.

1. To check if predicted risks occur or not. 
2. To ensure proper application of risk aversion steps defined for risk. 
3. To collect data for future risk analysis. 
4. To allocate what problems are caused by which risks throughout the project.

Risk Management and planning :

It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project manager when risk becomes reality and causes severe problems. If the project manager effectively uses project mitigation to remove risks successfully then it is easier to manage the risks. This shows that the response that will be taken for each risk by a manager. The main objective of the risk management plan is the risk register. This risk register describes and focuses on the predicted threats to a software project.

Drawbacks of RMMM:

• It incurs additional project costs.
• It takes additional time.
• For larger projects, implementing an RMMM may itself turn out to be another tedious project.
• RMMM does not guarantee a risk-free project, infact, risks may also come up after the project is delivered.

Que 10. Explain in details what is more important in “The product on process” Justify your answer with suitable example.

1) The process is nothing but the methodology to build a product while the product is nothing but the ultimate outcome (resultant) of any process applied under any framework.

2) If the process is weak, the end product will undoubtedly suffer, but an obsessive overreliance on process is also dangerous.

3) In every decade, the software community redefines “the problem” by shifting its focus from product issues to process issues. Thus, we have embraced structured programming languages (product) followed by structured analysis methods (process) followed by data encapsulation (product) followed by. the current emphasis on the Software Engineering Institute’s Software Development Capability Maturity Model (process).

4) All of human activity may be a process, but each of us derives a sense of self worth from those activities that result in a representation or instance that can be usedor appreciated either by more than one person, used over and over, or used in some other context not considered. That is, we derive feelings of satisfaction from reuse of our products by ourselves or others.

5) Thus, while the rapid assimilation of reuse goals into software development potentially increases satisfaction software practitioners derive from their work, it also increases the urgency for acceptance of the duality of product and process.

6) Thinking of a reusable artifact as only product or only process either obscures the context and ways to use it or obscures the fact that each use results in product. that will, in turn, be used as input to some, other software development activity.

7) Taking one view over the other dramatically reduces the opportunities for reuse and, hence, loses the opportunity for increasing job satisfaction.

8) People derive as much (or more) satisfaction from the creative process as they do from the end product. An artist enjoys the brush strokes as much the framed result. A writer enjoys the search for the proper metaphor as much as the finished book. A creative software professional should also derive as much satisfaction from the process as the end-product.

9) The duality of product and process is one important element in keeping creative people engaged as the transition from programming to software engineering is finalized.

Que 11. Explain the process decomposition and problem decomposition activities related in SPM.

(A)Problem decomposition sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis. During the scoping activity no attempt is made to fully decompose the problem. Rather, decomposition is applied in two major areas:

(1) the functionality that must be delivered and

(2) the process that will be used to deliver it. As the statement of scope evolves, a first level of partitioning naturally occurs.

The project team learns that the marketing department has talked with potential customers and found that the following functions should be part of automatic copy editing:

(1) spell checking,

(2) sentence grammar checking,

(3) reference checking for large documents (e.g., Is a reference to a bibliography entry found in the list of entries in the bibliography?), and

(4) section and chapter reference validation for large documents.

(B) Process Decomposition: A software team should have a significant degree of flexibility in choosing the software engineering paradigm that is best for the project and the software engineering tasks that populate the process model once it is chosen. A relatively small project that is similar to past efforts might be best accomplished using the linear sequential approach.