anant mc0084
TRANSCRIPT
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