Master of Computer Application (MCA) Semester 5 MC0084 Software Project Management & Quality Assurance

Assignment Set 1

Que 1. What is project management? Explain various activities involved in project management. Ans:
Project management is the discipline of organizing and managing resources in such a

way that these resources deliver all the work required to complete a project within the defined scope, time, and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service that brings about beneficial change or added value. This property of being a temporary and one-time undertaking contrasts with processes, or operations, which are permanent or semi-permanent ongoing functional work to create the same product or service over and over again. The management of these two systems is often very different and requires varying technical skills and philosophy, hence requiring the development of project management. The first challenge of project management is ensuring that a project is delivered within the defined constraints. The second, more ambitious, challenge is the optimized allocation and integration of the inputs needed to meet those pre-defined objectives. The project, therefore, is a carefully selected set of activities chosen to use resources (money, people, materials, energy, space, provisions, communication, quality, risk, etc.) to meet the pre-defined objectives. There are many software engineers, involved in the development of software product. Their work must be coordinated and managed. It is a traditional engineering practice to define a project manager, responsible for the total project management. Large projects may compose of several subprojects, and each of which may be subdivided into further sub-projects, if necessary. Overall, the project manager has to ensure that the project is completed.

Definitions Some of the professional bodies of software project management have Defined the project management in the following way

PMBOK (Project Management Institute PMI) Project Management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements DIN 69901 (Deutsches Institute for Normung German organization for execution. This chapter discusses the issues of project management artifacts, stakeholders, project development process, project charter and work break down structure. standardization)

Project Management is the complete set of tasks, techniques, tools applied during project

Project Management activities Project Management is composed of several different types of activities such as: 1. Planning the work or objectives: A manager must decide what objectives are to be achieved, what resources are required to achieve the objectives, how and when the resources are to be acquired and how the objectives are achieved 2. Assessing and controlling risk (or Risk Management): Risk is associated with several issues. It can be technical, methodology or financial one. Manager needs to plan from the starting of the project, to handle unexpected or sudden occurrence of risks. 3. Estimating resources: Resource estimation is another crucial task of the project manager. A resource can be software, hardware, human personnel, capital etc. Resource estimation involves the planning of required resources for the given tasks in the given period of time. Optimum utilization of these resources is the ultimate goal of the manager. 2

4. Allocation of resources and assigning tasks: This involves identification of task and allocation of required resources to fulfill the given task. For example, identification of skilled personnel to solve the given task. 5. Organizing the work: Organizing involves clear lines of authority and responsibility for groups of activities that achieve the goals of the enterprise. 6. Acquiring human resources (staffing): Staffing deals with hiring personnel, which involve recruiting, compensating, developing and promoting employees. 7. Directing activities: Directing involves leading subordinates. The goal of directing is to guide the subordinates and to understand and identify the organizational structure and goals of the enterprise. 8. Controlling project execution: Controlling consists of measuring and correcting activities to ensure that the goals are achieved. Controlling requires the measurement against plans and taking corrective action when development occurs. 9. Tracking and reporting progress: After assigning the tasks to the team members, it is

essential to track and monitor the work progress. The work progress is documented at regular intervals. 10. Forecasting future trends in the project: The project must be designed to facilitate

extensibility of new features in the forth coming days. This is very crucial task of manager or designer. Designers have to keep this point in mind, while designing architecture for the system. 11. Quality Management: Satisfying the customer requirements is called quality. Quality reflects in many ways. It can be through functionality, performance and external factors like portability etc. So the project manager needs to implement different quality management techniques from the analysis phase itself. 12. Issues solving: An issue can be a conflict among the team members, sudden

increase in the attrition rate of employees, sudden drop in rupee value etc. Based on the issues, proper corrective action needs to be taken to ensure the smooth working of the system. 13. Defect prevention: A defect is a flaw in the system. It is more serious than an error. A defect occurs because of improper design, poor quality etc. A thorough testing is needed before and after implementation of the product, to avoid the defects.

14. Project Closure meet:

Project closure describes the overall project details. The

details can be conveyed through closure reports. Ex. Performance reports, testing reports and project completion reports.

Que 2. Describe the following:

