Software Project Management: Last year Question Paper Questions with Answer

With AKTU’s Question Paper, you may embark on an Exciting Software Project Management Journey. Improve your understanding, test your knowledge, and fly to exam achievement.

Dudes 🤔.. You want more useful details regarding this subject. Please keep in mind this as well.

Important Questions For Software Project Management:
*Quantum          *B.tech-Syllabus
*Circulars           *B.tech AKTU RESULT
* Btech 4th Year

Section A: Short Question with Answer of Software Project Management

a. List the characteristics of software projects. 

Ans.

• 1. Invisibility
• 2. Complexity
• 3. Conformity
• 4. Flexibility

b. What is the difference between feasibility study and planning ?

Ans. Feasibility studies assess whether to pursue the business or another idea, whereas planning occurs after the choice to pursue the business has been made. Feasibility studies are essentially research initiatives, whereas planning is a projection of the future.

c. Differentiate between Spiral and Prototyping model ?  

Ans. 

d. What is error tracking ? 

Ans. Error tracking can also be used to estimate project progress. In this situation, we track errors in work deliverables (requirement specifications, design documents, source code, and so on) to assess a project’s status. 

e. What is schedule variance ? 

Ans. Schedule variance indicates if a project’s schedule is ahead or behind schedule. It is commonly used in Earned Value Management (EVM) to give project managers with a progress update at the point of analysis.

f. What is Fagan inspection?

Ans. A Fagan inspection is the process of looking for flaws in documents (such as source code or formal specifications) at various stages of the software development process.

g. What do you understand by boundary value analysis ? 

Ans. Boundary value analysis is a software testing technique that includes representatives of boundary values in a range in tests.  

h. Distinguish between informal and formal review. 

Ans. 

i. What is contract management ?

Ans. Contract administration is the process of managing agreements from their inception to its implementation by the designated party and, finally, their termination.

j. What are the different roles in SCM?

Ans. Activities under software configuration management (SCM) : 

• 1. Configuration identification 
• 2. Software configuration status reporting 
• 3. Audit and reviews

Section B : Solved Long Questions of Software Project Management

a. What is Work Breakdown Structure ? Explain its type.

Ans. Work breakdown structure :

• 1. Work Breakdown Structures (WBS) were first employed by the United States Department of Defense in the mid-1960s for the development of missile systems.
• 2. The goal of a work breakdown structure (WBS) is to divide the program/project into manageable bits of work to ease cost, scheduling, and technical content planning and control.
• 3. It defines the overall amount of work to be done and splits it into manageable components with increasing levels of detail.
• 4. A work breakdown structure (WBS) is a chart that depicts the important work parts, known as tasks, of a project to describe their links to one another and to the project as a whole.
• 5. The graphical form of the WBS can assist a project manager in predicting outcomes based on various situations, ensuring that optimal judgements regarding whether or not to adopt suggested procedures or changes are made.
• 6. A well-organized, detailed work breakdown structure can help key staff with resource allocation, project budgeting, procurement management, scheduling, quality assurance, quality control, risk management, product delivery, and service-oriented management.
• 7. While developing a work breakdown structure (WBS), the project manager first specifies the major objectives and then identifies the tasks required to achieve those objectives.
• 8. A work breakdown structure (WBS) looks like a tree, with the “trunk” at the top and the “branches” at the bottom.
• 9. The primary requirement or objective is shown at the top, with increasingly specific details shown as the observer reads down. 

Types of WBS :  

There are different types of projects and, therefore, different types of WBSS, each with unique elements. All WBSs have two or more of the five types of level 2 elements as shown in Fig.

These five types of elements are as follows : 

• 1. Product breakdown :
  • a. The most common and easiest WBS to design is one based on the physical structure of the product(s) being delivered (as the capital asset).
  • b. These projects have a tangible output product: software, a building, a dam, an aeroplane, a user’s handbook, and so on.
  • c. Alternatively, numerous products, such as an airport ground surveillance system, an information technology system for a centralised clearing house, an integrated deep water system, or an orbiting space laboratory system, may be given.
