Subject / Code: SOFTWARE PROJECT MANAGEMENT/ AI OE908

QUESTION BANK
Year/Semester/Section: III/VI/A & B Dept: AIML

Understand the basics project contexts and suggest the application management
CO1
strategy.
CO2 Describe the role of professional ethics in successful software development.
Describe the key phases of project management.
CO3
Determine an appropriate project management approach through an evaluation of
CO4 the business context and scope of the project.

CO5 Describe project scheduling and project tracking.

1. Explain in details about capability maturity (CMM) model (CO1,K1)

The CMM provides a framework for organizing these evolutionary steps into five maturity
levels that lay successive foundations for continuous process improvement. These five levels define
an ordinal scale for measuring the maturity of an organization’s software process and for evaluating
its software process capability.
The levels also help an organization prioritize its improvement efforts. A maturity levels is a well
defined evolutionary plateau towards achieving a mature software process. Each maturity level
provides a layer in the foundation for continuous process improvement.
Each level comprises a set of process goals that when satisfied, stabilize an important component of
the software process. Achieving each level of the maturity framework establishes a different
component in the software process, resulting in an increases in the process capability of the
organization. The following characterization of the five maturity levels highlight the primary process
change made at each level:
Initial: The software process is characterized as ad hoc, and occasionally even chaotic. Few
processes are defined, and success depends on individual effort.
Repeatable: Basic project management processes are established to track cost, schedule, and
functionality. The necessary process discipline is in place to repeat earlier successes on projects
with similar applications.
Defined: The software process for both management and engineering activities is
documented, standardized, and integrated into a standard software process for the organization.
All projects use an approved, tailored version of the organization's standard software process for
developing and maintaining software.
Managed: Detailed measures of the software process and product quality are collected. Both
the software process and products are quantitatively understood and controlled.
Optimizing: Continuous process improvement is enabled by quantitative feedback from the
process and from piloting innovative ideas and technologies.
Behavioral characterization of the maturity levels:
Maturity Levels 2 through 5 can be characterized through the activities performed by the
organization to establish or improve the software process, by activities performed on each
project, and by the resulting process capability across projects. A behavioral characterization of
Level 1 is included to establish a base of comparison for process improvements at higher
maturity levels.

The Five Maturity Levels of CMM:

1. Level 1 – Initial (Ad hoc):

o Characteristics: Processes are unpredictable, poorly controlled, and reactive.
There is a lack of formal processes, and the outcome of projects is highly
dependent on the skills and effort of individuals. The organization typically
operates in a chaotic manner with little to no documentation or process
standardization.
o Focus: At this level, there is little focus on process improvement. Projects are
often over-budget, late, and may not meet the defined requirements.
2. Level 2 – Managed (Repeatable):
o Characteristics: The organization has basic project management processes in
place to track cost, schedule, and functionality. The focus is on ensuring that the
project is completed within defined constraints. There is a consistent process for
managing requirements, planning, and tracking performance, but the processes are
still relatively reactive rather than proactive.
o Focus: At this stage, organizations begin to establish a more structured approach
to managing projects. The processes are repeatable and can be applied to similar
projects to achieve consistent results.
3. Level 3 – Defined (Proactive):
o Characteristics: The organization has developed standard processes for all
aspects of the project life cycle. These processes are documented, communicated,
and standardized across the organization. There is a proactive focus on process
improvement, and processes are tailored based on the project's needs.
o Focus: At this level, the organization focuses on process improvement through
standardization, and there is a focus on consistent execution of these processes
 across various projects. The organization moves beyond individual projects to
enhance the organization's overall capability.
4. Level 4 – Quantitatively Managed:
o Characteristics: The organization uses quantitative data to control and measure
process performance. Data collection and analysis are integral to decision-making
and process improvement. Statistical methods and metrics are used to monitor
performance, predict outcomes, and identify areas for further improvement.
o Focus: At this stage, the organization begins to use metrics and statistical analysis
to make data-driven decisions. Process performance is tightly controlled, and the
organization is focused on consistently meeting performance targets.
5. Level 5 – Optimizing (Continuous Improvement):
o Characteristics: The organization has a culture of continuous improvement. It
continuously reviews processes and practices, making incremental and innovative
improvements based on quantitative feedback and lessons learned. The focus is on
maximizing process efficiency and minimizing defects, with a focus on
innovation and agile adaptation to changing needs.
o Focus: At this level, the organization continuously monitors and improves
processes to maintain high levels of performance. Innovation and process
improvement are integral to organizational culture, and the focus is on achieving
the highest possible performance.

2. Describe the concepts of KPA project management. (CO1, K2)

The CMM has five levels or stages that describe an evolutionary pattern of software process maturity
and serve as a guide for improvement. Each level has a set of Key Process Areas (KPA) that an
organization needs to focus on to achieve maturity at that level. There are also key practices
associated with each level that provide support for implementing improvements at that level. Each
KPA identifies a cluster of related activities that, when performed collectively, achieve a set of goals
considered important for enhancing software capability.
 Commitment
 Ability
 Activity
 Measurement
 Verification
 Level 2 KPAs
 Requirements Management
 Establish common understanding of customer requirements between the