o Risk Categories o Risk components and Drivers o Risk Prioritization

Ans:
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: The degree of uncertainty that the product will meet its requirements and be fit for its intended use. The degree of uncertainty that the project budget will be maintained.

The degree of uncertainty that the result software will be easy to correct, adapt and enhance. The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. 4

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 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:

The probability that the risk condition will actually occur The impact if the risk condition does occur 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 which risk 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:
Scheduling is an inexact process in which it tries to predict the future. Whil it is not possible to know with certainty how long a project will take, there are techniques that can increase your likelihood of being close. If you are close in your planning and estimating, you can manage the project to achieve the schedule by accelerating some efforts or modifying approaches to meet required deadlines. In project management, a schedule consists of a list of 5

a project's terminal elements with intended start and finish dates. A Gantt chart can provide a graphical representation of a project schedule. Critical chain project management warns that terminal-element start dates and finish dates function as random variables, and suggests managing a project not by its traditional schedule but rather by using buffer management and a relay race Mentality. Many project scheduling software products exist which can do much of the tedious work of calculating the schedule automatically. However, before a project manager can use these tools, he or she should understand the concepts behind the WBS, dependencies, resource allocation, critical paths; Gantt charts PERT Diagrams and earned value. These are the real keys to planning a successful project. The purpose of scheduling is to plan how the activities in part or all of a project will be performed over a period of time. Scheduling uses a Work Breakdown Structure and estimates for a group of activities, to produce a schedule that predicts when the activities will occur and what the final end date for the group of activities will be. Scheduling uses a Work Breakdown Structure and estimates for a group of activities, to produce a schedule that predicts when the activities will occur and what the final end date for the group of activities will be. Scheduling can be applied to a whole project or a subset of a project, and can be used at varying levels of detail depending on the purpose of the schedule. One key ingredient in the scheduling process is experience in the project area; another is experience with scheduling in general. In every industry area there will be a body of knowledge that associates the accomplishment of known work efforts with time duration. In some industries, there are books recording industry standards for use by cost and schedule estimators. Interviewing those who have had experience with similar projects is the best way to determine how long things will really take. When preparing a schedule estimate, consider that transition between activities often takes time. Organizations or resources outside your direct control may not share your sense of schedule urgency, and their work may take longer to complete Beware of all external dependency relationships. Uncertain resources of talent, equipment, or data will likely result in extending the project schedule. Failure to meet schedule goals is most often due to unrealistic deadlines, passive project execution, unforeseen problems, or things overlooked in the plan

Scheduling Techniques

A schedule includes the following: The activities to be performed defined in Work Breakdown Structure Estimates of how long each activity will take Consideration of the dependencies between activities Estimates of effort for each activity are initially independent of the resources that will perform the activity. The Estimating technique explains how to develop estimates for the activities in a Work Breakdown Structure. We need to allocate resources to the activities and possibly modify the estimates depending on the skill level (or proficiency) of the resources available. We also need to confirm or define the dependencies between the activities. Then we need to develop and analyze the schedule. The following sections describe a number of individual techniques that are designed to do this.

PERT Technique

The Program Evaluation and Review Technique or Project Evaluation and Review Technique commonly abbreviated PERT - a model for project management to analyze and represent the tasks involved in completing a given project. PERT charts are visualization tools commonly used by project managers to control and administer the tasks required to complete a project. PERT charts are visualization tools commonly used by project managers to control and administer the tasks required to complete a project. PERT is basically a method to analyze the tasks involved in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. This model was invented by Booz Allen Hamilton, Inc. under contract to the United States Defense Departments US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine-launched ballistic missile project. PERT was developed in the 1950s, primarily to simplify the planning and scheduling of large and complex projects. It was able to incorporate uncertainty by making it possible to schedule a project not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented 7

The most famous part of PERT is the "PERT Networks", charts of timelines that interconnect. PERT is intended for very large-scale, one-time, complex, non-routine projects. The PERT chart provides a graphical display of Critical Path on a project. Most scheduling tools highlight the activities on the Critical Path. It is useful to include the following information in the activities on the PERT chart: Duration, Float Start date, End date, Resources Float The amount of surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule.

Fig 5.1

