MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)

Set-1

1. What is project management? Explain various activities involved in project management.

Ans:1 Project management is a systematic method of defining and achieving targets with optimized use of resources such as time, money, manpower, material, energy, and space. It is an application of knowledge, skills, resources, and techniques to meet project requirements. Project management involves various activities, which are as follows: Work planning Resource estimation Organizing the work Acquiring recourses such as manpower, material, energy, and space Risk assessment Task assigning Controlling the project execution Reporting the progress Directing the activities Analyzing the results

2. Describe the following: Risk Categories Risk components and Drivers Risk Prioritization Ans:2

Risk Categories : Project risks: Project risks threaten the projects plans. It is likely that project risks will slip and that costs will increase. Projects risks identify potential budgetary, schedule, resource, customer and requirements problems and their impact on software projects. Technical risks: Technical risks threaten the quality and timeliness of the software to be produced. Business risks: Business risks threaten the viability of the software to be built.

Risk components and Drivers : Risk components are defined as follows: Performance risk: The degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost risks: The degree of uncertainty that the project budget will be maintained. Support risks: The degree of uncertainty that the result software will be easy to correct, adapt and enhance. Schedule risks: The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time

Risk Prioritization : The identified risks for a project merely give the possible events that can hinder it from meeting the goal. The consequences of various risks, however, may differ. So before we proceed with management risks, project

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)
mangers prioritize them so that management energies can be focused on high risks. Prioritizatation requires analyzing the possible side effects of the risk event in case it actually occurs. Based on the possible consequences and the probability of the risks event occurring, you can compute the risk exposure, which you can then use for prioritizing risks. In risk prioritization, each identified risk is evaluated and assigned values for the following elements 1. The probability that the risk condition will actually occur. 2. The impact if the risk condition does occur. 3. The risk exposure Multiplying the risk probability by the impact would yield risk exposure, which is then compared against all other risk exposures to determine whichrisk will be given priority for risk mitigation. Since exposure is a relative measurement based on the numeric value assigned to risk probability and impact, consistency in assigning the probability and impact values is critical. A prioritized risks list that ranks risks by their exposure value determines the order in which risks will be addressed in risk mitigation and contingency planning.

3. What is project scheduling? Explain different techniques for project scheduling. Ans:3 Project scheduling is concerned with the techniques that can be employed to manage the activities that need to be undertaken during the development of a project. Scheduling is carried out in advance of the project commencing and involves: identifying the tasks that need to be carried out; estimating how long they will take; allocating resources (mainly personnel); scheduling when the tasks will occur. Once the project is underway control needs to be exerted to ensure that the plan continues to represent the best prediction of what will occur in the future: based on what occurs during the development; often necessitates revision of the plan. Effective project planning will help to ensure that the systems are delivered: within cost; within the time constraint; to a specific standard of quality. Two project scheduling techniques will be presented, the Milestone Chart (or Gantt Chart) and the Activity Network. Milestone Charts Milestones mark significant events in the life of a project, usually critical activities which must be achieved on time to avoid delay in the project. Milestones should be truely significant and be reasonable in terms of deadlines (avoid using intermediate stages). Examples include: installation of equipment; completion of phases; file conversion; cutover to the new system Gantt Charts A Gantt chart is a horizontal bar or line chart which will commonly include the following features: activities identified on the left hand side;

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)
time scale is drawn on the top (or bottom) of the chart; a horizontal open oblong or a line is drawn against each activity indicating estimated duration; dependencies between activities are shown; at a review point the oblongs are shaded to represent the actual time spent (an alternative is to represent actual and estimated by 2 separate lines); a vertical cursor (such as a transparent ruler) placed at the review point makes it possible to establish activities which are behind or ahead of schedule.

Activity Networks The foundation of the approach came from the Special Projects Office of the US Navy in 1958. It developed a technique for evaluating the performance of large development projects, which became known as PERT - Project Evaluation and Review Technique. Other variations of the same approach are known as the critical path method (CPM) or critical path analysis (CPA). The heart of any PERT chart is a network of tasks needed to complete a project, showing the order in which the tasks need to be completed and the dependencies between them. This is represented graphically:

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)

EXAMPLE OF ACTIVITY NETWORK The diagram consists of a number of circles, representing events within the development lifecycle, such as the start or completion of a task, and lines, which represent the tasks themselves. Each task is additionally labelled by its time duration. Thus the task between events 4 & 5 is planned to take 3 time units. The primary benefit is the identification of the critical path. The critical path = total time for activities on this path is greater than any other path through the network (delay in any task on the critical path leads to a delay in the project). Tasks on the critical path therefore need to be monitored carefully. The technique can be broken down into 3 stages: 1. Planning: identify tasks and estimate duration of times; arrange in feasible sequence; draw diagram. 2. Scheduling: establish timetable of start and finish times. 3. Analysis: establish float; evaluate and revise as necessary.

4. Explain the following Software design concepts: Abstraction Refinement Modularity Control Hierarchy Ans:4

Abstraction : Refinement : Modularity : Control Hierarchy :