customer and the software project
 Requirements is basis for planning and managing the software project
 Not working backwards from a given release date!
 Software Project Planning
 Establish reasonable plans for performing the software engineering
activities and for managing the software project
 Software Project Tracking and Oversight
 Establish adequate visibility into actual progress
 Take effective actions when project’s performance deviates significantly
from planned
 Software Subcontract Management
 Manage projects outsourced to subcontractors
 Software Quality Assurance
 Provide management with appropriate visibility into
 process being used by the software projects
 work products
 Software Configuration Management
 Establish and maintain the integrity of work products
 Product baseline
 Baseline authority
Level 3 KPAs
 Organization Process Focus
  Establish organizational responsibility for software process activities that
improve the organization’s overall software process capability
 Organization Process Definition
 Develop and maintain a usable set of software process assets
 stable foundation that can be institutionalized
 basis for defining meaningful data for quantitative process
management
 Training Program
 Develop skills and knowledge so that individual can perform their roles
effectively and efficiently
 Organizational responsibility
 Needs identified by project
 Integrated Software Management
 Integrated engineering and management activities
 Engineering and management processes are tailored from the
organizational standard processes
 Tailoring based on business environment and project needs
 Software Product Engineering
 technical activities of the project are well defined (SDLC)
 correct, consistent work products
 Intergroup Coordination
 Software engineering groups participate actively with other groups
 Peer Reviews
 early defect detection and removal
 better understanding of the products
 implemented with inspections, walkthroughs, etc
Level 4 KPAs
 Quantitative Process Management
 control process performance quantitatively
 actual results from following a software process
 focus on identifying and correcting special causes of variation with
respect to a baseline process
 Software Quality Management
 quantitative understanding of software quality
 products
 process

Level 5 KPAs
 Process Change Management
 continuous process improvement to improve quality, increase
productivity, decrease cycle time
 Technology Change Management
 identify and transfer beneficial new technologies
 tools
 methods
 processes
 Defect Prevention
 causal analysis of defects to prevent recurrence
3. Write short notes on role of project manager in effective team building (CO2, K1)

The role of the project manager encompasses many activities including:

• Planning and Defining Scope

• Activity Planning and Sequencing
• Resource Planning Developing Schedules Time Estimating
• Cost Estimating Developing a Budget Documentation
• Creating Charts and Schedules
• Risk Analysis
• Managing Risks and Issues Monitoring and Reporting Progress Team Leadership
• Strategic Influencing Business Partnering Working with Vendors
• Scalability, Interoperability and Portability Analysis
• Controlling Quality
• Benefits Realization

Effective Team Building

Team building refers to the process of creating and developing a group of individuals into a
cohesive team that works together effectively to achieve common goals. It involves enhancing
collaboration, trust, communication, and shared values within the team. Effective team building
is essential for improving performance, boosting morale, and ensuring that all team members
contribute to the overall success of the organization.

Key Aspects of Effective Team Building:

1. Clear Vision and Goals:

o A team needs to have a shared vision and well-defined goals to guide their
efforts. When everyone understands the team’s purpose and objectives, they can
work in alignment toward a common goal.
o Setting SMART goals (Specific, Measurable, Achievable, Relevant, Time-
bound) helps give clear direction and accountability.
2. Roles and Responsibilities:
 o Clearly defined roles and responsibilities ensure that every team member knows
their part in achieving the team’s goals. Understanding individual roles prevents
overlap and confusion.
o Teams benefit from having a mix of complementary skills, with each member
contributing their unique strengths.
3. Effective Communication:
o Open, honest, and respectful communication is essential for team success. Team
members should feel comfortable expressing ideas, providing feedback, and
discussing challenges.
o Active listening and regular meetings (both formal and informal) facilitate
ongoing communication and help prevent misunderstandings.
4. Trust and Mutual Respect:
o Trust is the foundation of any successful team. Team members must be able to
rely on each other to complete their tasks and support one another. Mutual
respect allows people to value differences and work together in harmony.
o Building trust requires consistent actions, transparent behavior, and follow-
through on commitments.
5. Collaboration and Cooperation:
o A well-functioning team encourages collaboration and cooperation rather than
competition. Team members should work together to leverage each other’s
strengths and achieve the team’s goals more effectively.
o Problem-solving sessions and brainstorming encourage creativity and innovation,
allowing the team to find the best solutions.
6. Positive Team Culture:
o Building a positive and inclusive culture is critical to fostering motivation,
engagement, and satisfaction within the team. Celebrating achievements, both big
and small, boosts morale and reinforces a sense of accomplishment.
o Team-building activities, whether they are work-related or social, help to build
stronger relationships among team members.
7. Conflict Resolution:
o Conflict is natural in any team, but how it’s handled can make the difference
between success and failure. It’s important to address conflicts early and in a
constructive manner.
o Open dialogue, understanding different viewpoints, and finding win-win
solutions can turn conflicts into opportunities for growth.
8. Leadership and Support:
o An effective team leader plays a pivotal role in guiding and supporting the team.
Leaders should be approachable, listen to team members, and provide clear
direction.
o Leaders should also motivate the team, provide constructive feedback, and
recognize achievements to ensure continued engagement.
9. Accountability and Motivation:
o Each team member should be held accountable for their own tasks and
responsibilities. Regular performance reviews and feedback can help maintain
accountability.
o Motivating team members through rewards, recognition, and a sense of purpose
helps maintain high levels of engagement.
10. Flexibility and Adaptability:
 o In a dynamic work environment, a team must be adaptable and open to change.
