Unit 4

Project Planning, Management and Estimation

Q.1) Write the steps for creating work breakdown structure.

Ans: Creating work breakdown structure

A common project management tool is a job breakdown structure. It is a diagram that helps to break down big projects into smaller and more manageable components that include the deliverables or results of the project that will be completed.

It is a project-oriented breakdown of deliverables that separates project deliverables into sub-deliverables and work packages that describe the work, length and expense of the tasks to be performed.

It has a structure that is hierarchical. Typically, having three stages of decomposition in a WBS is easier. You can add a fourth and a fifth level in the case of a more complicated project.

We have then mentioned the steps you need to take to build a scratch-based job breakdown structure.

Step 1: To define the project's deliverables and sub-deliverables, get the team together. This will include the project managers and the professionals in the subject matter.

Step 2: Collect the necessary documents, such as the project charter, the declaration of project scope and the strategy for project scope management.

Step 3: Identify the project's main deliverables. These should come at your WBS's second level. To complete the project, key deliverables will be necessary and will be carried out by separate teams, meaning the same team will not work on completing another deliverable.

Step 4: Split the main deliverables into smaller sections of the work (work packages) or, in other words, define the work that is required to complete each deliverable with the aid of the subject matter experts.

Step 5: Build a WBS dictionary that includes the description and scope of the various elements in your job breakdown structure as a text. The WBS dictionary contains details such as the name and ID of the job package, the name of the person to whom it is assigned, the due date, the approximate cost, etc. This will allow the team to better appreciate task packages.

Step 6: Using various formats, such as text-based work breakdown structures, tabular structures, or more visual ones like flowcharts, you can create a WBS. Share it with the team until it is over. With a safe share connection, a creatively functioning breakdown framework can be easily shared with the rest of your team. Once shared, you can collaborate on it in real time.

Q.2) What do you mean by the W5HH principle?

Ans: The W5HH principle

Barry Boehm gave a philosophy which prepares software projects with simple and manageable designs or outlines. He also presented a methodology to address the priorities, management, obligations and technological approach of the project and its required resources. Then he called it as the W5HH concept when few issues resulted in the success of the project properties, description and resulting plan.

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

Those questions are as follows:

❖      Why the system is going to be developed?

Both stakeholders must determine the validity of the product/project framework for the purposes of software work. Here Barry asks whether the object of the project would justify the cost of time spent on it by individuals?

❖      What is activities are needed to be done in this?

In this, Barry asks what role is currently expected to be performed for the project.

❖      When is this done?

After recognizing when project activities will be started and when they enter the final step to achieve the target, project scheduling is performed by team.

❖      Who is reason for these activities in this project?

For this, every member who is part of the software team is responsible. And it determines their positions.

❖      Where are these authoritatively located?

Tech professionals not only have positions in this, but consumers, clients and partners also have organizational roles and obligations as well.

❖      How is job technically and managerially finished?

After understanding the scope of the project that is being developed, all technical techniques and project management rules are established.

❖      How much part of each resource is required?

After estimating each resource as per customer/user requirements, software developers know this.

Q.3) Write short note on project initiation?

Ans: Project initiation

The implementation of the project is the first step of the life cycle of project management and businesses determine at this point if the project is needed and how useful it will be for them. The business case and feasibility analysis are the two metrics that are used to assess a planned project and determine its expectations.

Project initiation process:

Now that we have decided what the initiation of the project is and why it is so important, it is time to see what the key steps in the checklist for the initiation of the project are and how successful managers initiate their projects.

1. Creating a business case

The business case is an essential document which describes how the objectives of the project fit with the long-term goals of the organization. This report examines why the organization should invest its technological, financial and human capital on a particular project.

2.     Conducting a feasibility study

The next step after the acceptance of the business case is to assess the probability of the success of the project after considering all the variables. This research describes the project's high-level limitations and assumptions and determines whether or not the project is worth it.

3.     Establishing a project charter

Perhaps the most detailed and critical aspect of the process of project initiation is the project charter. To define the scope/goal, team members, and the potential timeline of the project, it responds to the 3 Ws.

In several cases, the charter is the first project document that outlines the necessary specifics, such as the project's objectives and constraints.