Gantt chart:Henry Laurence Gantt, A.B., M.E. (1861-23 November 1919) was a mechanical
engineer and management consultant who is most famous for developing the Gantt chart in the 1910s. These Gantt charts were employee on major infrastructure projects including the Hoover Dam and Interstate highway system and still are an important tool in project management. A Gantt chart allows for

Graphical representation of a schedule Clear and easy communication Resource allocation Tracking of the schedule Providing a history of the project

Fig: - Gantt. Chart

Taking its name from early project management innovator Henry L. Gantt, the basic Gantt chart is an easy way to document schedules. It is a horizontal-bar schedule showing activity start, duration, and completion. It shows the connection between events and the calendar, and provides a graphical analog of the activity duration. The Gantt schedule can illustrate the relationship between work activities having duration, events without duration that indicate a significant completion, and milestones that represent major achievements or decision points. Various annotations can be used to communicate the progress of the project effort compared to the baseline plan as well, to depict in a graphical way, areas where there are modified expectations from the baseline plan. Once a Gantt schedule has been established for a project, progress should be periodically plotted against the baseline schedule. If different functional areas are involved in a project, each area may need its own detailed schedules to support the project master schedule. In such cases it is important that working schedules be linked to a common master schedule in a way that they can be easily updated. Each activity or event on the schedule should have a responsible individual assigned, so there is clear ownership and schedule status can be updated without a lot of fuss.

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

Ans:- Design Concepts

A set of fundamental software design concepts has evolved over the past four decades. Although the degree of interest in each concept has varied over the years, each has stood the test of time. Each provides the software designer with a foundation from which more sophisticated design methods can be applied. Each helps the software engineer to answer the following questions. What criteria can be used to partition software into individual components? How function or data structure detail is separated from a conceptual representation of the software? What uniform criteria define the technical quality of a software design?

Abstraction:When we consider a modular solution to any problem, many levels of Abstraction can be posed. At the highest level of abstraction, a solution is Stated in broad terms using the language of the problem environment. Atlower levels of abstraction, a more procedural orientation is taken. Problemoriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. Wasserman [WAS83] provides a useful definition: The psychological notion of "abstraction" permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details; use of abstraction also permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure. Each step in the software process is a refinement in the level of abstraction of the software solution. During system engineering, software is allocated as an element of a computer-based system. During software requirements analysis, the software solution is stated in terms "that are familiar in the problem environment." As we move through the design process, the level of abstraction is reduced. Finally, the lowest level of abstraction is reached when source code is generated. As we move through different levels of abstraction, we work to create procedural and data abstractions. A procedural abstraction is a named sequence of instructions that has a specific and limited function. An example of a procedural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.). A data abstraction is a named

10

collection of data that describes a data object. In the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction door. Many modern programming languages provide mechanisms for creating abstract data types. For example, the Ada package is a programming language mechanism that provides support for both data and procedural abstraction. The original abstract data type is used as a template or generic data structure from which other data structures can be instantiated. Control abstraction is the third form of abstraction used in software design. Like procedural and data abstraction, control abstraction implies a program control mechanism without specifying internal details.

2. Refinement:Stepwise refinement is a top-down design strategy originally proposed by Niklaus A program is developed by successively refining levels of procedural detail. In each step (of the refinement), one or several instructions of the given program are decomposed into more detailed instructions. This successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of any underlying computer or programming language. As tasks are refined, so the data may have to be refined, decomposed, or structured, and it is natural to refine the program and the data specifications in parallel. Every refinement step implies some design decisions. It is important that the programmer be aware of the underlying criteria (for design decisions) and of the existence of alternative solutions. The process of program refinement proposed by Wirth is analogous to the process of refinement and partitioning that is used during requirements analysis. The differences that are in the level of implementation details are considered, not the approach. Refinement is actually a process of elaboration. We begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refinement helps the designer to reveal low-level details as design progresses. Both concepts aid the designer in creating a complete design model as the design evolves 11