Encouraging flexibility and a willingness to adjust plans when necessary is key to
overcoming challenges and maintaining team success.

4. Write the role of metrics in software development?(CO2,K3)

Software metric is a measure of some property of a piece of software or its specifications.
• The goal is obtaining objective, reproducible and quantifiable measurements, which may have
numerous valuable applications in schedule and budget planning, cost estimation, quality
assurance testing, software debugging, software performance optimization, and optimal personnel
task assignments.
Role of Metrics In Software Development

5. Explain in details about project initiation phase (CO3,K1)

The Project Initiation Phase is the 1st phase in the Project Management Life Cycle, as it
involves starting up a new project.
 • You can start a new project by defining its objectives, scope, purpose and deliverables to
be produced. You'll also hire your project team, setup the Project Office and review the
project, to gain approval to begin the next phase.
• Overall, there are six key steps that you need to take to properly initiate a new project.
These Project Initiation steps and their corresponding templates are shown in the
following diagram.
• The Project Initiation Phase is the most crucial phase in the Project Life Cycle, as it's the
phase in which you define your scope and hire your team.

Projects are initiated for two broad reasons:

 Problems that lend themselves to systems solutions
 Opportunities for improving through: (a) upgrading systems (b) altering systems (c)
installing new systems
A feasibility study should provide management with enough information to decide:
 Whether the project can be done
 Whether the final product will benefit its intended users and organization
 What are the alternatives among which a solution will be chosen
 Is there a preferred alternative

The Project Charter

Project Charter as the project initiation document. The Project Charter, as defined in the
PMBOK® Guide (Third Edition), is:
”A document issued by the project initiator or sponsor that formally authorizes the existence
of a project, and provides the project manager with the authority to apply organizational
resources to project activities.”

The “project initiator” or Project Sponsor is external to the project organization and at a level
that is able to fund the project. The development and issuance of the Project Charter by the
project initiator links the project to the ongoing work of the organization. The Project Charter
documents:
 Business Needs (at a higher level than detailed business requirements)
 Project Justification (which may refer to other documents, such as a feasibility study,
business case, or other business needs analysis)
 Current Understanding of the Customer’s Requirements
  The deliverable or work product intended to satisfy the Customer’s requirements.

The Project Mandate

The PRINCE2® Manual describes the use of a Project Mandate document as the project
initiation document. PRINCE2® sets out what ought to be in a Project Mandate, but is not strict
about all of the content. PRINCE2® allows for the Starting Up a Project (SU) process to sort out
the initial information needed and reach the minimum level of organization and understanding
prior to initiation of the project.
The Project Mandate is essentially instructions from corporate management or programme
management to start using the PRINCE2® methodology, in the form of a project, to achieve the
desired business objectives. Although the content and complexity of the Project Mandate is
dependent on the needs of the project, topics might include:
 Authority responsible
 Background or Purpose for the project
 Project objectives
 Scope (a description or outline)
 Constraints
 Quality expectations
 Business Case outline (and description)
 Reference documents or sources of information
 Indication of the project executive (or project sponsor, in PMBOK® terms) and
recommendation for project manager
 Who the customer(s) are
 Who the user(s) are
 Other Stakeholders

6. Describe the concepts of resource allocation and project plan.(CO3,K2)

Resource allocation is the process of assigning and scheduling available resources in the
most effective and economical way possible.
• Projects will always need resources but they can often be scarce. The task, therefore, lies
with the project manager to determine the proper timing and allocation of those resources
within the project schedule.

Most common types of resources to allocate are

Resource allocation is an integral part of project management and it often revolves around
four primary types of resources. These resources are essential to consider, irrespective of the
industry or project scope.
• Financial
This includes the project’s budget and funding. Financial resources help acquire other
resources and ensure sufficient funds to cover all project aspects, from initial planning to
execution and completion.
• Physical
This involves tangible assets used in the project, such as equipment, materials, and
workspaces. Physical resources are necessary for the project’s actual construction or
development phase.
• People
 This category includes the people involved in the project, such as team members,
contractors, and consultants. Human resources carry out the tasks and responsibilities
outlined in the project plan.
• Technological
This includes software tools for planning and monitoring, communication systems, and
other technological aids that make project processes run more smoothly.

PROJECT PLAN
7. Write short notes on process tracking and Scheduling (CO4,K2)
8. Explain in details about Configuration item and Configuration audits (CO4, k3)