Communication and discussions are an important aspect of successful project management and a significant part of the time spent by a project manager is typically spent communicating with stakeholders. PMBOK describes stakeholders as anybody who can be impacted or have an impact on the project. Project stakeholders can be internal or external and each category has its own communication requirements.

Without a project team, no project can be initiated. Forming a working project team and assigning tasks and duties to them is an integral part of the initiation process of the project. It also increases the overall responsibility of the whole team by assigning tasks and responsibilities early on and can assist you as a manager in the later stages of the project life cycle.

It is a good idea to revisit the entire project initiation process after doing all to ensure that you missed nothing. You will have to check the work in later stages, as monitoring and control is one of the five phases of the life cycle of project management.

Q.4) Describe size & function- oriented metrics (FP & LOC), in detail.

Ans: Size & function- oriented metrics (FP & LOC)

Estimation of the size of software is an essential part of software project management. It helps the project manager to further predict the effort, cost and time which will be needed to build the product. The project size is a measure of the problem complexity in terms of the effort and time required to build the product.

There are two software matrices which are being used to estimate size:

●      Size Oriented metrics

It focuses on the size of the software that has been produced. If a software organization maintains simple records, a table of size-oriented measures, such as shown below can be created. The table lists each software development project that has been completed over the past few years and corresponding measures for that project.

It shows that for the project: alpha, 12,100 LOC were developed with 24 person months of effort, at a cost of $168,000. Note that the effort and cost recorded in the table represent all software engineering activities (i.e. analysis, design, code and test) and not just coding. Furthermore, it shows that 365 pages of documentation were developed, 134 errors were recorded before software was released and 29 defects were encountered after release to the customer within the first year of operation and three people worked on this project alpha.

In order to develop metrics that can be assimilated with similar metrics from other projects, we choose lines of code as our normalization value. From the rudimentary data contained in the table, a set of simple size-oriented metrics can be developed for each project:

●      Errors per KLOC (thousand lines of code).

●      Defects per KLOC.

●      $ per LOC.

●      Page of documentation per KLOC.

In addition, other interesting metrics can be computed:

●      Errors per person-month.

   LOC per person-month.

●      $ per page of documentation.

Size-oriented metrics are not universally accepted as the best way to measure the process of software development. Most of the controversy swirls around the use of lines of code as a key measure. Proponents of the LOC measure claim that LOC is an "artifact" of all software development projects that can be easily counted, that many existing software estimation models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists. On the other hand, opponents argue that LOC measures are programming language dependent, that they penalize well-designed but shorter programs, that they cannot easily accommodate nonprocedural languages, and that their use in estimation requires a level of detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long before analysis and design have been completed).

●      Function-Oriented Metrics

Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity.

Function points are computed by completing the table shown in Figure above. Five information domain characteristics are determined and counts are provided in the appropriate table location. Information domain values are defined in the following manner:

Number of user inputs – Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.

Number of user outputs – Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.

Number of user inquiries – An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.

Number of files – Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.

Number of external interfaces – All machine-readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted.

Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective. To compute function points (FP), the following relationship is used:

FP = count total * [0.65 + 0.01 * Σ(Fi)]

Where count total is the sum of all FP entries obtained from Figure above.

Q.5) What are the metrics for the project?

Ans: Metrics for project

These are indicators that relate to the quality of projects. They are used to measure errors, prices, scheduling, efficiency and estimation of different resources and deliverables of the project.

1. Schedule Variance: Any inconsistency is known as Schedule Variation between the expected completion of an operation and the actual completion.

Schedule variance = ((Actual calendar days – Planned calendar days) + Start variance)/ Planned calendar days x 100.

2.     Effort Variance: The gap between the expected effort outlined and the effort needed to actually execute the mission is called the variance of effort.

Effort variance = (Actual Effort – Planned Effort)/ Planned Effort x 100.

3.     Size Variance: Difference between the approximate project size and the project's actual size (normally in KLOC or FP).

Size variance = (Actual size – Estimated size)/ Estimated size x 100.

4.     Requirement Stability Index: Provides visibility of the extent and effect of changes in specifications.

RSI = 1- ((Number of changed + Number of deleted + Number of added) / Total number of initial requirements) x100.

