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.

1

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 standardization)

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

execution”.

This chapter discusses the issues of project management artifacts,

stakeholders, project development process, project charter and work break

down structure.

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.

3

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:

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.

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

6

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 Department’s US Navy Special Projects Office in 1958 as part of the

Polaris mobile submarine-launched ballistic missile project. PERT was developed in the

1950’s, 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

8

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

9

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.

10

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

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.

11

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

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

12

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.

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.

13

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

Ans:-

Debugging:-

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

14

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

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

15

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.

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

16

When identifying possible causes for a problem.

Especially when a team’s thinking tends to fall into ruts.

Fishbone Diagram Procedure

Materials needed: flipchart or whiteboard, marking pens.

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 Methods

o Machines (equipment)

o People (manpower)

o Materials

o Measurement

o 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