Software Engineering unit-2

 

UNIT-II

SOFTWARE PROJECT MANAGEMENT

Software Project Management (SPM) is a proper way of planning and leading software projects. It is a part of project management in which software projects are planned, implemented, monitored, and controlled. This article focuses on discussing Software Project Management (SPM).

Need for Software Project Management

Software is a non-physical product. Software development is a new stream in business and there is very little experience in building software products. Most of the software products are made to fit clients’ requirements. The most important is that basic technology changes and advances so frequently and rapidly that the experience of one product may not be applied to the other one.

Such types of business and environmental constraints increase risk in software development hence it is essential to manage software projects efficiently. It is necessary for an organization to deliver quality products, keep the cost within the client’s budget constraint, and deliver the project as per schedule. Hence, in order, software project management is necessary to incorporate user requirements along with budget and time constraints.

What is Software Project Management Complexities?

Software Project Management Complexities refer to the various difficulties to manage a software project. It recognizes in many different ways. The main goal of software project management is to enable a group of developers to work effectively toward the successful completion of a project in a given time. But software project management is a very difficult task.

Earlier many projects have failed due to faulty project management practices. Management of software projects is much more complex than management of many other types of projects. In this article, we will discuss the types of Complexity as well as the factors that make Project Management Complex.

Types of Complexity

The following are the types of complexity in software project management:

Time Management Complexity: Complexities to estimate the duration of the project. It also includes the complexities to make the schedule for different activities and timely completion of the project.

Cost Management Complexity: Estimating the total cost of the project is a very difficult task and another thing is to keep an eye that the project does not overrun the budget.

Quality Management Complexity: The quality of the project must satisfy the customer’s requirements. It must assure that the requirements of the customer are fulfilled.

Risk Management Complexity: Risks are the unanticipated things that may occur during any phase of the project. Various difficulties may occur to identify these risks and make amendment plans to reduce the effects of these risks.

Human Resources Management Complexity: It includes all the difficulties regarding organizing, managing, and leading the project team.

Communication Management Complexity: All the members must interact with all the other members and there must be good communication with the customer.

Infrastructure complexity: Computing infrastructure refers to all of the operations performed on the devices that execute our code. Networking, load balancers, queues, firewalls, security, monitoring, databases, shading, etc. We are solely interested in dealing with data, processing business policy rules, and clients since we are software engineers that are committed to providing value in a continuous stream. The aforementioned infrastructure ideas are nothing more than irksome minutiae that don’t offer any benefit to the clients. Since it is a necessary evil, we view infrastructure as accidental complexity. Our policies for scaling, monitoring, and other issues are of little interest to our paying clients.

Deployment complexity: A release candidate, or finalized code, has to be synchronized from one system to another. Conceptually, such an operation ought to be simple. To perform this synchronization swiftly and securely in practice proves to be difficult.

Who is a Project Manager?

A project manager has to face many difficult situations to accomplish these works. The job responsibilities of a project manager range from invisible activities like building up team morale to highly visible customer presentations. Most of the managers take responsibility for writing the project proposal, project cost estimation, scheduling, project staffing, software process tailoring, project monitoring and control, software configuration management, risk management, managerial report writing, and presentation, and interfacing with clients.

 

 

The tasks of a project manager are classified into two major types:

1.     Project planning

2.     Project monitoring and control

 

SoftwareProjectManager: 
Software Project Manager is generally never directly involved in producing the end product but he controls and manages the activities involved in the production. He is aware of all the phases of Software Development Life Cycle that the software would go through. 

Responsibilities of software project manager: 

Proper project management is essential for the successful completion of a software project and the person who is responsible for it is called project manager. To do his job effectively, the project manager must have certain set of skills. This section discusses both the job responsibilities of project manager and the skills required by him.

1.     Managing people:

·        Acts as a project leader

·        Communication with stakeholders

·        Manages human resources

2.     Managing project:

·        Monitors progress and performance

·        Risk analysis at every phase

·        Manages time and budget constraint

·        Job Responsibilities:

·        Involves with the senior managers in the process of appointing team members.

·        Builds the project team and assigns tasks to various team members.

·        Responsible for effective project planning and scheduling, project monitoring and control activities in order to achieve the project objectives.