Software configuration management (SCM) is an umbrella activity that is applied throughout the
software process. Because change can occur at any time, SCM activities are developed to
Identify change
Control change
Ensure that change is being properly implemented
Report changes to others who may have an interest.
9. Write short notes about quality control.(CO5, K1)
Software Quality Control is the set of procedures used by organizations to ensure that a
software product will meet its quality goals at the best value to the customer, and to continually
improve the organization’s ability to produce software products in the future. Software quality
control refers to specified functional requirements as well as non-functional requirements such as
supportability, performance and usability. It also refers to the ability for software to perform well in
unforeseeable scenarios and to keep a relatively low defect rate. These specified procedures and
outlined requirements leads to the idea of Verification and Validation and software testing.
It is distinct from software quality assurance which includes audits of the quality management system
against a standard. Whereas software quality control is a control of products, software quality
assurance is a control of processes.
Software Quality Control is the function that checks whether the software project follows its
standards processes, and procedures, and that the project produces the desired internal and external
(deliverable) products i.e. output.
Definition:
Software Quality Control Plan :
Quality Control Plan implies to analyze the actions required to fulfill the project requirements
such that the end product meets its specifications and product quality is maintained .
The characteristics of the Quality Plan are as follows:
Consistent : The plan should follow the standard and guidelines set by LADOTD design manuals
and AASHTO standard.
Complete: The plan should include the overall representation of the project requirements, features,
documentation of the project plan .such plan should be developed through all the stages of the project
development activity.
Clear: The plan, thus developed should be very clear to the developer and also to the stakeholders
regarding project requirements and other project details .
Correct: The project details will be very clear to stakeholders regarding product delivery date of its
postponement or cancellation of the product.
Constructible: The project development plan should be such that if by chance some design errors
occurs in product development then it should be constructible within small time span .

To achieve 5 C's it is recognized that communication between stakeholders and developer is very
necessary .
Purpose
The purpose of Quality Control Plan is to assure that the quality of the product being developed is
maintained throughout the development process.The Plan also includes the procedures which assist
in controlling the quality of the product.
Objective
The main objective of Quality Control Plan is to provide mechanism by which all the plans are
executed consistently without any design errors. It ensures that the procedures are continuously
reviewed by the stakeholders and the designers. To achieve quality control, a project file document is
created where feedback is given at regular intervals. Periodic review of the feedback results in
appropriate changes in the development process.
Requirements of Quality Control
The basic requirements of Quality Control is to fulfill all the valid requirements of the project . It also
requires planning, documentation of the project development activities, constant supervision of
designer throughout the development process . It also require the developer to ensure that all the
project activities are co-ordinated and completed as per schedule and reviews are made
periodically.
Quality Control Staff
Mainly the QC team contains following members:

 Engineer of Record (EOR)

 Designer
 Technical Advisors
 Checkers/Testers
 Quality Assurance Manager
10. Explain in details about Importance of working capital management (CO5, K2)

Working capital is one of the important measurements of the financial position. The words of H.
G. Guthmann clearly explain the importance of working capital. “Working Capital is the life-blood
and nerve centre of the business.”
1.It helps measure profitability of an enterprise. In its absence, there would be neither
production nor profit.
2. Without adequate working capital an entity cannot meet its short-term liabilities in time.
3. A firm having a healthy working capital position can get loans easily from the market due
to its high reputation or goodwill.
4. Sufficient working capital helps maintain an uninterrupted flow of production by supplying
raw materials and payment of wages.
5. Sound working capital helps maintain optimum level of investment in current assets.
6. It enhances liquidity, solvency, credit worthiness and reputation of enterprise.
7. It provides necessary funds to meet unforeseen contingencies and thus helps the enterprise
run successfully during periods of crisis. TYPES OF WORKING CAPITAL

FACTORS DETERMINING WORKING CAPITAL

The following factor determine the amount of working capital
1. Nature of Companies: The composition of an asset is a function of the size of a business and the
companies to which it belongs. Small companies have smaller proportions of cash, receivables and
inventory than large corporation. This difference becomes more marked in large corporations. A public
utility, for example, mostly employs fixed assets in its operations, while a merchandising department
depends generally on inventory and receivable. Needs for working capital are thus determined by the
nature of an enterprise.
2. Demand of Creditors: Creditors are interested in the security of loans. They want their obligations to
be sufficiently covered. They want the amount of security in assets which are greater than the liability.
3. Cash Requirements: Cash is one of the current assets which are essential for the successful operations
of the production cycle. A minimum level of cash is always required to keep the operations going.
Adequate cash is also required to maintain good credit relation.
4. Nature and Size of Business: The working capital requirements of a firm are basically influenced by
the nature of its business. Trading and financial firms have a very less investment in fixed assets, but
require a large sum of money to be invested in working capital. Retail stores, for example, must carry
large stocks of a variety of goods to satisfy the varied and continues demand of their customers. Some
manufacturing business, such as tobacco manufacturing and construction firms also have to invest
substantially in working capital and a nominal amount in the fixed assets.
5. Time: The level of working capital depends upon the time required to manufacturing goods. If the time
is longer, the size of working capital is great. Moreover, the amount of working capital depends upon
inventory turnover and the unit cost of the goods that are sold. The greater this cost, the bigger is the
amount of working capital.
6. Volume of Sales: This is the most important factor affecting the size and components of working
capital. A firm maintains current assets because they are needed to support the operational activities
which result in sales. They volume of sales and the size of the working capital are directly related to each
other. As the volume of sales increase, there is an increase in the investment of working capital-in the cost
of operations, in inventories and receivables.
7. Terms of Purchases and Sales: If the credit terms of purchases are more favourable and those of sales
liberal, less cash will be invested in inventory. With more favourable credit terms, working capital
requirements can be reduced. A firm gets more time for payment to creditors or suppliers. A firm which
enjoys greater credit with banks needs less working capital.
8. Business Cycle: Business expands during periods of prosperity and declines during the period of
depression. Consequently, more working capital required during periods of prosperity and less during the
periods of depression.
9. Production Cycle: The time taken to convert raw materials into finished products is referred to as the
production cycle or operating cycle. The longer the production cycle, the greater is the requirements of
the working capital. An utmost care should be taken to shorten the period of the production cycle in order
to minimize working capital requirements.
10. Liquidity and Profitability: If a firm desires to take a greater risk for bigger gains or losses, it
reduces the size of its working capital in relation to its sales. If it is interested in improving its liquidity, it
increase the level of its working capital. However, this policy is likely to result in a reduction of the sales
volume, and therefore, of profitability. A firm, therefore, should choose between liquidity and
profitability and decide about its working capital requirements accordingly.
11. Seasonal Fluctuations: Seasonal fluctuations in sales affect the level of variable working capital.
Often, the demand for products may be of a seasonal nature. Yet inventories have got to be purchased
during certain seasons only. The size of the working capital in one period may, therefore, be bigger than
that in another.
11. Describe the concepts of Productivity improvement process.(CO1,K2)