• 2. Service project breakdown :
  • a. There is no tangible, organised output for service initiatives. The output is a specific body of work completed for others: a conference, a party, a wedding, a vacation trip, and so on.  
  • b. The work breakdown is a logical collection of related work areas. 
• 3. Results project breakdown : 
  • a. There is no tangible, organised deliverable for results projects. The output is the result of a process that produces a product or a conclusion, such as cancer research, new medicine development, or cultural change.
  • b. The work breakdown is a series of accepted steps. 
• 4. Cross-cutting element : 
  • a. This is a split of product-wide items such as architectural design, assembly, and system testing.
  • b. They are typically technical and supportive in character. In level 2, there may be more than one aspect of this trait.
  • c. While there are no restrictions, such cross-cutting features are uncommon in service or outcomes projects.
• 5. Project management : 
  • a. This is a breakdown of the project’s managerial duties and managerial activities.
  • b. It comprises items such as reports, project evaluations, and other project management or staff tasks (Conceptually, these are the overhead of the project).
  • c. Typically, there is only one of these types of WBS elements, although it exists as a level 2 element on all projects.

b. What is vision and scope document ? Explain in detail. 

Ans.

• 1. A vision and scope document aids in the establishment of business needs and their alignment with software requirements specifications (SRSs).
• 2. A clear vision and scope help to accelerate the convergence of software requirements.
• 3. A typical vision and scope document template includes three main sections: 
  • i. Business requirements and context: It includes a concise overview of the product’s logic and business opportunity. It also contains the primary business objectives as well as some quantifiable success criteria for the objectives.
  • ii. Product vision: It provides a clear statement of the product goals. 
  • iii. Project scope and limitations: It specifies the functionality and features that will be included in subsequent product releases or versions.
• 4. Table 1 illustrates a template for a software vision and scope document.  

Table 1. Template for a software vision and scope document 

c. Explain RAD model with its advantages and disadvantages. 

Ans. RAD model :

• 1. Rapid application development (RAD) is a model of incremental software development that stresses a very short development cycle.
• 2. The RAD model is a “high-speed” modification of the linear sequential model that uses component-based construction to accomplish quick development.
• 3. If the requirements are well understood and the project scope is limited, the RAD approach allows a development team to construct a “fully working system” in a very short amount of time (example, 60 to 90 days).

Advantages : 

• 1. Requirements can be changed at any time. 
• 2. Encourages and priorities customer feedback. 
• 3. Reviews are quick. 
• 4. Development time is drastically reduced. 
• 5. More productivity with fewer people. 
• 6. Time between prototypes and iterations is short. 

Disadvantages : 

• 1. Needs strong team collaboration. 
• 2. Cannot work with large teams. 
• 3. Needs highly skilled developers. 
• 4. Needs user requirement throughout the life cycle of the product. 
• 5. Only suitable for projects which have a small development time. 
• 6. More complex to manage when compared to other models.

d. What do you understand by EVA ? Explain in detail. 

Ans. Earned value indicators: Earned value indicators are the indicators which defines something about the performance compared to the plan. 

Various earned value indicators are: 

• 1. Budgeted Cost of Work Performed (BCWP): In project management, budgeted cost of work performed (BCWP) or “Earned Value” (EV) is the budgeted cost of work that has actually been performed in carrying out a scheduled job during a given time period. 
• 2. Budgeted Cost of Work Scheduled (BCWS): It is the approved budget that has been allocated to complete a scheduled task during a specific time period. 
• 3. Actual Cost of Work Performed (ACWP): It is the actual cost that has been spent, rather than the budgeted cost.
• 4. Cost Variance (C): 
  • a. The word cost variation, commonly abbreviated CV, refers to the accurate measurement of cost performance on a certain project.
  • b. The cost variance is the algebraic difference between the earned value of a project (abbreviated EV) and the actual cost of the project (also known by the abbreviation AC).