·        Acts as a communicator between the senior management and the development team and internal and external stakeholders.

·        Effectively resolves issues that arise between the team members by changing their roles and responsibilities.

·        Modifies the project plan (if required) to deal with the situation.

CategorizingSoftwareProjects: 
Compulsory Vs Voluntary systems (projects): 

·        Compulsory systems are the systems which the staff of an organisation have to use if they want to do a task.

·        Voluntary systems are the systems which are voluntarily used by the users eg. computer gaming, school project, etc.

2.     Information Vs Embedded systems (projects): 

·        Information systems are used by staff to carry out office processes and tasks eg. stock control system.

·        Embedded systems are used to control machines eg. a system controlling equipment in a building.

3.     Objective-based Vs Product-based systems (projects): 

·        Project whose requirement is to meet certain objectives which could be met in a number of ways, is objective-based project.

·        Project whose requirement is to create a product, the details of which have been specified by the client, is product-based project.

 

 Features of a Good Project Manager

1.     Knowledge of project estimation techniques.

2.     Good decision-making abilities at the right time.

3.     Previous experience managing a similar type of projects.

4.     Good communication skills to meet the customer satisfaction.

5.     A project manager must encourage all the team members to successfully develop the product.

6.     He must know the various type of risks that may occur and the solution to these problems.

 

 

SPM is a sub-field of Project Management in which software projects are planned, implemented, monitored and controlled. 

It consists of three terms: Software, Project and Management. So, let us understand each term separately. Software includes a set of programs, documentation and user manual for a particular software project. So, it is basically the complete procedure of the software development starting from the requirement gathering phase and extending to testing and maintenance. Project means a planned activity which consists of several well defined tasks. Management makes sure that the product comes out as planned. 

 

There are many constraints of the software projects but the main and fundamental constraints includes: Time, Cost and Quality. Any one of the two factors can severely affect the third one. Therefore, Software Project Management is essential to develop software projects within time and the specified budget and that too of good quality. 

What is Project Size Estimation?

Project size estimation is determining the scope and resources required for the project.

1.     It involves assessing the various aspects of the project to estimate the effort, time, cost, and resources needed to complete the project.

2.     Accurate project size estimation is important for effective and efficient project planning, management, and execution.

 

Importance of Project Size Estimation

Here are some of the reasons why project size estimation is critical in project management:

1.     Financial Planning: Project size estimation helps in planning the financial aspects of the project, thus helping to avoid financial shortfalls.

2.     Resource Planning: It ensures the necessary resources are identified and allocated accordingly.

3.     Timeline Creation: It facilitates the development of realistic timelines and milestones for the project.

4.     Identifying Risks: It helps to identify potential risks associated with overall project execution.

5.     Detailed Planning: It helps to create a detailed plan for the project execution, ensuring all the aspects of the project are considered.

6.     Planning Quality Assurance: It helps in planning quality assurance activities and ensuring that the project outcomes meet the required standards.

 

Who Estimates Projects Size?

Here are the key roles involved in estimating the project size:

1.     Project Manager: Project manager is responsible for overseeing the estimation process.

2.     Subject Matter Experts (SMEs): SMEs provide detailed knowledge related to the specific areas of the project.

3.     Business Analysts: Business Analysts help in understanding and documenting the project requirements.

4.     Technical Leads: They estimate the technical aspects of the project such as system design, development, integration, and testing.

5.     Developers: They will provide detailed estimates for the tasks they will handle.

6.     Financial Analysts: They provide estimates related to the financial aspects of the project including labor costs, material costs, and other expenses.

7.     Risk Managers: They assess the potential risks that could impact the projects’ size and effort.

8.     Clients: They provide input on project requirements, constraints, and expectations.

 

Metrics for software project size estimation

Accurate estimation of the problem size is fundamental to satisfactory estimation of effort, time duration and cost of a software project. In order to be able to accurately estimate the project size, some important metrics should be defined in terms of which the project size can be expressed. The size of a problem is obviously not the number of bytes that the source code occupies. It is neither the byte size of the executable code. The project size is a measure of the problem complexity in terms of the effort and time required to develop the product. Currently two metrics are popularly being used widely to estimate size:

1-    lines of code (LOC)