3. Modularity:The concept of modularity in computer software has been espoused for almost five decades. Software architecture embodies modularity; that is, software is divided into separately named and addressable components, often called modules that are integrated to satisfy problem requirements. . It has been stated that "modularity is the single attribute of software that allows a program to be intellectually manageable" [MYE78]. Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a reader.How modular should we make software? The answers to these questions require an understanding of other design concepts considered later in this chapter. Another important question arises when modularity is considered. How do we define an appropriate module of a given size? The answer lies in the method(s) used to define modules within a system. Meyer [MEY88] defines five criteria that enable us to evaluate a design method with respect to its ability to define an effective modular system.

Modular decomposability: If a design method provides a systematic mechanism for decomposing the problem into sub-problems, it will reduce the complexity of the overall problem, thereby achieving an effective modular solution Modular composability: If a design method enables existing (reusable) design components to be assembled into a new system, it will yield a modular solution that does not reinvent the wheel. 12

Modular understandability: If a module can be understood as a standalone unit (without reference to other modules), it will be easier to build and easier to change. Modular continuity: If small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of change-induced side effects will be minimized. Modular protection: If an aberrant condition occurs within a module and its effects are constrained within that module, the impact of error-induced side effects will be minimized. Finally, it is important to note that a system may be designed modularly, even if its implementation must be "monolithic." There are situations (e.g., real time software, embedded software) in which relatively minimal speed and memory overhead introduced by subprograms (i.e., subroutines, procedures) is unacceptable. In such situations, software can and should be designed with modularity as an overriding philosophy. Code may be developed "in line." Although the program source code may not look modular at first glance, the philosophy has been maintained and the program will provide the benefits of a modular system. Control Hierarchy:Control hierarchy, also called program structure, represents the organization of program components (modules) and implies a hierarchy of control. It does not represent procedural aspects of software such as sequence of processes, occurrence or order of decisions, or repetition of operations; no is it necessarily applicable to all architectural styles. Different notations are used to represent control hierarchy for those architectural styles that are amenable to this representation. The most common is the tree like diagram (Figure 5.2) that represents hierarchical control for call and return architectures. A call and return architecture is a classic program structure that decomposes function into a control hierarchy where a main program invokes a number of program components, which in turn may invoke still other components. The control relationship among modules is expressed in the following way: A module that controls another module is said to be super ordinate to it, and conversely, a module controlled by another is said to be subordinate to the controller.

5. What is debugging? Explain the basic steps in debugging? Ans:Debugging:13

Debugging is the process of locating and fixing errors (known as bugs), in a computer program or hardware device. To debug a program or hardware device, you start with a known problem, isolate the source of the problem, and then fix it. When someone says they have debugged a program, or "removed the bugs" in a program, they imply that they have fixed the program, so that the bugs no longer exist in it. Debugging is a necessary process in almost any new software or hardware development process, whether a commercial product, an enterprise or personal application program. For complex products, debugging is done periodically throughout the development, and again during the customer beta test stages. As most computer programs and many

programmed hardware devices contain thousands of lines of code, almost any new product is likely to contain a few bugs. Invariably, the bugs in the functions that get the most use are found and fixed first. An early version of a program that has lots of bugs is referred to as "buggy." Debugging tools help identify coding errors at various stages of development. Some programming language packages include a facility for checking the code for errors as it is being written. Although each debugging experience is unique, certain general principles can be applied in debugging. This section particularly addresses debugging software, although many of these principles can also be applied to debugging hardware.

The Basic steps in Debugging:

Recognize that a bug exists Isolate the source of the bug Identify the cause of the bug Determine a fix for the bug Apply the fix and test it

Recognize a bug exists:Detection of bugs can be done proactively or passively. An experienced programmer often knows where errors are more likely to occur, based on the complexity of sections of the 14

program as well as possible data corruption. For example, any data obtained from a user should be treated suspiciously. Great care should be taken to verify that the format and content of the data are correct. Data obtained from transmissions should be checked to make sure the entire message (data) was received. Complex data that must be parsed and/or processed may contain unexpected combinations of values that were not anticipated, and not handled correctly. By inserting checks for likely error symptoms, the program can detect when data has been corrupted or not handled correctly.