1. Productivity (Project): A calculation of output for an input unit from a related process.

Project Productivity = Actual Project Size / Actual effort expended in the project.

2.     Productivity (for test case preparation) = Actual number of test cases/ Actual effort expended in test case preparation.

3.     Productivity (for test case execution) = Actual number of test cases / actual effort expended in testing.

4.     Productivity (defect detection) = Actual number of defects (review + testing) / actual effort spent on (review + testing).

5.     Productivity (defect fixation) = actual no of defects fixed/ actual effort spent on defect fixation.

6.     Schedule variance for a phase: The deviation between scheduled and actual schedules within a project for the phases.

Schedule variance for a phase = (Actual Calendar days for a phase – Planned calendar days for a phase + Start variance for a phase)/ (Planned calendar days for a phase) x 100

7.     Effort variance for a phase: The deviation between a scheduled and actual effort within the project for different phases.

Effort variance for a phase = (Actual effort for a phase – a planned effort for a phase)/ (planned effort for a phase) x 100.

Q.6) Define software project estimation.

Ans: Software Project Estimation

For an effective management accurate estimation of various measures is a must.

With correct estimation managers can manage and control the project more

Efficiently and effectively.

Project estimation may involve the following:

●      Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating the number of function points in the software. Lines of code depend upon coding practices and Function points vary according to the user or software requirement.

●      Effort estimation

The managers estimate efforts in terms of personnel requirement and man-hour required to produce the software. For effort estimation software size should be known. This can either be derived by managers’ experience, organization’s historical data or software size can be converted into efforts by using some standard formulae.

●      Time estimation

Once size and efforts are estimated, the time required to produce the software can be estimated. Efforts required is segregated into sub categories as per the requirement specifications and interdependency of various components of software. Software tasks are divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The tasks are scheduled on a day-to-day basis or in calendar months. The sum of time required to complete all tasks in hours or days is the total time invested to complete the project.

●      Cost estimation

This might be considered as the most difficult of all because it depends on more elements than any of the previous ones. For estimating project cost, it is required to consider -

• Size of software
• Software quality
• Hardware
• Additional software or tools, licenses etc.
• Skilled personnel with task-specific skills
• Travel involved
• Communication
• Training and support

Q.7) What do you mean by Decomposition technique?

Ans: Decomposition technique

The software is believed by this approach to be a product of different compositions.

Before it is possible to make an approximation and apply decomposition techniques, the planner must

-         Understand the complexity of the programme to be designed.

-         Generate an approximation of the size of the programme.

Two major models exist -

Line of code (LOC): The calculation is conducted on behalf of the number of codes in the software product line.

Functions points (FP): Estimation is performed on behalf of the number of software product feature points.

Either of two strategies is then used

-         Problem based estimation

Based on either code source lines or estimates of feature points.

-         Process based estimation

Based on the effort needed to achieve each assignment.

Problem-Based Estimation

Start with a restricted declaration of scope. Decompose the programme into problem functions that can be independently calculated for each one. For each function, compute a LOC or FP value. By adding the LOC or FP values to the base productivity metrics (e.g. LOC/person-month or FP/person-month) to extract cost or effort estimates. Merge for the whole project.

LOC and FP estimation are different estimation methods, but both have a number of characteristics in common. The project manager starts with a restricted software scope statement and tries to decompose software into problem functions that can be independently calculated from this statement. LOC or FP (the estimation variable) is then estimated for each function.

Process-Based Estimation

The most popular way of estimating a project is to base the estimation on the method that will be used. That is, the method is broken down into a relatively small set of tasks and it calculates the effort needed to accomplish each task.

Process-based estimation starts, like problem-based techniques, with a delineation of software functions obtained from the scope of the project. For each function, a sequence of software process operations must be performed.

Functions and related activities of the software process can be described as part of a table.

When problem functions and process activities are melded, the planner calculates the effort needed to execute each software process operation for each software function (e.g., person-months). These data constitute the table's core matrix.

Q.8) What are the cost estimation tools and techniques?

Ans: Cost estimation tools and technique

For all projects, accurate cost estimates are important. It would be difficult to prepare a business plan, set up comprehensive budgets, forecast resource needs or manage project costs without a cost estimate.