2-    2- function point (FP)

The usage of each of these metrics in project size estimation has its own advantages and disadvantages.

Different Methods of Project Estimation

1.     Expert Judgment: In this technique, a group of experts in the relevant field estimates the project size based on their experience and expertise. This technique is often used when there is limited information available about the project.

2.     Analogous Estimation: This technique involves estimating the project size based on the similarities between the current project and previously completed projects. This technique is useful when historical data is available for similar projects.

3.     Bottom-up Estimation: In this technique, the project is divided into smaller modules or tasks, and each task is estimated separately. The estimates are then aggregated to arrive at the overall project estimate.

4.     Three-point Estimation: This technique involves estimating the project size using three values: optimistic, pessimistic, and most likely. These values are then used to calculate the expected project size using a formula such as the PERT formula.

5.     Function Points: This technique involves estimating the project size based on the functionality provided by the software. Function points consider factors such as inputs, outputs, inquiries, and files to arrive at the project size estimate.

6.     Use Case Points: This technique involves estimating the project size based on the number of use cases that the software must support. Use case points consider factors such as the complexity of each use case, the number of actors involved, and the number of use cases.

7.     Parametric Estimation: For precise size estimation, mathematical models founded on project parameters and historical data are used.

8.     COCOMO (Constructive Cost Model): It is an algorithmic model that estimates effort, time, and cost in software development projects by taking into account several different elements.

9.     Wideband Delphi: Consensus-based estimating method for balanced size estimations that combines expert estimates from anonymous experts with cooperative conversations.

10. Monte Carlo Simulation: This technique, which works especially well for complicated and unpredictable projects, estimates project size and analyses hazards using statistical methods and random sampling.

Estimating the Size of the Software

Estimation of the size of the software is an essential part of Software Project Management. It helps the project manager to further predict the effort and time that will be needed to build the project. Here are some of the measures that are used in project size estimation:

1. Lines of Code (LOC)

As the name suggests, LOC counts the total number of lines of source code in a project. The units of LOC are: 

1.     KLOC: Thousand lines of code

2.     NLOC: Non-comment lines of code

3.     KDSI: Thousands of delivered source instruction

·        The size is estimated by comparing it with the existing systems of the same kind. The experts use it to predict the required size of various components of software and then add them to get the total size.

·        It’s tough to estimate LOC by analyzing the problem definition. Only after the whole code has been developed can accurate LOC be estimated. This statistic is of little utility to project managers because project planning must be completed before development activity can begin.

·        Two separate source files having a similar number of lines may not require the same effort. A file with complicated logic would take longer to create than one with simple logic. Proper estimation may not be attainable based on LOC.

·        The length of time it takes to solve an issue is measured in LOC. This statistic will differ greatly from one programmer to the next. A seasoned programmer can write the same logic in fewer lines than a newbie coder.

Advantages:

1.     Universally accepted and is used in many models like COCOMO.

2.     Estimation is closer to the developer’s perspective.

3.     Both people throughout the world utilize and accept it.

4.     At project completion, LOC is easily quantified.

5.     It has a specific connection to the result.

6.     Simple to use.

Disadvantages:

1.     Different programming languages contain a different number of lines.

2.     No proper industry standard exists for this technique.

3.     It is difficult to estimate the size using this technique in the early stages of the project.

4.     When platforms and languages are different, LOC cannot be used to normalize.

2. Number of Entities in ER Diagram

ER model provides a static view of the project. It describes the entities and their relationships. The number of entities in the ER model can be used to measure the estimation of the size of the project. The number of entities depends on the size of the project. This is because more entities needed more classes/structures thus leading to more coding. 

Advantages: 

1.     Size estimation can be done during the initial stages of planning.

2.     The number of entities is independent of the programming technologies used.

Disadvantages:  

1.     No fixed standards exist. Some entities contribute more to project size than others.

2.     Just like FPA, it is less used in the cost estimation model. Hence, it must be converted to LOC.

3. Total Number of Processes in DFD

Data Flow Diagram(DFD) represents the functional view of software. The model depicts the main processes/functions involved in software and the flow of data between them. Utilization of the number of functions in DFD to predict software size. Already existing processes of similar type are studied and used to estimate the size of the process. The sum of the estimated size of each process gives the final estimated size. 