5. What is debugging? Explain the basic steps in debugging? Ans:5 Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Debugging

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)
tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Many books have been written about debugging (see below: Further reading), as it involves numerous aspects, including: interactive debugging, control flow, integration testing, log files, monitoring (application, system), memory dumps, profiling, Statistical Process Control, and special design tactics to improve detection while simplifying changes. Step 1. Identify the error. This is an obvious step but a tricky one, sometimes a bad identification of an error can cause lots of wasted developing time, is usual that production errors reported by users are hard to be interpreted and sometimes the information we are getting from them is misleading. A few tips to make sure you identify correctly the bug are. See the error. This is easy if you spot the error, but not if it comes from a user, in that case see if you can get the user to send you a few screen captures or even use remote connection to see the error by yourself. Reproduce the error. You never should say that an error has been fixed if you were not able to reproduce it. Understand what the expected behavior should be. In complex applications could be hard to tell what should be the expected behavior of an error, but that knowledge is basic to be able to fix the problem, so we will have to talk with the product owner, check documentation to find this information Validate the identification. Confirm with the responsible of the application that the error is actually an error and that the expected behavior is correct. The validation can also lead to situations where is not necessary or not worth it to fix the error. Step 2. Find the error. Once we have an error correctly identified, is time to go through the code to find the exact spot where the error is located, at this stage we are not interested in understanding the big picture for the error, we are just focused on finding it. A few techniques that may help to find an error are: Logging. It can be to the console, file It should help you to trace the error in the code. Debugging. Debugging in the most technical sense of the word, meaning turning on whatever the debugger you are using and stepping through the code. Removing code. I discovered this method a year ago when we were trying to fix a very challenging bug. We had an application which a few seconds after performing an action was causing the system to crash but only on some computers and not always but only from time to time, when debugging, everything seemed to work as expected, and when the machine was crashing it happened with many different patterns, we were completely lost, and then it occurred to us the removing code approach. It worked more or less like this: We took out half of the code from the action causing the machine to crash, and we executed it hundreds of times, and the application crashed, we did the same with the other half of the code and the application didnt crash, so we knew the error was on the first half, we kept splitting the code until we found that the error was on a third party function we were using, so we just decided to rewrite it by ourselves. Step 3. Analyze the error. This is a critical step, use a bottom-up approach from the place the error was found and analyze the code so you can see the big picture of the error, analyzing a bug has two main goals: to check that around that error there arent any other errors to be found (the iceberg metaphor), and to make sure what are the risks of entering any collateral damage in the fix. Step 4. Prove your analysis This is a straight forward step, after analyzing the original bug you may have come with a few more errors that may appear on the application, this step its all about writing automated tests for these areas (is better to use a test framework as any from the xUnit family). Once you have your tests, you can run them and you should see all them failing, that proves that your analysis is right. Step 5. Cover lateral damage. At this stage you are almost ready to start coding the fix, but you have to cover your ass before you change the code, so you create or gather (if already created) all the unit tests for the code which is around where you will do the changes so that you will be sure after completing the modification that you wont have break anything else. If you run this unit tests, they all should pass. Step 6. Fix the error. Thats it, finally you can fix the error! Step 7. Validate the solution. Run all the test scripts and check that they all pass.

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)
6. What is a fish bone diagram? How is it helpful to the project management? Ans:6

FISH BONE DIAGRAM Ishikawa diagrams (also called fishbone diagrams, cause-and-effect diagrams or Fishikawa) are causal diagrams that show the causes of a certain event -- created by Kaoru Ishikawa (1990).[1] Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify these sources of variation. The categories typically include: People: Anyone involved with the process Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws Machines: Any equipment, computers, tools etc. required to accomplish the job Materials: Raw materials, parts, pens, paper, etc. used to produce the final product Measurements: Data generated from the process that are used to evaluate its quality Environment: The conditions, such as location, time, temperature, and culture in which the process operates Ishikawa diagrams were proposed by Ishikawa [2] in the 1960s, who pioneered quality management processes in the Kawasaki shipyards, and in the process became one of the founding fathers of modern management. It was first used in the 1940s, and is considered one of the seven basic tools of quality control.[3] It is known as a fishbone diagram because of its shape, similar to the side view of a fish skeleton. Mazda Motors famously used an Ishikawa diagram in the development of the Miata sports car, where the required result was "Jinba Ittai" or "Horse and Rider as One". The main causes included such aspects as "touch" and "braking" with the lesser causes including highly granular factors such as "50/50 weight distribution" and "able to rest elbow on top of driver's door". Every factor identified in the diagram was included in the final design. Causes Causes in the diagram are often categorized, such as to the 8 M's, described below. Cause-and-effect diagrams can reveal key relationships among various variables, and the possible causes provide additional insight into process behavior. Causes can be derived from brainstorming sessions. These groups can then be labeled as categories of the fishbone. They will typically be one of the traditional categories mentioned above but may be something unique to the application in a specific case. Causes can be traced back to root causes with the 5 Whys technique. Typical categories are: The 8 Ms (used in manufacturing)

MC0084 Software Project Management & Quality Assurance

(Book ID: B0958 & B0959)
The 8 Ps (used in service industry) The 4 Ss (used in service industry) One may find it helpful to use the Fishbone diagram in the following cases: To analyze and find the root cause of a complicated problem When there are many possible causes for a problem If the traditional way of approaching the problem (trial and error, trying all possible causes, and so on) is very time consuming The problem is very complicated and the project team cannot identify the root cause When not to use it Of course, the Fishbone diagram isn't applicable to every situation. Here are a just a few cases in which you should not use the Fishbone diagram because the diagrams either are not relevant or do not produce the expected results: The problem is simple or is already known. The team size is too small for brainstorming. There is a communication problem among the team members. There is a time constraint; all or sufficient headcount is not available for brainstorming. The team has experts who can fix any problem without much difficulty.