Estimating project costs scares a lot of people. They don't know how much it's going to cost, but they know whatever value they offer, their boss will keep them.

The Project Cost Engineer uses either one or a combination of the following instruments and techniques in the cost estimation process:

To estimate the cost of the project, expert judgement uses the expertise and knowledge of experts. The particular factors related to the project can be taken into account in this technique. It can also be biased, however.

The values such as scope, expense, budget and length or measurements of scale such as size, weight and complexity from a previous, equivalent project are used in an analogous cost estimate as the basis for calculating the same parameter or measurement for a current project.

This methodology relies on the actual cost of previous, related projects when calculating costs as the basis for estimating the cost of the current project.

In order to build a cost estimate, parametric estimation uses statistical modelling. To calculate an estimate for various parameters such as cost and length, it utilizes historical data from key cost drivers. Square footage, for instance, is used in some building projects.

In order to calculate an overall cost estimate for the project, bottom-up estimating uses the estimates of individual job packages that are then summarized or 'rolled up'. In general, this type of calculation is more comprehensive than other approaches since it looks at costs from a more granular perspective.

●      THREE - POINT ESTIMATING

By using three estimates, the three-point estimation approach defines a spectrum of operation costs.

1. Best case (B)
2. Most likely (M)
3. Worst case (W)

One of the main benefits of using the project cost estimation approach is that, compared to other project cost estimation methods, it gives you far more reliable and balanced estimates. The formula for three is used - estimation is :

Formula:  E = (B + 4M + W) /6

Software forecasting project management includes software cost estimating programs, spreadsheets, modelling applications, and tools for statistical software. This form of programme is particularly useful for looking at alternatives to cost estimation.

Unanimity, majority, plurality, division of points, and dictatorship are some decision techniques. All must insist on unanimity; there is a common consensus. Normally, a majority or plurality is decided by a vote. For a majority, more than half the participants must agree on the decision.

Q.9) What do you mean by Process and Project Domains?

Ans: Process and project domains

Process metrics guideline:

●      When analyzing data from metrics, utilizing common sense and organizational awareness.

●      Provide the people and teams that collect measurements and metrics with daily feedback. 

●      To intimidate individuals or teams, never use metrics.

●      Work to set specific targets and metrics that will be used to achieve them with professionals and teams.

●      Data on metrics that demonstrate a problem area should not be regarded as "negative" Such knowledge is merely a measure of process change.

●      To the exclusion of other significant metrics, don't obsess on a single metric.

Process metrics

➢      Quality related: Concentrate on the quality of goods and deliverables at work.

➢      Productivity related: Job development - an increased effort-related commodity.

➢      Statistical SAQ data: error categorization and analysis.

➢      Defect removal efficiency: Propagation of error from operation of processes to activity.

➢      Reuse data: The number of generated components and their degree of reusability.

Project metrics

●      Used by making the necessary changes to prevent delays and mitigate possible issues and risks to minimize the development timeline.

●      Used to ensure consistent access to product quality and, where appropriate, to change the technical approach to quality management.

●      Each project should be assessed by:

❏      Input: Measures of the tools needed to do the job (e.g. Personnel and instruments)

❏      Output: Measures of the deliverables or job items produced during the process of software engineering.

❏      Result: Measures that show the deliverables' efficacy.

Typical project metrics

●      Effort /time per software engineering task

●      Errors uncovered per review hour.

Changes (number) and their characteristics

Q.10) Write a short note on planning scope management.

Ans: Planning scope management

The process of developing a scope management plan that records how the scope of the project will be defined, validated, and managed is Plan Scope Management. The main advantage of this approach is that it offers guidance and direction on how to handle the scope throughout the project.

This is the process of developing a strategy for scope management that records how to identify, verify and monitor the scope of the project.

Scope management plan planning is close to project management plan planning. Before defining a performance for this phase, we have to start with a statement of work, WBS and other specifications.

1. Input: It offers an overview of the deliverables and approval requirements for a project as an input to the "Plan Scope Management" process.

2.     Expert judgment: This resource is an article explaining the judgments of experts and how they are used to help project managers establish a strategy for scope management.

3.     Output: The tools for creating a scope management plan, scope declaration, WBS, and how they are managed and recorded are defined.