Advantages:  

1.     It is independent of the programming language.

2.     Each major process can be decomposed into smaller processes. This will increase the accuracy of the estimation.

Disadvantages:  

1.     Studying similar kinds of processes to estimate size takes additional time and effort.

2.     All software projects are not required for the construction of DFD.

4. Function Point Analysis

In this method, the number and type of functions supported by the software are utilized to find FPC(function point count). The steps in function point analysis are:  

1.     Count the number of functions of each proposed type.

2.     Compute the Unadjusted Function Points(UFP).

3.     Find the Total Degree of Influence(TDI).

4.     Compute Value Adjustment Factor(VAF).

5.     Find the Function Point Count(FPC).

 

Project Estimation Techniques

The main activities which comes under software project planning:

• # Estimation,

• # Scheduling,

• # Risk Analysis,

• # Quality Management Planning,

• # Change management planning.

Estimation: It Is an attempt to determine how much money, efforts, resources and time it will take to build a specific software based system or project.

Who does estimation? :

• Software manager does estimation using information collected from customers and software Engineers and

• software metrics data collected from past projects.

• Assumption taken from experience .

• Identified risks and feasibility helps in estimation.

Steps for Estimations:

• -> Estimate the size of the development product

• -> Estimate the effect in person- month or person - hours

• -> Estimate the schedule in calendar months.

• ->Estimate the project cost in agreed currency.

Before a final estimate is made, problem complexity and risk are considered.

"Estimate Risk" is measured by the degree of uncertainty in the quantitative estimate established by the resources, and schedule.

 

Empirical estimation technique:

Empirical estimation technique are based on the data taken from the previous project and some based on guesses and assumptions.

There are many empirical estimation technique but most popular are

Expert Judgement Technique

Delphi Cost Technique

Expert judgement technique:

An expert makes an educated guess of the problem size after analyzing the problem thoroughly. Expert estimate the cost of different components that is modules and sub modules of the system.

Disadvantages:

Human error, considering not all factors and aspects of the project, individual bias, more chances of failure.

Estimation by group of experts minimises factors such as individual oversight, lack of familiarity with a particular aspect of a project, personal bias and desired to win a contract through overly optimistic estimates.

 

 

 

Delphi cost estimation:

Role of Members: Coordinator provide a copy of Software Requirement Specification(SRS) document and a form of recording it cost estimate to each estimator.

Estimator: It complete their individual estimate anomalously and submit to the coordinator with mentioning, if any, unusual characteristics of product which has influenced his estimation.

The coordinator and distribute the summary of the response to all estimator and they re-estimate them.

 

This process is Iterated for several rounds.

No discussion is allowed among the estimator during the entire estimation process because there may be many estimators get easily influenced by rationale of an estimator who may be more experienced or senior.

After the completion of several iterations of estimation, the coordinator takes the responsibility of compiling the result and preparing the final estimates.

COCOMO Model

What is the COCOMO Model?

The COCOMO Model is a procedural cost estimate model for software projects and is often used as a process of reliably predicting the various parameters associated with making a project such as size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which makes it one of the best-documented models. 

The key parameters that define the quality of any software product, which are also an outcome of COCOMO, are primarily effort and schedule:

1.     Effort: Amount of labor that will be required to complete a task. It is measured in person-months units.

2.     Schedule: This simply means the amount of time required for the completion of the job, which is, of course, proportional to the effort put in. It is measured in the units of time such as weeks, and months.

 

COCOMO(constructive COst MOdel) what purpose by "Boehm[1981]". According to him, software cost estimation should be done through three stages.

Basic COCOMO,

Intermediate COCOMO,

complete COCOMO

Modes of development:

Boehm proposed that there can be three modes of software development project based on development complexity. He considered software size innovation deadline / constraint deadline and development environment and gave three modes which were

Types of Projects in the COCOMO Model

In the COCOMO model, software projects are categorized into three types based on their complexity, size, and the development environment. These types are:

1.     Organic: A software project is said to be an organic type if the team size required is adequately small, the problem is well understood and has been solved in the past and also the team members have a nominal experience regarding the problem.