The Productivity Improvement Process involves systematically identifying,

analyzing, and enhancing the various elements that contribute to an organization’s productivity.
It focuses on increasing output (or results) while minimizing resource consumption (e.g., time,
labor, materials, and capital). The goal is to achieve greater efficiency, effectiveness, and quality
in the organization’s operations, leading to improved performance and competitiveness.

Key Concepts of the Productivity Improvement Process:

1. Measurement of Productivity:
o Productivity is typically measured as the ratio of outputs to inputs. In a business
context, this could mean how much revenue or value is generated for each unit of
resource (e.g., time, labor, capital) used.
o Common formulas for measuring productivity include:
 Labor Productivity: Output (e.g., units produced) / Labor input (e.g.,
hours worked).
 Total Factor Productivity (TFP): Total Output / (Total Inputs, including
labor, capital, materials).

Measuring productivity is the first step in the process of improvement, as it helps identify
areas of inefficiency.

2. Identifying Productivity Gaps:

o The process starts with identifying areas where productivity is suboptimal. This
can involve:
 Reviewing historical performance data.
 Analyzing individual or departmental performance.
 Identifying bottlenecks or areas where resource utilization is poor.
o Root Cause Analysis is often employed to understand the underlying factors that
contribute to productivity gaps.
3. Process Optimization:
o Process optimization focuses on improving the efficiency of workflows, tasks, or
activities within the organization. Key strategies for process optimization include:
 Streamlining workflows: Reducing unnecessary steps or simplifying
processes.
 Automation: Using technology to automate repetitive or time-consuming
tasks, reducing human error and increasing speed.
 Eliminating bottlenecks: Identifying steps in the process that slow down
overall production and addressing them.
 Standardizing procedures: Creating standardized processes to eliminate
variability and errors.
4. Technology Integration:
o Technology adoption plays a vital role in improving productivity. Automation,
data analytics, machine learning, and AI are some tools that can increase
efficiency by speeding up processes, improving decision-making, and reducing
human error.
o Upgrading software, adopting collaborative tools, and leveraging data
management systems can also enhance productivity.

5. Employee Training and Development:

o Skilled employees contribute significantly to improving productivity. Training
and development ensure that employees are equipped with the right skills to
perform their tasks efficiently and effectively.
o Regular up-skilling and cross-training ensure that employees can adapt to new
processes, tools, and systems, thus enhancing their overall performance.
6. Workforce Motivation and Engagement:
o Motivated employees are more likely to be productive. Motivational factors that
can improve productivity include:
 Incentives and rewards: Recognizing and rewarding employees for high
performance can lead to greater engagement and effort.
 Job satisfaction: Providing employees with meaningful work and
opportunities for growth can boost morale and productivity.
 Work-life balance: Employees who are not overworked or stressed are
often more productive in the long run.

12. Describe the concepts of KPA Project Management. (CO1,K2)

The CMM has five levels or stages that describe an evolutionary pattern of
software process maturity and serve as a guide for improvement. Each level has a set of Key Process
Areas (KPA) that an organization needs to focus on to achieve maturity at that level. There are also
key practices associated with each level that provide support for implementing improvements at that
level. Each KPA identifies a cluster of related activities that, when performed collectively, achieve a
set of goals considered important for enhancing software capability.
 Commitment
 Ability
 Activity
 Measurement
 Verification
 Level 2 KPAs
 Requirements Management
 Establish common understanding of customer requirements between the
customer and the software project
 Requirements is basis for planning and managing the software project
 Not working backwards from a given release date!
 Software Project Planning
 Establish reasonable plans for performing the software engineering
activities and for managing the software project
 Software Project Tracking and Oversight
 Establish adequate visibility into actual progress
 Take effective actions when project’s performance deviates significantly