Unit 4

Project Planning, Management and Estimation

Q.1) Write the steps for creating work breakdown structure.

Ans: Creating work breakdown structure

A common project management tool is a job breakdown structure. It is a diagram that helps to break down big projects into smaller and more manageable components that include the deliverables or results of the project that will be completed.

It is a project-oriented breakdown of deliverables that separates project deliverables into sub-deliverables and work packages that describe the work, length and expense of the tasks to be performed.

It has a structure that is hierarchical. Typically, having three stages of decomposition in a WBS is easier. You can add a fourth and a fifth level in the case of a more complicated project.

We have then mentioned the steps you need to take to build a scratch-based job breakdown structure.

Step 1: To define the project's deliverables and sub-deliverables, get the team together. This will include the project managers and the professionals in the subject matter.

Step 2: Collect the necessary documents, such as the project charter, the declaration of project scope and the strategy for project scope management.

Step 3: Identify the project's main deliverables. These should come at your WBS's second level. To complete the project, key deliverables will be necessary and will be carried out by separate teams, meaning the same team will not work on completing another deliverable.

Step 4: Split the main deliverables into smaller sections of the work (work packages) or, in other words, define the work that is required to complete each deliverable with the aid of the subject matter experts.

Step 5: Build a WBS dictionary that includes the description and scope of the various elements in your job breakdown structure as a text. The WBS dictionary contains details such as the name and ID of the job package, the name of the person to whom it is assigned, the due date, the approximate cost, etc. This will allow the team to better appreciate task packages.

Step 6: Using various formats, such as text-based work breakdown structures, tabular structures, or more visual ones like flowcharts, you can create a WBS. Share it with the team until it is over. With a safe share connection, a creatively functioning breakdown framework can be easily shared with the rest of your team. Once shared, you can collaborate on it in real time.

Q.2) What do you mean by the W5HH principle?

Ans: The W5HH principle

Barry Boehm gave a philosophy which prepares software projects with simple and manageable designs or outlines. He also presented a methodology to address the priorities, management, obligations and technological approach of the project and its required resources. Then he called it as the W5HH concept when few issues resulted in the success of the project properties, description and resulting plan.

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

Those questions are as follows:

❖      Why the system is going to be developed?

Both stakeholders must determine the validity of the product/project framework for the purposes of software work. Here Barry asks whether the object of the project would justify the cost of time spent on it by individuals?

❖      What is activities are needed to be done in this?

In this, Barry asks what role is currently expected to be performed for the project.

❖      When is this done?

After recognizing when project activities will be started and when they enter the final step to achieve the target, project scheduling is performed by team.

❖      Who is reason for these activities in this project?

For this, every member who is part of the software team is responsible. And it determines their positions.

❖      Where are these authoritatively located?

Tech professionals not only have positions in this, but consumers, clients and partners also have organizational roles and obligations as well.

❖      How is job technically and managerially finished?

After understanding the scope of the project that is being developed, all technical techniques and project management rules are established.

❖      How much part of each resource is required?

After estimating each resource as per customer/user requirements, software developers know this.

Q.3) Write short note on project initiation?

Ans: Project initiation

The implementation of the project is the first step of the life cycle of project management and businesses determine at this point if the project is needed and how useful it will be for them. The business case and feasibility analysis are the two metrics that are used to assess a planned project and determine its expectations.

Project initiation process:

Now that we have decided what the initiation of the project is and why it is so important, it is time to see what the key steps in the checklist for the initiation of the project are and how successful managers initiate their projects.

1. Creating a business case

The business case is an essential document which describes how the objectives of the project fit with the long-term goals of the organization. This report examines why the organization should invest its technological, financial and human capital on a particular project.

2.     Conducting a feasibility study

The next step after the acceptance of the business case is to assess the probability of the success of the project after considering all the variables. This research describes the project's high-level limitations and assumptions and determines whether or not the project is worth it.

3.     Establishing a project charter

Perhaps the most detailed and critical aspect of the process of project initiation is the project charter. To define the scope/goal, team members, and the potential timeline of the project, it responds to the 3 Ws.

In several cases, the charter is the first project document that outlines the necessary specifics, such as the project's objectives and constraints.

