MC0084 Software Project Management & Quality Assurance

Que.1 what is project management? Explain various activities involved in project management. Ans. 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: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 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 with respect to Estimation and Budgeting of Projects: a. Software Cost Estimation and Methods b. COCOMO model and its variations Ans A Software Cost Estimation and Methods Following are the estimate software cost. 1. Algorithmic Models 2. Expert Judgment 3. Analogy Estimation 4. Top-Down Estimation 5. Bottom-Up Estimation 6. Parkinson's Principle 7. Price to Win 8. Bottom-Up Estimation 9. Each component of the software job is separately estimated, and the results aggregated to produce an estimate for the overall job. Cost Estimation Guidelines 1. Assign the initial estimating task to the final developers. 2. Delay finalizing the initial estimate until the end of a thorough study. 3. Anticipate and control user changes. 4. Monitor the progress of the proposed project. 5. Evaluate proposed project progress by using independent auditors. 6. Use the estimate to evaluate project personnel. 7. Computing management should carefully approve the cost estimate. 8. Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas. 9. Don't rely on cost estimating software for an accurate estimate. Ans B COCOMO model and its variations The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics. COCOMO was first published in 1981 Barry W. Boehm's Book Software engineering economics[1] as a model for estimating effort, cost, and schedule for software projects. COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases. The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics.

Que. 3. What is project scheduling? Explain different techniques for project scheduling. Ans 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: 1. 2. 3. 4. 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.

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 labeled 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.

Explain the Mathematics in software development? Explain its preliminaries also

Ans A mathematical specification of a system should be presented, and a solution developed in terms of a software architecture that implements the specification should be produced. Another advantage of using mathematics in the software process is that it provides a smooth transition between software engineering activities. Not only functional specifications but also system designs can be expressed in mathematics, and of course, the program code is a mathematical notation albeit a rather long-winded one. Mathematics has many useful properties for the developers of large systems. One of its most useful properties is that it is capable of succinctly and exactly describing a physical situation, an object or the outcome of an action. Ideally, the software engineer should be in the same position as the applied mathematician. The major property of mathematics is that it supports abstraction and is an excellent medium for modeling. As it is an exact medium there is little possibility of ambiguity: Specifications can be mathematically validated for contradictions and incompleteness, and vagueness disappears completely. Mathematical Preliminaries The intent of the section is to provide a brief introduction. Sets and Constructive Specification A set is a collection of objects or elements and is used as a cornerstone of formal methods. The elements contained within a set are unique (i.e., no duplicates are allowed). Sets with a small number of elements are written within curly brackets (braces) with the elements separated by commas. For example, the set {C++, Pascal, Ada, COBOL, Java} contains the names of five programming languages. The order in which the elements appear within a set is immaterial. The number of items in a set is known as its cardinality. The # operator returns a set's cardinality. For example, the expression #{A, B, C, D} = 4 implies that the cardinality operator has been applied to the set shown with a result indicating the number of items in the set. There are two ways of defining a set. A set may be defined by enumerating its elements (this is the way in which the sets just noted have been defined). The second approach is to create a constructive set specification. The general form of the members of a set is specified using a Boolean expression. Constructive set specification is preferable to enumeration because it enables a succinct definition of large sets. It also explicitly defines the rule that was used in constructing the set.

5. What is debugging? Explain the basic steps in debugging?

Ans
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 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 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. These are the following steps for finding the debugging in a computer or software. Step1. 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. Step2. 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, Step3. 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: Step4. 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 Step5. Cover lateral damage. This stage we are almost ready to start coding the fix, but we have to cover your ass before you change the code Step6. Fix the error. Thats it, finally you can fix the error! Step7. Validate the solution. Run all the test scripts and check that they all pass.

6. What is a fish bone diagram? How is it helpful to the project management?

Ans
FISH BONE DIAGRAM Ishikawa diagrams are 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 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.