• c. The equation to determine the cost variance would be broken down as follows : CV = EV minus AC. 
• d. If the resulting value for the cost variance is a number greater than zero (or “positive value”), then it is considered to be a favourable cost variance condition. 
• e. A value that is less than zero (or a resulting “negative” value) represents a cost variance that is considered less than favourable. 
• f. Because the cost variance is so dependent on the earned value and the actual cost, in order to maintain a favourable cost variance, it is advantageous for the project to minimize actual costs to the extent possible. 
• CV = BCWP – ACWP and CV = EV – AC
• 5. Schedule Variance (SV) :
  • a. Schedule variance is a quantitative measure used by project managers to gauge project performance during or after completion.
  • b. It is determined using a simple algebraic equation in which the earned value (EV) indicates the real amount of time required to complete or progress the project to its current stage.
  • c. The intended value (P) represents the amount of time it should have taken to reach the project’s current status according to the project management’s timetable.
  • d. Schedule variance (SV) is found by subtracting PV from EV. (EV – PV = S). 
  • e. Schedule variance and its exact number may indicate many possible things to project management. 
  • f. A value close to zero indicates that project management’s schedule and timeframes were accurate within a tiny margin of error.
  • g. A figure in the negatives indicates that project management either overestimated the amount of time required or overstated the budget and labour required to finish the project in raw man hours.
  • h. This is not a good thing either as it represents an unnecessary expenditure of resources. 
  • i. A schedule variance figure high in positive numbers could represent many things. 
  • j. It could indicate that project management underestimated the amount of time needed to complete the project, or it might indicate that the budget and workforce was insufficient. 
  • k. It could also mean that project management or the workforce suffered setbacks, foreseen or otherwise, which may or may not have been avoidable. It is given by formula 
  • SV = EV – PV 
• 6. Cost Performance Index : 
  • a. The cost performance index, commonly known as the acronym (CPI), refers to a method, chart, or other instrument that is used to determine/measure the real cost efficiency of a project.
  • b. The cost performance index is calculated by calculating the ratio of earned value (also known as EV) to actual costs (also known by the abbreviation of AC).
  • c. The equation to determine the cost performance index can be derived by the following equation : CPI = EV divided by AC. 
  • d. If the resulting value is more than one, it shows that the project’s cost-efficiency characteristics are favourable.
  • e. A resulting number less than one shows that the project’s cost efficiency characteristics are deemed less than favourable.
  • f. The cost performance index may alter over the course of a project based on how the earned values and real costs have changed.
  • g. This can also be shown by a simple formula,
  • CPI = EV/ACWP  
• 7. Schedule Performance Index (SPI) :  
  • a. The schedule performance index is a metric used by project management to assess project progress and efficiency.
  • b. A schedule performance index score of 1 or above is an ideal aim since it indicates to project management that the project is on track and has favourable conditions for accomplishing the required goals.
  • c. A schedule performance index less than l, on the other hand, should be avoided since it indicates that the project is not reaching goals and is exhibiting unfavourable conditions, which could lead to project failure if the current course of action is allowed to continue.
  • d. If the schedule performance index shows a trend of 1 or close to 1, project management will reevaluate the existing project conditions, conduct an analysis of current project trends, and initiate corrective actions.
  • e. If the trend of the schedule performance index rises, project management will study the goals and existing favourable conditions to perhaps re-evaluate the project’s short-term goals.
  • f. The schedule performance index is calculated as a ratio of Earned Value (EV) to Planned Value (PV) (PV).
  • g. Earned Value is the project’s value at the present time frame. The Planned Value is the project’s overall estimated value at the same time as the Earned Value.
  • h. To determine the project’s schedule performance index the project management divides the EV by the PV. This can also be shown by a simple formula: 
  • SPI = EV/PV.

e. Write a short note on SEI-CMIM. How does it differ from ISO-9000 ? 

Ans. SEI-CMIM : 

• 1. The capability maturity model (CMM) is not a model of the software life cycle. Rather, it is a technique for enhancing the software process, regardless of the life cycle model employed.
• 2. The CMM was created in 1987 by the Software Engineering Institute (SEI) at Carnegie Mellon University and is still being refined.
• 3. CMM is used to assess the maturity of an organization’s software processes and to identify the essential practises necessary to improve the maturity of these processes.

ISO9000 v/s CMM :

Section 3 : CPM Network in Software Project Management

a. Discuss the network model represented by the CPM network. 