Communication and discussions are an important aspect of successful project management and a significant part of the time spent by a project manager is typically spent communicating with stakeholders. PMBOK describes stakeholders as anybody who can be impacted or have an impact on the project. Project stakeholders can be internal or external and each category has its own communication requirements.

Without a project team, no project can be initiated. Forming a working project team and assigning tasks and duties to them is an integral part of the initiation process of the project. It also increases the overall responsibility of the whole team by assigning tasks and responsibilities early on and can assist you as a manager in the later stages of the project life cycle.

It is a good idea to revisit the entire project initiation process after doing all to ensure that you missed nothing. You will have to check the work in later stages, as monitoring and control is one of the five phases of the life cycle of project management.

Q.4) Describe size & function- oriented metrics (FP & LOC), in detail.

Ans: Size & function- oriented metrics (FP & LOC)

Estimation of the size of software is an essential part of software project management. It helps the project manager to further predict the effort, cost and time which will be needed to build the product. The project size is a measure of the problem complexity in terms of the effort and time required to build the product.

There are two software matrices which are being used to estimate size:

●      Size Oriented metrics

It focuses on the size of the software that has been produced. If a software organization maintains simple records, a table of size-oriented measures, such as shown below can be created. The table lists each software development project that has been completed over the past few years and corresponding measures for that project.

It shows that for the project: alpha, 12,100 LOC were developed with 24 person months of effort, at a cost of $168,000. Note that the effort and cost recorded in the table represent all software engineering activities (i.e. analysis, design, code and test) and not just coding. Furthermore, it shows that 365 pages of documentation were developed, 134 errors were recorded before software was released and 29 defects were encountered after release to the customer within the first year of operation and three people worked on this project alpha.

In order to develop metrics that can be assimilated with similar metrics from other projects, we choose lines of code as our normalization value. From the rudimentary data contained in the table, a set of simple size-oriented metrics can be developed for each project:

●      Errors per KLOC (thousand lines of code).

●      Defects per KLOC.

●      $ per LOC.

●      Page of documentation per KLOC.

In addition, other interesting metrics can be computed:

●      Errors per person-month.

   LOC per person-month.

●      $ per page of documentation.

Size-oriented metrics are not universally accepted as the best way to measure the process of software development. Most of the controversy swirls around the use of lines of code as a key measure. Proponents of the LOC measure claim that LOC is an "artifact" of all software development projects that can be easily counted, that many existing software estimation models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists. On the other hand, opponents argue that LOC measures are programming language dependent, that they penalize well-designed but shorter programs, that they cannot easily accommodate nonprocedural languages, and that their use in estimation requires a level of detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long before analysis and design have been completed).

●      Function-Oriented Metrics

Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity.

Function points are computed by completing the table shown in Figure above. Five information domain characteristics are determined and counts are provided in the appropriate table location. Information domain values are defined in the following manner:

Number of user inputs – Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.

Number of user outputs – Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.

Number of user inquiries – An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.

Number of files – Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.

Number of external interfaces – All machine-readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted.

Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective. To compute function points (FP), the following relationship is used:

FP = count total * [0.65 + 0.01 * Σ(Fi)]

Where count total is the sum of all FP entries obtained from Figure above.

Q.5) What are the metrics for the project?

Ans: Metrics for project

These are indicators that relate to the quality of projects. They are used to measure errors, prices, scheduling, efficiency and estimation of different resources and deliverables of the project.

1. Schedule Variance: Any inconsistency is known as Schedule Variation between the expected completion of an operation and the actual completion.

Schedule variance = ((Actual calendar days – Planned calendar days) + Start variance)/ Planned calendar days x 100.

2.     Effort Variance: The gap between the expected effort outlined and the effort needed to actually execute the mission is called the variance of effort.

Effort variance = (Actual Effort – Planned Effort)/ Planned Effort x 100.

3.     Size Variance: Difference between the approximate project size and the project's actual size (normally in KLOC or FP).

Size variance = (Actual size – Estimated size)/ Estimated size x 100.

4.     Requirement Stability Index: Provides visibility of the extent and effect of changes in specifications.

RSI = 1- ((Number of changed + Number of deleted + Number of added) / Total number of initial requirements) x100.