from planned
 Software Subcontract Management
 Manage projects outsourced to subcontractors
 Software Quality Assurance
 Provide management with appropriate visibility into
 process being used by the software projects
 work products
 Software Configuration Management
 Establish and maintain the integrity of work products
 Product baseline
 Baseline authority
Level 3 KPAs
 Organization Process Focus
  Establish organizational responsibility for software process activities that
improve the organization’s overall software process capability
 Organization Process Definition
 Develop and maintain a usable set of software process assets
 stable foundation that can be institutionalized
 basis for defining meaningful data for quantitative process
management
 Training Program
 Develop skills and knowledge so that individual can perform their roles
effectively and efficiently
 Organizational responsibility
 Needs identified by project
 Integrated Software Management
 Integrated engineering and management activities
 Engineering and management processes are tailored from the
organizational standard processes
 Tailoring based on business environment and project needs
 Software Product Engineering
 technical activities of the project are well defined (SDLC)
 correct, consistent work products
 Intergroup Coordination
 Software engineering groups participate actively with other groups
 Peer Reviews
 early defect detection and removal
 better understanding of the products
 implemented with inspections, walkthroughs, etc
Level 4 KPAs
 Quantitative Process Management
 control process performance quantitatively
 actual results from following a software process
 focus on identifying and correcting special causes of variation with
respect to a baseline process
 Software Quality Management
 quantitative understanding of software quality
 products
 process

Level 5 KPAs
 Process Change Management
 continuous process improvement to improve quality, increase
productivity, decrease cycle time
 Technology Change Management
 identify and transfer beneficial new technologies
 tools
 methods
 processes
 Defect Prevention
 causal analysis of defects to prevent recurrence
 UNIT - II
13. Explain about different Organization Structure in People Management (CO2,K1)
It is a framework within which an Organization arranges it’s lines of authorities
and communications and allocates rights and duties.
• All Organizations have a management structure that determines the relationships b/w
functions and positions and subdivides and delegates roles, responsibilities and authority
to carry out defined tasks.

Types of Organizational Structure

1. Tall & Flat Organizations
2. Divisional Structures
3. Global Structures
4. Matrix & Product Teams
5. Hybrid Structures
6. Coordinating Functions

1. Tall & Flat Organizations:

Tall structures: It have many levels of authority relative to the

organization’s size. As levels in the hierarchy increase, communication gets
difficult. The extra levels result in more time being taken to implement decisions.
Communications can also become garbled as it is repeated through the firm.
Large, complex organizations often require a taller hierarchy. In its simplest form,
a tall structure results in one long chain of command similar to the military. As an
organization grows, the number of management levels increases and the structure
grows taller. In a tall structure, managers form many ranks and each has a small
area of control.
2. Divisional Structures:

A division is a collection of functions working together to produce a product.

Divisions create smaller, manageable parts of a firm. Divisions develop a
business-level strategy to compete. A division has marketing, finance, and other
 functions. Functional managers report to divisional managers who then report to
corporate management.
◦ Product structure: divisions created according to the type of product or service.
◦ Geographic structure: divisions based on the area of a country or world served.
◦ Market structure: divisions based on the types of customers served.

3. Global Structures

When managers find different problems or demands across the globe, global
solutions are needed.
◦ Global geographic structure: different divisions serve each world region. For
customer needs
that vary between regions.
◦ Global product structure: Customers in different regions buy similar products so
firms keep
most functional work at home and set up a division to market product abroad.
4. Matrix & Product Teams

Matrix structure: managers group people by function and product teams

simultaneously. The results in a
complex network of reporting relationships and very flexible and can respond
rapidly to change. Each employee
has two bosses which can cause problems. Functional manager gives different
directions than product manager
and employee cannot satisfy both.
Product Team Structure: no 2-way reporting and the members are permanently
assigned to the team and
empowered to bring a product to market.
5. Hybrid Structures

Many large organizations have divisional structures where each manager can
select the best structure for
that particular division. One division may use a functional structure, one
geographic, and so on. This ability to
break a large organization into many smaller ones makes it much easier to
manage.

6. Coordinating Functions:

This structure is to ensure sufficient coordination between functions, managers

delegate authority.
Authority: the power vested in the manager to make decisions and use resources.
Hierarchy of authority: it describes the relative authority each manager has from
top to bottom.
Span of Control: it refers to the number of workers a manager manages.
Northern Line authority: it manages in the direct chain of command for production of
Goods or services.
Example: Sales Staff authority: it manages in positions that give advice to line
 Managers.
Example: Legal

Region
14. Explain about the Analysis of Data for Measuring Correctness, Integrity and
Maintainability of Software Products. (CO2,K3)
ISO/IEC9126 Software engineering — Product quality is an international standard
for the evaluation of software quality. The fundamental objective of this standard is to address some
of the well known human biases that can adversely affect the delivery and perception of a software
development project. These biases include changing priorities after the start of a project or not having
any clear definitions of "success." By clarifying, then agreeing on the project priorities and
subsequently converting abstract priorities (compliance) to measurable values (output data can be
validated against schema X with zero intervention), ISO/IEC 9126 tries to develop a common
understanding of the project's objectives and goals.
ISO 9126 Software Quality Factors
The standard is divided into four parts:
quality model
external metrics
Internal metrics quality in use metrics.