Isolate sources of debugging:This step is often the most difficult (and therefore rewarding) step in debugging. The idea is to identify what portion of the system is causing the error. Unfortunately, the source of the problem isn't always the same as the source of the symptoms. For example, if an input record is corrupted, an error may not occur until the program is processing a different record, or performing some action based on the erroneous information, which could happen long after the record was read. This step often involves iterative testing. The programmer might first verify that the input is correct, next if it was read correctly, processed correctly, etc. For modular systems, this step can be a little easier by checking the validity of data passed across interfaces between different modules. If the input was correct, but the output was not, then the source of the error is within the module. By iteratively testing inputs and outputs, the debugger can identify within a few lines of code where the error is occurring. Identify Cause of the Bug:Having identified the source of the problem, the next task is to determine how the problem can be fixed. This is because the fix will modify the existing behavior of the system, which may produce unexpected results. Furthermore, fixing an existing bug can often either create additional bugs, or expose other bugs that were already present in the program, but never Exposed because of the original bug. These problems are often caused by the program executing a previously untested branch of code, or under previously untested conditions.

15

Determine a fix for the problem Fix and test:After the fix has been applied, it is important to test the system and determine that the fix the former problem correctly. Testing should be done for two purposes: (1) does the fix now handle the original problem correctly, and (2) make sure the fix hasn't created any undesirable side effects. For large systems, it is a good idea to have regression tests, a series of test runs that exercise the system. After significant changes and/or bug fixes, these tests can be repeated at any time to verify that the system still executes as expected. As new features are added, additional tests can be included in the test suite.

Que 6. What is a fish bone diagram? How is it helpful to the project management? Ans:Fishbone Diagram
Also Called: Cause-and-Effect Diagram, Ishikawa Diagram Variations: cause enumeration diagram, process fishbone, time-delay fishbone, CEDAC (cause-and-effect diagram with the addition of cards), desired-result fishbone, reverse fishbone diagram Description The fishbone diagram identifies many possible causes for an effect or problem. It can be used to structure a brainstorming session. It immediately sorts ideas into useful categories. When to Use a Fishbone Diagram

When identifying possible causes for a problem. Especially when a teams thinking tends to fall into ruts.

Fishbone Diagram Procedure Materials needed: flipchart or whiteboard, marking pens. 16

1. Agree on a problem statement (effect). Write it at the center right of the flipchart or whiteboard. Draw a box around it and draw a horizontal arrow running to it. 2. Brainstorm the major categories of causes of the problem. If this is difficult use generic headings:
o o o o o o

Methods Machines (equipment) People (manpower) Materials Measurement Environment

3. Write the categories of causes as branches from the main arrow. 4. Brainstorm all the possible causes of the problem. Ask: Why does this happen? As each idea is given, the facilitator writes it as a branch from the appropriate category. Causes can be written in several places if they relate to several categories. 5. Again ask why does this happen? about each cause. Write sub-causes branching off the causes. Continue to ask Why? and generate deeper levels of causes. Layers of branches indicate causal relationships. 6. When the group runs out of ideas, focus attention to places on the chart where ideas are few. Fishbone Diagram Example This fishbone diagram was drawn by a manufacturing team to try to understand the source of periodic iron contamination. The team used the six generic headings to prompt ideas. Layers of branches show thorough thinking about the causes of the problem.

17

Fishbone Diagram Example For example, under the heading Machines, the idea materials of construction shows four kinds of equipment and then several specific machine numbers. Note that some ideas appear in two different places. Calibration shows up under Methods as a factor in the analytical procedure, and also under Measurement as a cause of lab error. Iron tools can be considered a Methods problem when taking samples or a Manpower problem with maintenance personnel. Role of Fishbone Diagram in Project Management Fishbone diagrams primarily show the root causes of an event, e.g. quality failures. Therefore they are of vital importance in project management through project quality plan, fault detection, and task management. The proactive project managers apply fishbone diagrams for early planning, especially when gathering factors, and to identify hidden factors that can play significant role in the project. It is also used in mapping the operation, business process modeling and business process improvement. Tips to Successfully Build a Fishbone Diagram 1. Make sure that all the team members agree on the problem statement prior to beginning. 2. Consider all the possible factors for casualty and label them properly. 3. Split the overcrowded categories.

18

4. Merge the empty branches with others. 5. Study the root causes that are most likely to merit deeper investigation.

19