2.     Semi-detached: A software project is said to be a Semi-detached type if the vital characteristics such as team size, experience, and knowledge of the various programming environments lie in between organic and embedded. The projects classified as Semi-Detached are comparatively less familiar and difficult to develop compared to the organic ones and require more experience better guidance and creativity. Eg: Compilers or different Embedded Systems can be considered Semi-Detached types.

3.     Embedded: A software project requiring the highest level of complexity, creativity, and experience requirement falls under this category. Such software requires a larger team size than the other two models and also the developers need to be sufficiently experienced and creative to develop such complex models.

 

COCOMO model depends on two main equations:

1. Development Efforts:

MM=a1*(KLOC)a2*PM

Based onMM- man month (MM)/ person month(PM)/ staff month is one month of efforts by one person. COCOMO consider 152 hours per person month. It may vary according to organization by 10% to 20%.

2. Effort and Development Time(TDEV)

TDEV=Bb1*(effort)b2*Months

Tdev is estimated time to develop the software, expressed in months.

a1,a2,b1,b2 are constant for each category of software products.

The Six phases of detailed COCOMO are:

 

1.     Planning and requirements: This initial phase involves defining the scope, objectives, and constraints of the project. It includes developing a project plan that outlines the schedule, resources, and milestones

2.     System design: : In this phase, the high-level architecture of the software system is created. This includes defining the system’s overall structure, including major components, their interactions, and the data flow between them.

3.     Detailed design: This phase involves creating detailed specifications for each component of the system. It breaks down the system design into detailed descriptions of each module, including data structures, algorithms, and interfaces.

4.     Module code and test: This involves writing the actual source code for each module or component as defined in the detailed design. It includes coding the functionalities, implementing algorithms, and developing interfaces.

5.     Integration and test: This phase involves combining individual modules into a complete system and ensuring that they work together as intended.

6.     Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used method for estimating the cost and effort required for software development projects.

Types of COCOMO Model

There are three types of COCOMO Model:

·        Basic COCOMO Model

·        Intermediate COCOMO Model

·        Detailed COCOMO Model

1. Basic COCOMO Model

The Basic COCOMO model is a straightforward way to estimate the effort needed for a software development project. It uses a simple mathematical formula to predict how many person-months of work are required based on the size of the project, measured in thousands of lines of code (KLOC).

It estimates effort and time required for development using the following expression:

E = a*(KLOC)b PM

Tdev = c*(E)d

Person required = Effort/ Time

Where,

E is effort applied in Person-Months

KLOC is the estimated size of the software product indicate in Kilo Lines of Code

Tdev is the development time in months

a, b, c are constants determined by the category of software project given in below table.

The above formula is used for the cost estimation of the basic COCOMO model and also is used in the subsequent models.

 

 

Software Projects	a	b	c	d
Organic	2.4	1.05	2.5	0.38
Semi-Detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

Example of Basic COCOMO Model

Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate effort and time for each of the three modes of development. All the constants value provided in the following table:

Solution

From the above table we take the value of constant a,b,c and d.

1.     For organic mode, 

·        effort = 2.4 × (400)1.05  ≈ 1295 person-month.

·        dev. time = 2.5 × (1295)0.38 ≈ 38 months.

2.     For semi-detach mode, 

·        effort = 3 × (400)1.12  ≈ 2462 person-month.

·        dev. time = 2.5 × (2462)0.35 ≈  38 months.

3.     For Embedded mode, 

·        effort = 3.6 × (400)1.20  ≈ 4772 person-month.

·        dev. time = 2.5 × (4772)0.32 ≈ 38 months.

Advantages of the COCOMO Model

1.     Systematic cost estimation: Provides a systematic way to estimate the cost and effort of a software project.

2.     Helps to estimate cost and effort: This can be used to estimate the cost and effort of a software project at different stages of the development process.

3.     Helps in high-impact factors: Helps in identifying the factors that have the greatest impact on the cost and effort of a software project.

4.     Helps to evaluate the feasibility of a project: This can be used to evaluate the feasibility of a software project by estimating the cost and effort required to complete it.

Disadvantages of the COCOMO Model

1.     Assumes project size as the main factor: Assumes that the size of the software is the main factor that determines the cost and effort of a software project, which may not always be the case.