Ans.

• 1. In 1957 the Critical Path Method (CPM) was developed as a network model for project management. 
• 2. In a network model, various states and events are represented. 
• 3. Many events occur between the initial and end states, and the project gains several intermediate stages.
• 4. The states are represented by circles, and the occurrences by arrows.
• 5. An event affects the project’s status, and the project itself has numerous events.
• 6. CPM is frequently used in tandem with the Project Evaluation and Review Method (PERT).
• 7. PERT is a representation of all the events and states in a project, together with the time of each event.
• 8. The objective of CPM and PERT is to devise analytic tools for scheduling the activities. 
• 9. Fig. 1 summarizes the steps of the techniques. 
• 10. First, we define the activities of the project, their precedence relationships, and their time requirements. 

• 11. Next, the precedence relationships among the activities are modeled as a network. 
• 12. The third step involves specific computations for developing the time schedule. 
• 13. During the actual execution phase, execution of the activities may not proceed as planned.
• 14. When this happens, the schedule is updated to reflect the realities on the ground. This is the reason for including a feedback loop in Fig. 1. 

b. Define hazard. How are hazards identified and analyzed ? 

Ans. Hazards: A hazard is defined as a “condition, event, or circumstance that could lead to or contribute to an unplanned or undesirable event.” 

Hazard Identification : 

• 1. The use of checklists and brainstorming are the two basic ways to hazard identification.
• 2. Checklists are simple lists of risks discovered to occur frequently in software development initiatives.
• 3. A group of project stakeholders evaluates a risk-identification checklist for their project.
• 4. The checklist frequently recommends potential countermeasures for each danger.
• 5. Brainstorming is the practise of detecting potential difficulties using the knowledge of key stakeholders about various aspects of the project.

Hazard Analysis: A hazard analysis is performed with the following steps :  

• 1. Define objectives. 
• 2. Define scope.  
• 3. Define and describe the system in terms of system boundaries and information to be used in the analysis. 
• 4. Identify the hazards. 
• 5. Collect data. 
• 6. Perform qualitative ranking of hazards based on their potential effects and their likelihood. 
• 7. Identify causal factors. 
• 8. Identify preventive or corrective measures and general design criteria and controls. 

Section 4 : Vision and Scope Document in Software Project Management

a. What is vision and scope document ? Explain in detail. 

Ans.

• 1. A vision and scope document aids in the establishment of business needs and their alignment with software requirements specifications (SRSs).
• 2. A clear vision and scope help to accelerate the convergence of software requirements.
• 3. A typical vision and scope document template includes three main sections: 
  • i. Business requirements and context: It includes a concise overview of the product’s logic and business opportunity. It also contains the primary business objectives as well as some quantifiable success criteria for the objectives.
  • ii. Product vision: It provides a clear statement of the product goals. 
  • iii. Project scope and limitations: It specifies the functionality and features that will be included in subsequent product releases or versions.
• 4. Table 1 illustrates a template for a software vision and scope document.  

Table 1. Template for a software vision and scope document

b. Explain how project can be evaluated against strategic, technical and economic criteria. 

Ans.

• 1. The initial assessment of organizational and financial feasibility is the foundation of a project’s success.
• 2. Project managers must explicitly justify the cost estimation and approval of the project.
• 3. Projects must be evaluated based on strategic, technical and economic grounds. 

• A. Strategic Assessment : 
  • 1. Strategic assessment is the first criteria for project evaluation. 
  • 2. It is used to assess whether a project fits in the long-term goal of the organization. 
  • 3. It is usually carried out by senior management. 
  • 4. It needs a strategic plan that clearly defines the objectives of the organization. 
  • 5. It evaluates individual projects against the strategic plan or the overall business objectives.
  • 6. Evaluation of project depends on:
    • i. How it contributes to programme goal. 
    • ii. Its viability. 
    • iii. Timing. 
    • iv. Resourcing.  
  • 7. For successful strategic assessment, there should be a strategic plan which defines : 
    • i. Organisation’s objective. 
    • ii. Provide context for defining programme goals. 
    • iii. Provide context for accessing individual project.