1. Productivity (Project): A calculation of output for an input unit from a related process.

Project Productivity = Actual Project Size / Actual effort expended in the project.

2.     Productivity (for test case preparation) = Actual number of test cases/ Actual effort expended in test case preparation.

3.     Productivity (for test case execution) = Actual number of test cases / actual effort expended in testing.

4.     Productivity (defect detection) = Actual number of defects (review + testing) / actual effort spent on (review + testing).

5.     Productivity (defect fixation) = actual no of defects fixed/ actual effort spent on defect fixation.

6.     Schedule variance for a phase: The deviation between scheduled and actual schedules within a project for the phases.

Schedule variance for a phase = (Actual Calendar days for a phase – Planned calendar days for a phase + Start variance for a phase)/ (Planned calendar days for a phase) x 100

7.     Effort variance for a phase: The deviation between a scheduled and actual effort within the project for different phases.

Effort variance for a phase = (Actual effort for a phase – a planned effort for a phase)/ (planned effort for a phase) x 100.

Q.6) Define software project estimation.

Ans: Software Project Estimation

For an effective management accurate estimation of various measures is a must.

With correct estimation managers can manage and control the project more

Efficiently and effectively.

Project estimation may involve the following:

●      Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating the number of function points in the software. Lines of code depend upon coding practices and Function points vary according to the user or software requirement.

●      Effort estimation

The managers estimate efforts in terms of personnel requirement and man-hour required to produce the software. For effort estimation software size should be known. This can either be derived by managers’ experience, organization’s historical data or software size can be converted into efforts by using some standard formulae.

●      Time estimation

Once size and efforts are estimated, the time required to produce the software can be estimated. Efforts required is segregated into sub categories as per the requirement specifications and interdependency of various components of software. Software tasks are divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The tasks are scheduled on a day-to-day basis or in calendar months. The sum of time required to complete all tasks in hours or days is the total time invested to complete the project.

●      Cost estimation

This might be considered as the most difficult of all because it depends on more elements than any of the previous ones. For estimating project cost, it is required to consider -

• Size of software
• Software quality
• Hardware
• Additional software or tools, licenses etc.
• Skilled personnel with task-specific skills
• Travel involved
• Communication
• Training and support

Q.7) What do you mean by Decomposition technique?

Ans: Decomposition technique

The software is believed by this approach to be a product of different compositions.

Before it is possible to make an approximation and apply decomposition techniques, the planner must

-         Understand the complexity of the programme to be designed.

-         Generate an approximation of the size of the programme.

Two major models exist -

Line of code (LOC): The calculation is conducted on behalf of the number of codes in the software product line.

Functions points (FP): Estimation is performed on behalf of the number of software product feature points.

Either of two strategies is then used

-         Problem based estimation

Based on either code source lines or estimates of feature points.

-         Process based estimation

Based on the effort needed to achieve each assignment.

Problem-Based Estimation

Start with a restricted declaration of scope. Decompose the programme into problem functions that can be independently calculated for each one. For each function, compute a LOC or FP value. By adding the LOC or FP values to the base productivity metrics (e.g. LOC/person-month or FP/person-month) to extract cost or effort estimates. Merge for the whole project.

LOC and FP estimation are different estimation methods, but both have a number of characteristics in common. The project manager starts with a restricted software scope statement and tries to decompose software into problem functions that can be independently calculated from this statement. LOC or FP (the estimation variable) is then estimated for each function.

Process-Based Estimation

The most popular way of estimating a project is to base the estimation on the method that will be used. That is, the method is broken down into a relatively small set of tasks and it calculates the effort needed to accomplish each task.

Process-based estimation starts, like problem-based techniques, with a delineation of software functions obtained from the scope of the project. For each function, a sequence of software process operations must be performed.

Functions and related activities of the software process can be described as part of a table.

When problem functions and process activities are melded, the planner calculates the effort needed to execute each software process operation for each software function (e.g., person-months). These data constitute the table's core matrix.

Q.8) What are the cost estimation tools and techniques?

Ans: Cost estimation tools and technique

For all projects, accurate cost estimates are important. It would be difficult to prepare a business plan, set up comprehensive budgets, forecast resource needs or manage project costs without a cost estimate.