2.     Does not count development team-specific characteristics: Does not take into account the specific characteristics of the development team, which can have a significant impact on the cost and effort of a software project.

3.     Not enough precise cost and effort estimate: This does not provide a precise estimate of the cost and effort of a software project, as it is based on assumptions and averages.

2. Intermediate COCOMO Model

The basic COCOMO model assumes that the effort is only a function of the number of lines of code and some constants evaluated according to the different software systems. However, in reality, no system’s effort and schedule can be solely calculated based on Lines of Code. For that, various other factors such as reliability, experience, and Capability. These factors are known as Cost Drivers (multipliers) and the Intermediate Model utilizes 15 such drivers for cost estimation.

Intermediate COCOMO Model equation:

E = a*(KLOC)b * EAF PM

Tdev = c*(E)d

Where,

·        E is effort applied in Person-Months

·        KLOC is the estimated size of the software product indicate in Kilo Lines of Code

·        EAF is the Effort Adjustment Factor (EAF) is a multiplier used to refine the effort estimate obtained from the basic COCOMO model.

·        Tdev is the development time in months

·        a, b, c are constants determined by the category of software project given in below table.

The constant values a, b, c, and d for the Basic Model for the different categories of the software projects are:

Software Projects	a	b	c	d
Organic	3.2	1.05	2.5	0.38
Semi-Detached	3.0	1.12	2.5	0.35
Embedded	2.8	1.20	2.5	0.32

 Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving deeper into project-specific factors. It considers a wider range of parameters, like team experience, development practices, and software complexity. By analyzing these factors in more detail, Detailed COCOMO provides a highly accurate estimation of effort, time, and cost for software projects. It’s like zooming in on a project’s unique characteristics to get a clearer picture of what it will take to complete it successfully.

 

Halstead’s Software Science

Halstead’s Software Science Halstead’s complexity measurement was developed to measure a program module’s complexity directly from source code, with emphasis on computational complexity. The Halstead’s measures are based on four scalar number derived directly from a program’s source code:

n1 is number of distinct operators.

n2 is number of distinct operands.

 N1 is total number of distinct operators.

N2 is total number of distinct operands.

 From these numbers, five measures are derived:

Halstead’s uses certain measures such as program length, program vocabulary, volume, difficulty, and effort for the given algorithm. By this Halstead’s is trying to show that the program length can be calculated, volume of algorithm can be estimated. The above given table shows how actually these measure can be obtained. The Halstead’s measures are applicable to operational system and to development efforts once the code has been written. Thus using Halstead’s measurement experimental verification can be performed in software science.

Halstead’s Software metrics are a set of measures proposed by Maurice Halstead to evaluate the complexity of a software program. These metrics are based on the number of distinct operators and operands in the program and are used to estimate the effort required to develop and maintain the program. These metrics provide a quantitative assessment of software complexity, aiding in software development, maintenance, and quality assurance processes. They include measures such as program length, vocabulary, volume, difficulty, and effort, calculated based on the number of unique operators and operands in a program. Halstead’s metrics help developers understand and manage software complexity, identify potential areas for optimization, and improve overall software quality.

 

Program length: The length of a program is total usage of operators and operands in the program. Length (N) = N1 + N2.

Program vocabulary: The Program vocabulary is the number of unique operators and operands used in the program. Vocabulary (n) = n1 + n2.

Program Volume: The Program Volume can be defined as minimum number of bits needed to encode the program. Volume (V) = N log2 n.

Length estimation: N = n1 log2 n1 + n2 log2 n2

Program level (L):

This is the ratio of the number of operator occurrences to the number of operand occurrences in the program,

i.e., L = n1/n2

where n1 is the number of operator occurrences and n2 is the number of operand occurrences.

Program difficulty (D):

This is the ratio of the number of unique operators to the total number of operators in the program,

i.e., D = (n1/2) * (N2/n2)

Program effort (E):

This is the product of program volume (V) and program difficulty

(D), i.e., E = V*D

Example of Halstead’s Software Metrics

Before we look at the example, let’s review the counting rules for a C program.

Counting Rules for C Language

1.     Comments are not considered.

2.     The identifier and function declarations are not considered

3.     All the variables and constants are considered operands.