• B. Technical Assessment :  
  • 1. It is the second criteria for evaluating the project. 
  • 2. A proposed system’s technical assessment consists of comparing the desired functionality to the hardware and software available.
  • 3. A consistent and uniform hardware/software infrastructure is likely to constrain the nature of technical solutions.
  • 4. The organisational policy must define a uniform and consistent infrastructure to ensure that no constraints are imposed.
• C. Economic Assessment : 
  • 1. It is used to determine whether the project is the best alternative among others.
  • 2. It prioritises projects so that resources can be allocated appropriately if multiple projects are running concurrently.
  • 3. Cost-benefit analysis is an important and widely used method of conducting economic analysis.
  • 4. This is accomplished by weighing the predicted costs of system creation and operation against the system’s advantages.
  • 5. It takes in account : 
    • i. Expected cost of development of system. 
    • ii. Expected cost of operation of system.
    • iii. Benefits obtained.  
• 6. Assessment is based on :  
  • i. Whether the estimated costs are executed by the estimated income. 
  • ii. And by other benefits.

Section 5 : Risk Planning in Software Project Management

a. Explain with an example how critical path can be identified in precedence networks.

Ans.

• 1. A project often comprises of many activities that take place both concurrently and sequentially.
• 2. You draw a precedence diagram to determine the sequence of these actions.
• 3. After building the precedence diagram, identify the tasks that, if postponed, will cause the entire project to be delayed.
• 4. This is known as critical path. 

Example: You are managing the construction of a shed. Now, to determine the critical path in precedence networks following steps are used : 

Step 1: Define the duration of each activity : 

1. After creating a precedence diagram, define the estimated duration of each activity, as shown in Fig. 2. 

Step 2: Identify all the paths : 

1. The precedence diagram shown in Fig. 2 has three paths. 

2. These paths are shown in Fig. 3.

3. One of the paths in Fig. 3 is the critical path. 

4. By using the Critical Path Method or the Critical Path Analysis we can determine the critical path. 

Step 3: Calculate the duration of each path: 

1. In this step we simply add the duration of each activity in each path. 

2. For Path 1, we get :  

Duration for Path 1 = Duration of Start + Duration of Purchase Plot + Duration of Select Design + Duration of Purchase Wood + Duration of Assemble Shed + Duration of End 

Therefore, Duration of Path 1 = 0 days + 5 days + 3 days + 3 days + 8 days + 0 days = 19 days.  

3. Similarly, the duration of path 2 and path 3 : 

Duration of Path 2 = 0 days + 5 days + 3 days + 1 days + 8 days + 0 days = 17 days. 

Duration of Path 3 = 0 days +5 days + 3 days + 4 days + 4 days +6 days + 8 days + 8 days + 0 days = 38 days.  

4. Each path has a different duration. 

5. That means the Critical Path Method or the Critical Path Analysis is required to determine the most important path. 

Step 4: Identify the longest path : 

1. The longest path is the critical path. 

2. From the calculations in step 3, we can see that Path 3 is the longest. 

3. Therefore, if activity on this path is delayed, then the project will be delayed. 

4. After identifying the critical path, you can deduce the activities that when delayed will not impact the project. 

b. Explain risk planning and control in detail.  

Ans. Risk management is a very tedious task. It involves basically two steps :  

1. Risk assessment 

2. Risk control 

• 1. Risk assessment: It is the process of examining a project and identifying areas of potential risk. The risk assessment consists of three activities : 
  • a. Risks Identifying. 
  • b. Risk Analyzing.
  • c. Risk Prioritization. 

• a. Risk identification :
  • i. Risk identification is a methodical effort to identify threats to the project strategy. The goal of risk identification is to create a list of risk components known as a risk statement.
  • ii. A checklist of frequent risk areas for software projects or an examination of the contents of an organisational database of previously identified risks and mitigation measures can help with risk identification (both successful and unsuccessful).
  • iii. Risk identification is done collaboratively through brainstorming. A list of risk kinds can be utilised to aid the process.
  • iv. The end result of this step of the process is a list of potential hazards to the product, process, or business.