Software Quality is decomposed into seven factors

1. Functionality
2. Usability
3. Maintainability
4. Integrity
5. Correctness
6. Reusability
7. Interoperability
Functionality
The software performs as per the requirements and specifications. Testing is used to verify that the
requirements are met. Obviously this is the most basic of quality factors but can be problematic for
large, complex software.
Functionality is the essential purpose of any product or service. For certain items this is relatively
easy to define, for example a ship's anchor has the function of holding a ship at a given location. The
more functions a product has, e.g. an ATM machine, then the more complicated it becomes to define
it's functionality. For software a list of functions can be specified, i.e. a sales order processing
systems should be able to record customer information so that it can be used to reference a sales
order. A sales order system should also provide the functions listed below:

 Record sales order product, price and quantity.

 Calculate total price.
 Calculate appropriate sales tax.
 Calculate date available to ship, based on inventory.

Usability
Usability is an attempt to define user friendliness. It can be measured in terms of physical and
intellectual skill required to learn the system, time required to become moderately efficient in the use
of the system, the net increase in productivity over the system it replaces and a subjective assessment
of users' attitudes towards the system.
Maintainability
Software has a high degree of maintainability if it is easy to understand, enhance, and correct.
Criteria include consistency, simplicity, conciseness, self-descriptiveness, and modularity.
Maintainability cannot be measured directly. MTTC (mean time to change) is the time it takes to
analyze, design, and implement the change. Maintainable programs have a lower MTTC.
Integrity
Integrity is the ability of a system to withstand attacks to its security. Criteria include access control
and access audit. To measure integrity one must define:
a) Threat: the probability that an attack will occur within a given time.
b) Security: the probability that the attack of a specific type will be repelled.
Correctness
Correctness is the degree to which software performs its desired function. A common measure of
correctness is defects per KLOC. Defects are caught during regression testing reported by the user
during beta testing or in regular use of the product.
Reusability
Reusability is the ability of components of the software to be used in other applications. 
 Criteria
 Generality
 Self-descriptiveness
 Modularity
 Machine independence
 Software system independence

Interoperability
Interoperability is the ability of the software to work with other software systems or to
coexist without causing difficulties.

 Criteria
 Modularity
 Communications commonality
 Data commonality

UNIT - III
15. Explain in detail about Software Development Process. (CO3, K1)
A software development process, also known as a software
development life-cycle (SDLC), is a structure imposed on the development of a software
product. There are several models for such processes, each describing approaches to a variety of
tasks or activities that take place during the process. Some people consider a life-cycle model a
more general term and a software development process a more specific term.
16. Describe about Process of Inspection & Software Requirements
Specification(SRS).(CO3,K2)
The process should have entry criteria that determine if the inspection process is
ready to begin. This prevents unfinished work products from entering the inspection process.
• The stages in the inspections process are: Planning, Overview meeting, Preparation,
Inspection meeting, Rework and Follow-up. The Preparation, Inspection meeting and
Rework stages might be iterated.
 Planning: The inspection is planned by the moderator.
 Overview meeting: The author describes the background of the work product.
 Preparation: Each inspector examines the work product to identify possible defects.
 Inspection meeting: During this meeting the reader reads through the work product, part
by part and the inspectors point out the defects for every part.
 Rework: The author makes changes to the work product according to the action plans
from the inspection meeting.
 Follow-up: The changes by the author are checked to make sure everything is correct.

INSPECTION ROLES
During an inspection the following roles are used.
Author: The person who created the work product being inspected.
 Moderator: This is the leader of the inspection. The moderator plans the inspection and
coordinates it.
 Reader: The person reading through the documents, one item at a time. The other inspectors
then point out defects.
 Recorder/Scribe: The person that documents the defects that are found during the
inspection.
 Inspector: The person that examines the work product to identify possible defects.
 SOFTWARE REQUIREMENTS SPECIFICATION
• A software requirements specification (SRS) is a requirements specification for a software
system. It is a complete description of the behavior of a system to be developed.
• It may include a set of use cases that describe the interactions that the users will have with the
software. It also contains non-functional requirements which impose constraints on the
design or implementation.
• The software requirements specification document enlists all necessary requirements for
project development.
• To derive the requirements we need to have clear and thorough understanding of the products
to be developed. This is prepared after detailed communications with project team and the
customer.

UNIT - IV
17. Explain in detail about Software Configuration Management and its Items. (CO4,
K1)

Software configuration management (SCM) is an umbrella activity that is applied

throughout the software process. Because change can occur at any time, SCM activities are
developed to
Identify change
Control change
Ensure that change is being properly implemented
Report changes to others who may have an interest.
 18. Explain in detail about SCM Process, Version Control and Change Control. (CO4,
k3)

SCM is responsible for the identification of individual SCIs and various

versions of the software, the auditing of the software configuration to ensure that it has been
properly developed, and the reporting of all changes applied to the configuration. Any discussion
of SCM introduces a set of complex questions:
How does an organization identify and manage the many existing versions of a program (and
its documentation) in a manner that will enable change to be accommodated efficiently?
How does an organization control changes before and after software is released to a customer?
Who has responsibility for approving and ranking changes?
How can we ensure that changes have been made properly?
What mechanism is used to appraise others of changes that are made?