Estimating project costs scares a lot of people. They don't know how much it's going to cost, but they know whatever value they offer, their boss will keep them.

The Project Cost Engineer uses either one or a combination of the following instruments and techniques in the cost estimation process:

To estimate the cost of the project, expert judgement uses the expertise and knowledge of experts. The particular factors related to the project can be taken into account in this technique. It can also be biased, however.

The values such as scope, expense, budget and length or measurements of scale such as size, weight and complexity from a previous, equivalent project are used in an analogous cost estimate as the basis for calculating the same parameter or measurement for a current project.

This methodology relies on the actual cost of previous, related projects when calculating costs as the basis for estimating the cost of the current project.

In order to build a cost estimate, parametric estimation uses statistical modelling. To calculate an estimate for various parameters such as cost and length, it utilizes historical data from key cost drivers. Square footage, for instance, is used in some building projects.

In order to calculate an overall cost estimate for the project, bottom-up estimating uses the estimates of individual job packages that are then summarized or 'rolled up'. In general, this type of calculation is more comprehensive than other approaches since it looks at costs from a more granular perspective.

●      THREE - POINT ESTIMATING

By using three estimates, the three-point estimation approach defines a spectrum of operation costs.

1. Best case (B)
2. Most likely (M)
3. Worst case (W)

One of the main benefits of using the project cost estimation approach is that, compared to other project cost estimation methods, it gives you far more reliable and balanced estimates. The formula for three is used - estimation is :

Formula:  E = (B + 4M + W) /6

Software forecasting project management includes software cost estimating programs, spreadsheets, modelling applications, and tools for statistical software. This form of programme is particularly useful for looking at alternatives to cost estimation.

Unanimity, majority, plurality, division of points, and dictatorship are some decision techniques. All must insist on unanimity; there is a common consensus. Normally, a majority or plurality is decided by a vote. For a majority, more than half the participants must agree on the decision.

Q.9) What do you mean by Process and Project Domains?

Ans: Process and project domains

Process metrics guideline:

●      When analyzing data from metrics, utilizing common sense and organizational awareness.

●      Provide the people and teams that collect measurements and metrics with daily feedback. 

●      To intimidate individuals or teams, never use metrics.

●      Work to set specific targets and metrics that will be used to achieve them with professionals and teams.

●      Data on metrics that demonstrate a problem area should not be regarded as "negative" Such knowledge is merely a measure of process change.

●      To the exclusion of other significant metrics, don't obsess on a single metric.

Process metrics

➢      Quality related: Concentrate on the quality of goods and deliverables at work.

➢      Productivity related: Job development - an increased effort-related commodity.

➢      Statistical SAQ data: error categorization and analysis.

➢      Defect removal efficiency: Propagation of error from operation of processes to activity.

➢      Reuse data: The number of generated components and their degree of reusability.

Project metrics

●      Used by making the necessary changes to prevent delays and mitigate possible issues and risks to minimize the development timeline.

●      Used to ensure consistent access to product quality and, where appropriate, to change the technical approach to quality management.

●      Each project should be assessed by:

❏      Input: Measures of the tools needed to do the job (e.g. Personnel and instruments)

❏      Output: Measures of the deliverables or job items produced during the process of software engineering.

❏      Result: Measures that show the deliverables' efficacy.

Typical project metrics

●      Effort /time per software engineering task

●      Errors uncovered per review hour.

Changes (number) and their characteristics

Q.10) Write a short note on planning scope management.

Ans: Planning scope management

The process of developing a scope management plan that records how the scope of the project will be defined, validated, and managed is Plan Scope Management. The main advantage of this approach is that it offers guidance and direction on how to handle the scope throughout the project.

This is the process of developing a strategy for scope management that records how to identify, verify and monitor the scope of the project.

Scope management plan planning is close to project management plan planning. Before defining a performance for this phase, we have to start with a statement of work, WBS and other specifications.

1. Input: It offers an overview of the deliverables and approval requirements for a project as an input to the "Plan Scope Management" process.

2.     Expert judgment: This resource is an article explaining the judgments of experts and how they are used to help project managers establish a strategy for scope management.

3.     Output: The tools for creating a scope management plan, scope declaration, WBS, and how they are managed and recorded are defined.