• v. Within the identification phase, several activities occur. The main activities are:  
  • 1. Identify risks: There are numerous approaches for identifying danger. Checklists, interviews, brainstorming sessions, reviews, and surveys are a few examples. A checklist is provided to be used as a tool for risk identification.
  • 2. Define risk attributes: After identifying the risks, they are evaluated using the following criteria: likelihood of occurrence (probability), consequence, and time frame for action. These are preliminary estimates that will be refined in the following step.  
  • 3. Document: The hazards are then recorded. A risk statement and context, in addition to the name of the hazards, must be included. During this early step, the risk issue, probability, and consequence are described in subjective terms.
  • 4. Communicate : 
    • a. Sharing knowledge with project participants. Uncertainties, knowledge, worries, and issues are all inputs to the identification step.
    • b. If previous projects have been completed, the resolution of these inputs may be saved in a database to assist project managers in detecting and locating relevant risk items.
    • c. The risk statement, which incorporates identified hazards that may harm the project, is the product of the identification phase.
    • d. Furthermore, together with the statements, risk context is produced. 
    • e. The context’s objective is to characterise the risk items, events, conditions, restrictions, assumptions, circumstances, contributing elements, and related issues by answering the questions what, when, where, how, and why of each identified risk.
    • f. One risk may have several responses to each of these. questions.
    • g. The project team and the risk management team should be included in the risk identification process. The whole project team and key stakeholders should be involved in the second iteration.
    • h. If an unbiased analysis is desired, a third iteration of risk identification may be performed by someone who is not involved in the project.

• b. Risk analysis :
  • i. After identifying the hazards, all items are assessed using several criteria. The risk analysis’s goal is to determine the likelihood and magnitude of each risk item’s loss.
  • ii. The risk statement and context created during the identification step serve as the input.
  • iii. This phase produces a risk list with a relative ranking of the hazards as well as additional analysis of the description, probability, consequence, and context.
  • iv. The main activities in this phase are : 
    • 1. Group similar risks: Detect duplicates and find new risk items by grouping the identified risks into categories. 
    • 2. Determine risk drivers: The risk drivers are the variables that influence the detected risk. The critical route model, for example, includes schedule drivers. Identifying these features aids in risk assessment and prioritisation.
    • 3. Determine source of risks: The sources of risks are the root causes of the risks. These are determined by asking the question why ? and trying to figure out what may have caused the risk. Several root causes may lead to the same risk.
    • 4. Estimate risk exposure: The risk exposure is a measure of the likelihood and impact of a risk item. The result can also be expressed in terms of loss (for example, life, money, property, reputation).
    • 5. Evaluate against criteria : 
      • a. Each risk item is evaluated using predetermined criteria that are relevant to the project.
      • b. Criteria can be specified in terms of likelihood of occurrence, consequence, and time frame.
      • c. The information is used to rank the risks. After that, risks can be prioritised and the most important hazards determined for monitoring.

• c. Risk prioritization : 
  • i. Risk prioritisation assists the project in focusing on the most serious risks by measuring risk exposure.
  • ii. Exposure is the product of the risk’s chance of causing a loss and the magnitude of that loss.
  • iii. This prioritisation can be done quantitatively by estimating the likelihood (0.1-1.0) and relative loss on a 1-10 scale.
  • iv. Multiplying these factors results in an estimate of risk exposure attributable to each risk item, which can range from 0.1 to 10.
  • v. The greater the risk, the more vigorously it should be addressed. It may be simpler to simply rate the likelihood and impact as High, Medium, or Low.
  • vi. Those items having at least one dimension rated as high are the ones to worry about first. 

• 2. Risk control: Risk control is the process of managing risks to achieve the desired outcomes. Risk control process involves the following activities : 
  • a. Risk planning
  • c. Risk resolution
  • d. Risk monitoring  
  • b. Risk mitigation

• a. Risk planning : 
  • i. Risk management planning generates a strategy for dealing with each significant risk, including mitigation strategies, owners, and time lines.
  • ii. Risk resolution is the execution of risk management strategy for each risk. Finally, risk management entails keeping track of your progress towards resolving each risk item.
  • iii. Risk planning is to identify strategies to deal with risk. These strategies fall into three categories: 
    • 1. Risk avoidance
    • 2. Risk minimization
    • 3. Risk contingency plans. 