These questions lead us to the definition of five SCM tasks: identification, version control
change control, configuration auditing, and reporting.
 UNIT - V
19. Explain about Risk Analysis and Management and its types of Risk involved. (CO5,
K1)

Risks are simply potential problems. For example, every time we

cross the street, we run the risk of being hit by a car. The risk does not start until we make the
commitment, until we step in the street.
A software project may encounter various types of risks:
• Technical risks include problems with languages, project size, project functionality,
platforms, methods, standards, or processes. These risks may result from excessive
constraints, lack of experience, poorly defined parameters, or dependencies on
organizations outside the direct control of the project team.
• Management risks include lack of planning, lack of management experience and training,
communications problems, organizational issues, lack of authority, and control problems.
• Financial risks include cash flow, capital and budgetary issues, and return on investment
constraints.
• Contractual and legal risks include changing requirements, market-driven schedules,
health & safety issues, government regulation, and product warranty issues.
• Personnel risks include staffing lags, experience and training problems, ethical and moral
issues, staff conflicts, and productivity issues.
• Risk management is the process of measuring or assessing risk and then developing
strategies to manage the risk.
• Risk management requires you to identify potential risks; risk being anything that can
possibly harm or have a negative impact on the project.
Risk managers generally approach the search for potential risk from two distinct angles: Source
analysis and Problem analysis. Source analysis seeks to look at the potential sources of risk
whereas problem analysis looks at specific individual problems that could arise.

TYPES OF RISK INVOVLED

1. Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed
properly. Schedule risks mainly affect on project and finally on company economy and may
lead to project failure. Schedules often slip due to following reasons:
• Wrong time estimation
• Resources are not tracked properly. All resources like staff, systems, skills of
individuals etc.
• Failure to identify complex functionalities and time required to develop those
functionalities.
• Unexpected project scope expansions.
2. Budget Risk:
• Wrong budget estimation.
• Cost overruns
• Project scope expansion
3. Operational Risks
Risks of loss due to improper process implementation, failed system or some external
events risks. Causes of Operational risks:
• Failure to address priority conflicts
• Failure to resolve the responsibilities
• Insufficient resources
• No proper subject training
• No resource planning
• No communication in team.
4. Technical risks:
Technical risks generally lead to failure of functionality and performance. Causes of
technical risks are:
• Continuous changing requirements
• No advanced technology available or the existing technology is in initial stages.
• Product is complex to implement.
• Difficult project modules integration.
5. Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks
are outside the control of the program. These external events can be:
• Running out of fund.
• Market development
• Changing customer product strategy and priority
• Government rule changes.
 20. Describe about Defect Prevention Process in detail. (CO5, K2)

Reducing Costs and Enhancing Quality

“Prevention is better than cure” applies to defects in the software development life cycle as well
as illnesses in medical science. Defects, as defined by software developers, are variances from a
desired attribute. These attributes include complete and correct requirements and specifications as
drawn from the desires of potential customers. Thus, defects cause software to fail to meet
requirements and make customers unhappy.
And when a defect gets through during the development process, the earlier it is diagnosed, the
easier and cheaper is the rectification of the defect. The end result in prevention or early detection is
a product with zero or minimal defects.
How serious are defects in software development? In the United States, up to 60 percent of
software developers are involved in fixing errors, Computer Finance Magazine reported in 1998.
This fact alone, without consideration of providing the quality needed to please customers, shows the
value of preventing software defects.

Advantage of Early Defect Detection

Data to support the need for early fixes of software defects is supplied by several reports. The
National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of
fixing one bug found in the production stage of software is 15 hours compared to five hours of effort
if the same bug were found in the coding stage.
The Systems Sciences Institute at IBM has reported that the cost to fix an error found after
product release was four to five times as much as one uncovered during design, and up to 100 times
more than one identified in the maintenance phase

Figure 2.1 : Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)
Principles of Defect Prevention
How does a defect prevention mechanism work? The answer is in a defect prevention cycle
(Figure 2.2). The integral part of the defect prevention process begins with requirement analysis
– translating the customer requirements into product specifications without introducing additional
errors. Software architecture is designed, code review and testing are done to find out the defects,
followed by defect logging and documentation.

Figure 2.2: Defect Prevention Cycle (Source: 1998 IEEE Software Productivity Consortium)

The blocks and processes in the gray-colored block represent the handling of defects within the
existing philosophy of most of the software industry – defect detection, tracking/documenting and
analysis of defects for arriving at quick, short-term solutions.
The processes that form the integral part of the defect prevention methodology are on the white
background. The vital process of the defect prevention methodology is to analyze defects to get their
root causes, to determine a quick solution and preventive action. These preventive measures, after
consent and commitments from team members, are embedded into the organization as a baseline for
future projects. The methodology is aimed at providing the organization a long-term solution and the
maturity to learn from mistakes.
Most of the activities of the defect prevention methodology require a facilitator. The facilitator can
be the software development project leader (wearing another hat of responsibility) or any member of
the team. The designated defect prevention coordinator is actively involved in leading defect
prevention efforts, facilitating meetings and communication among team and management, and
consolidating the defect prevention measures/guidelines.