4.     Global variables used in different modules of the same program are counted as multiple occurrences of the same variable.

5.     Local variables with the same name in different functions are counted as unique operands.

6.     Functions calls are considered operators.

7.     All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.

8.     In control construct switch ( ) {case:…}, switch as well as all the case statements are considered as operators.

9.     The reserve words like return, default, continue, break, size, etc., are considered operators.

10. All the brackets, commas, and terminators are considered operators.

11. GOTO is counted as an operator and the label is counted as an operand.

12. The unary and binary occurrences of “+” and “-” are dealt with separately. Similarly “*” (multiplication operator) is dealt with separately.

13. In the array variables such as “array-name [index]” “array-name” and “index” are considered as operands and [ ] is considered as operator.

14. In the structure variables such as “struct-name, member-name” or “struct-name -> member-name”, struct-name, and member-name are taken as operands, and ‘.’, ‘->’ are taken as operators. Some names of member elements in different structure variables are counted as unique operands.

15. All the hash directives are ignored.

 

What is Risk Management?

A risk is a probable problem; it might happen, or it might not. There are main two characteristics of risk.

·        Uncertainty: the risk may or may not happen which means there are no 100% risks.

·        Loss: If the risk occurs in reality, undesirable results or losses will occur.

 

Risk Management is a systematic process of recognizing, evaluating, and handling threats or risks that have an effect on the finances, capital, and overall operations of an organization. These risks can come from different areas, such as financial instability, legal issues, errors in strategic planning, accidents, and natural disasters.

The main goal of risk management is to predict possible risks and find solutions to deal with them successfully.

The risk management process

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

·        Risks Identification.

·        Risk Assessment.

·        Risks Planning.

·        Risk Monitoring

 

Risk Identification

Risk identification refers to the systematic process of recognizing and evaluating potential threats or hazards that could negatively impact an organization, its operations, or its workforce. This involves identifying various types of risks, ranging from IT security threats like viruses and phishing attacks to unforeseen events such as equipment failures and extreme weather conditions.

Risk analysis

Risk analysis is the process of evaluating and understanding the potential impact and likelihood of identified risks on an organization. It helps determine how serious a risk is and how to best manage or mitigate it. Risk Analysis involves evaluating each risk’s probability and potential consequences to prioritize and manage them effectively.

Risk Planning

Risk planning involves developing strategies and actions to manage and mitigate identified risks effectively. It outlines how to respond to potential risks, including prevention, mitigation, and contingency measures, to protect the organization’s objectives and assets.

Risk Monitoring

Risk monitoring involves continuously tracking and overseeing identified risks to assess their status, changes, and effectiveness of mitigation strategies. It ensures that risks are regularly reviewed and managed to maintain alignment with organizational objectives and adapt to new developments or challenges.

 

 

Understanding Risks in Software Projects

A computer code project may be laid low with an outsized sort of risk. To be ready to consistently establish the necessary risks that could affect a computer code project, it’s necessary to group risks into completely different categories. The project manager will then examine the risks from every category square measure relevant to the project. 

There are mainly 3 classes of risks that may affect a computer code project: 

1.     Project Risks: 

Project risks concern various sorts of monetary funds, schedules, personnel, resources, and customer-related issues. A vital project risk is schedule slippage. Since computer code is intangible, it’s tough to observe and manage a computer code project. It’s tough to manage one thing that cannot be seen. For any producing project, like producing cars, the project manager will see the merchandise taking form. 

For example, see that the engine is fitted, at the moment the area of the door unit is fitted, the automotive is being painted, etc. so he will simply assess the progress of the work and manage it. The physical property of the merchandise being developed is a vital reason why several computer codes come to suffer from the danger of schedule slippage. 

2.     Technical Risks: 

Technical risks concern potential style, implementation, interfacing, testing, and maintenance issues. Technical risks conjointly embody ambiguous specifications, incomplete specifications, dynamic specifications, technical uncertainty, and technical degeneration. Most technical risks occur thanks to the event team’s lean information concerning the project. 
 

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

 

Why is risk management important?

Risk management is important because it helps organizations to prepare for unexpected circumstances that can vary from small issues to major crises. By actively understanding, evaluating, and planning for potential risks, organizations can protect their financial health, continued operation, and overall survival.