• b. Risk mitigation :
  • i. Risk mitigation is a strategy for reducing or eliminating the most serious risks. The main question is, what should be done and who is responsible for eliminating or reducing the risk?
  • ii. The mitigation plan describes the activities that can be taken to reduce the red-rated risk and designates a principal handler for the action.
• c. Risk resolution :
  • i. Once a risk has happened, it must be resolved. Risk resolution is the execution of risk management strategy for each risk.
  • ii. If the risk is on the watch list, a plan for resolving the risk has already been developed. The project manager must react to the trigger and carry out the action plan.
  • iii. The project manager must also report on progress and remedy deviations from the plan.
  • iv. This phase’s input is the risk lists and their implementation. The result is a risk action strategy.
• d. Risk monitoring : 
  • i. Risk monitoring is the process of constantly reassessing risks as the project progresses and conditions change.
  • ii. For example, successful beta testing reduces the risk of the client organisation rejecting the system, whereas high turnover in development employees typically increases project and product risks.

Section 6 : Software Review in Software Project Management

a. What is software review ? Explain its types

Ans. Software review :

• 1. A software review is a filter or software engineering process that is used at various phases throughout software development to identify flaws and faults that can then be removed.
• 2. Software review “purifies” the software engineering operations of analysis, design, and coding.
• 3. As part of software engineering, many different types of reviews can be performed. Each has a purpose.
• 4. If technical concerns are discussed, a casual discussion around the coffee machine is a kind of review.
• 5. A formal presentation of software design to a group of customer management and technical employees is another type of evaluation.

Following are the types of software review : 

• Inspection :
  • 1. Inspections improve the reliability, availability, and maintainability of a software product.  
  • 2. Anything readable that is produced during software development can be inspected. 
  • 3. Inspections can be used in conjunction with structured, systematic testing to create a strong tool for developing defect-free programmes.
  • 4. The inspection activity follows a predefined procedure, with participants assigned to specific duties.
  • 5. An inspection team is made up of three to eight people who serve as moderator, author, reader, recorder, and inspector.
  • 6. Having a client representative participate in requirements specification inspections is also beneficial.
  • 7. During an inspection session, team members can exchange expertise and ideas through group inspections.
  • 8. The moderator is in charge of leading the inspection, scheduling meetings, controlling meetings, reporting inspection results, and following up on rework issues.
  • 9. The author generates or maintains the work output under scrutiny.
  • 10. While the team inspects the work result, the reader discusses the sections to them.
  • 11. The recorder categorises and documents problems and difficulties discovered throughout the examination.
  • 12. Everyone takes on the job of an inspector. Good inspectors, on the other hand, are individuals who created the specification for the work product being inspected.
  • 13. For example, during code inspection, the designer can work as an inspector, while a quality assurance representative can operate as a standard enforcer.
• Code inspection :
  • 1. Code inspection is performed to identify some frequent sorts of problems caused by misunderstanding and poor programming.
  • 2. In other words, code inspection is the process of inspecting programme code to identify flaws that code walkthrough can not detect.
  • 3. Unlike a walkthrough, the inspection meeting and procedure are significantly more formal.
  • 4. A group of peers inspects a work product privately first, then gather in a formal meeting to discuss potential problems discovered by people and to detect other defects.
  • 5. Any technical product, including requirements specifications, system design documents, detailed designs, code, and test plans, can be inspected.
  • 6. During identifying errors through code inspection, the standard of coding is also checked. 

b. Describes in details the principles of testing ?

Ans. Seven principles of testing are :

• 1. Testing shows the presence of defects: Software testing’s purpose is to make the software fail. Defects are reduced by software testing. Software testing focuses on the existence of flaws rather than the absence of defects. Software testing can confirm the presence of problems but cannot verify that the software is defect-free. 
• 2. Exhaustive testing is not possible: Exhaustive testing is the process of testing the functionality of software in all possible inputs (valid or invalid) and pre-conditions. Because exhaustive testing is impossible, the programme will never be able to test at every test scenario. It can only test a subset of the test cases and assume that the software is correct and will produce the correct output in all of them.
• 3. Early Testing: Early test activity is required to locate the software fault. The cost of detecting a fault in the early stages of SDLC will be relatively low. Software testing will begin from the first phase, i.e., the requirement analysis phase, to improve software performance.
• 4. Defect clustering: A small number of modules in a project can contain the majority of the problems. According to the Pareto Principle, 80% of software problems are caused by 20% of modules.
• 5. Pesticide paradox: Running the same test cases will not result in the discovery of new bugs. To detect new bugs, it is required to evaluate the test cases and add or update test cases.
• 6. Testing is context-dependent: The testing strategy is determined by the context of the software being produced. Various types of software require various methods of testing. The testing of an e-commerce site, for example, differs from the testing of an Android application.
• 7. Absence of errors fallacy: If a piece of software is 99% bug-free but does not meet the needs of the user, it is unusable. It is not only required for software to be 99% bug-free, but it is also necessary to meet all customer needs. 

Section 7 : Human Resource Management in Software Project Management

a. Explain in detail about Human Resource Management in detail.  

Ans.

• 1. Human resource management (HRM) is the practise of recruiting, hiring, deploying, and managing personnel in a business.
• 2. It is critical in reinforcing the organization’s predetermined culture with the suitable workers.
• 3. HRM encompasses procedures such as organisational planning, personnel acquisition, team development, and so on.
• 4. This process assists organisations in defining personnel management plans, assigning project roles, and determining reporting obligations.
• 5. The staffing plan specifies how and when team members will be recruited, as well as whether or not a training need exists and, if so, what training is required.
• 6. These processes helps in making the most effective use of the people involved with a project.
• 7. Roles are designated for persons or groups from inside or outside the organization. 
• 8. Processes are used multiple times in different phases of the project.

b. Write a short note on : 

i. Verification and Validation 

ii. Quality Assurance and Quality Control 

Ans. i. Verification and Validation : 

• 1. Requirements validation is concerned with showing that the requirements actually define the system that the customer wants. 
• 2. It refers to a set of activities that ensure that the software, that is, going to be build is traceable to customer requirements, i.e.,  “Are we building the right product”. 

• 3. Software verification, on the other hand, refers to a set of actions that ensure that software successfully implements a certain purpose, i.e., “Are we producing the product correctly?”
• 4. Software verification and validation is traditionally characterised as a system engineering process used to verify that quality is integrated into software throughout development.
• 5. V & V performs analysis and testing activities, evaluating and assessing software products and development processes during each software life cycle step, not after the development effort is over.
• 6. This provides early identification of errors, improving software performance, identification of program risks. V & V attacks on two of major contributor of software failure : 
  • a. incorrect or missing requirements, and
  • b. poor organization in software architecture and failure to plan effectively. 
• 7. It is also an effective risk management tool. V & V is often defined by standards that establish software development project management and software quality assurance criteria.

ii. Quality Assurance and Quality Control 

• A. Quality Assurance :  
  • 1. Quality assurance is the process of ensuring that all software engineering processes, methodologies, activities, and work items are monitored and meet the set standards.
  • 2. These established standards could be a single standard or a set of standards such as ISO 9000, the CMMI model, ISO15504, and so on.
  • 3. Quality assurance encompasses all software development stages, from requirements definition to coding and release.
  • 4. Quality assurance is concerned with enhancing the software development process and making it more efficient and effective in accordance with the quality standards established for software products.
  • 5. Its prime goal is to ensure quality. 
• B. Quality Control :
  • 1. Quality Control (QC) is a Software Engineering procedure that ensures the quality of a product or service.
  • 2. It is concerned with the quality of the “end products” and the final output rather than the procedures utilised to develop a product.
  • 3. The primary goal of QA is to ensure that the products meet the customer’s specifications and requirements.
  • 4. If an issue or problem is discovered, it must be resolved before the product is delivered to the consumer.
  • 5. QC also assesses people’s quality level skill sets and provides training and certifications.
  • 6. This evaluation is necessary for service-based organisations and aids in providing consumers with “perfect” service.