ROLL NO: * 19CS16

Name: * Anjali Kumari

Subject: * Software Engineering
Assignment: * #02
Date: * 30-11-2022
Q#1: Explain the software project management. Identify the
kinds of skills for administrators according to Robert L. katz.
Software project management is an art and discipline of planning and supervising
software projects. It is a sub-discipline of software project management in which
software projects planned, implemented, monitored and controlled.
It is a procedure of managing, allocating and timing resources to develop
computer software that fulfills requirements.

Types of skills for administrators:

Harvard Business Review first published Robert Katz’s “Skills of an Effective
Administrator” in 1955. It is still as applicable today as it was when first
published – which is why it is an HBR classic. Katz’s basic premise is that an
administrator (manager) must possess three different skill sets:
 Technical skills
 Conceptual skills
 Human skills

Technical skills: These skills are related to an individual’s specific area of

expertise. They are the ability of an accountant to understand cash flow
statements, income statements and balance sheets. They are the ability of a
graphics designer to understand the importance of colors and how to run the
latest software. These are the basic “languages of the task” if you will.

Conceptual skills: These skills are related to an individual’s ability to think

beyond the task at hand. These skills are the ability to picture how a new product
will impact a company’s position in the market. They are the ability to envision
how things will look five years in the future AND to take this vision of the future
and translate it in to a series of discrete steps that need to be accomplished to
reach this new state. These are the skills to envision the future

Human skills: These skills are related to an individual’s ability to effectively

interact with others. These are the skills that make some individuals great team
members and others terrible. They are the skills that allow some people to
succeed as mangers and others to fail. They allow individuals to multiply their
abilities by interacting with others.
Q#2: Why project planning is called first activity of project
management, discuss the different stages of project planning.
Project planning is at the heart of the project life cycle, and tells everyone
involved where you’re going and how you’re going to get there. The planning
phase is when the project plans are documented, the project deliverables and
requirements are defined, and the project schedule is created. The plans created
during this phase will help you manage time, cost, quality, changes, risk, and
related issues. They will also help you control staff and external suppliers to
ensure that you deliver the project on time, within budget, and within schedule.

Project planning steps:

1. Create and Analyze Business Case
2. Identify and Meet Stakeholders for Approval
3. Define Project Scope
4. Set Project Goals and Objectives
5. Determine Project Deliverables
6. Create Project Schedule and Milestones
7. Assignment of Tasks
8. Carry Out Risk Assessment

1. How to Create and Analyze Business Case?

The business case is the reason why your organization needs to carry out the
project. It should outline the problem, such as a lack of repeat customers or a
day longer supply line than competitors and describe how this will be solved
and how much monetary benefit should accrue to the organization once the
project is completed.
2. How to Identify and Meet Relevant Stakeholders for Approval?
Identifying project stakeholders means listing anyone who will be affected by
your project, so includes the public and government regulatory agencies. For
 the project planning phase however, it should only be necessary to meet those
who will directly decide whether the project will happen or not.
3. Define Project Scope?
The scope of your project is an outline of what it is and isn’t setting out to
achieve. It is necessary to delineate the boundaries of your project to prevent
“scope creep”, i.e. your resources going towards something that’s not in your
project’s goals.
4. Set Goals and Objectives
The goals and objectives for your project will build on the initial objectives
outlined in the business plan. At this step you will give finer detail to the initial
broad ideas and set them in a project charter as reference points for your project
as it proceeds.
5. Determine Deliverables
Deliverables are the concrete results that your project produces. One of the most
important project planning steps is to decide on what these deliverables will be
and who is responsible for both producing and receiving them.
6. Create Project Schedule and Milestones
Your project schedule is a very important document that outlines when different
tasks of a project are due to begin and end, along with major measurement
milestones. It will be referred to when measuring project progress. It will be
available to all stakeholders and should be adhered to as closely as possible.
7. Assignment of Tasks
Within your team everyone should know what their role is and who is responsible
for different elements of the project. Assigning tasks clearly should remove any
uncertainty about roles and responsibilities on your team.
8. Carry Out Risk Assessment
Having a functional risk management plan means performing a strong assessment
at the planning stage of the project. All potential risks should be identified along
with their possible effect on the project and likelihood of occurring.
Q#3: Software resources are primarily reusable building blocks.
Explain the different reusable components with complete
reference to software product.
Component-based software engineering (CBSE) emphasizes reusability—that is,
the creation and reuse of software building blocks. Such building blocks, often
called components, must be cataloged for easy reference, standardized for easy
application, and validated for easy integration.
Bennatan suggests four software resource categories that should be considered
as planning proceeds:

Off-the-shelf components: Existing software that can be acquired from a third

party or that has been developed internally for a past project. COTS (commercial
off-the-shelf) components are purchased from a third party, are ready for use on
the current project, and have been fully validated.

Full-experience components: Existing specifications, designs, code, or test data

developed for past projects that are similar to the software to be built for the
current project. Members of the current software team have had full experience
in the application area represented by these components. Therefore,
modifications required for full-experience components will be relatively low-risk.

Partial-experience components: Existing specifications, designs, code, or test

data developed for past projects that are related to the software to be built for
the current project but will require substantial modification. Members of the
current software team have only limited experience in the application area
represented by these components. Therefore, modifications required for partial-
experience components have a fair degree of risk.

New components: Software components that must be built by the software team
specifically for the needs of the current project.

The following guidelines should be considered by the software planner when

reusable components are specified as a resource:
1. If off-the-shelf components meet project requirements, acquire them. The cost
for acquisition and integration of off-the-shelf components will almost always be
less than the cost to develop equivalent software. In addition, risk is relatively
low.
2. If full-experience components are available, the risks associated with
modification and integration are generally acceptable. The project plan should
reflect the use of these components.
3. If partial-experience components are available, their use for the current project
must be analyzed. If extensive modification is required before the components
can be properly integrated with other elements of the software, proceed
carefully—risk is high. The cost to modify partial-experience components can
sometimes be greater than the cost to develop new components.

Ironically, reusable software components are often neglected during planning,

only to become a paramount concern during the development phase of the
software process. It is better to specify software resource requirements early. In
this way technical evaluation of the alternatives can be conducted and timely
acquisition can occur.
Q#4: Describe scope of the product. Identify the factors which
are helping in deciding the scope of the software product.

The Product Scope can be defined as the features and functions that characterize
a product. In other words, it defines and details the features, characteristics of a
product, service, or result. Therefore it involves technical specifications, features,
functions required to represent a product itself. Simply put, the product scope
focuses on how the product will look and how will it work. The product can be
described as the output or the end result of a project.

How to Identify the Scope of a Project: The Four Steps

Step 1: Identify Project Needs

The first step in the project scope checklist is to identify project needs. For this,
you need to:
 Establish a project timeline
 Understand project resource allocation needs
 Set project goals

It is essential to understand project requirements to know what exactly needs to

be done when trying to reach the end goal.

Step 2: Identify Project Objectives

Project objectives are the different business goals that a company wishes to
achieve through their product or service. A few examples of project objectives
include introducing a new product, developing new software, or creating a new
service in an organization. The best way to identify and determine project
objectives is through the S.M.A.R.T guidelines.
Specific – What are the project goals and objectives? Why and how will they be
achieved?
Measurable – Can all of them be accounted for?
Achievable – Can it be accomplished with the available resources?
Realistic – Can it be easily delivered, irrespective of any complications?
Time-bound – Can everything be achieved in the set time frame?
Make sure you have answers to all these questions before you proceed to the
third step.

Step 3: Identify Project Expectations

It is essential to identify project expectations for both the team working on the
project and the target audience. So, for the team, the project expectations
include the efficiency and effectiveness of the project’s operational process.

For the target audience, the main expectation is customer delight; that is how
happy the customers are when using your product or service. This usually is
determined by the product or service:
 Price
 Quality
 Availability
 Policies

Make sure you have identified and defined all these aspects when defining the
project scope.

Step 4: Identify Project Constraints

The last and most important step in the project scope checklist is identifying the
project constraints. Being aware of a project’s limitations is as equally important
as identifying its goals. This can minimize problems or issues faced during project
execution, thereby preventing any delay in deliverables.

A few things that can cause project constraints are:

 Internal and external conditions

 Dynamic environment
 Technical glitches
 Lack of resources
Q#5: Is it true that a software product can always be developed
faster by having a large development team of software
engineers? Describe different team organization structures.
The success of each project depends on the efficiency of internal communication.
If there are more than seven people in the team, finding the common ground
becomes more challenging. The optimal team size for the most productive
cooperation is up to five people. The solution for large projects that require more
people is to divide the developers into smaller groups based on the project
components each of them is working on.

Software engineering organizational structure

 Software engineering organizational structure
o Functional team
o Matrix team
o Product teams
Functional team:

In this organizational structure, employees who perform the same or similar

functions are put under a department. Each of the departments has a head that
manages every member of the team and reports to a higher authority on the
organization’s leadership hierarchy.

Matrix team:

The matrix form of organizational structure combines the two other forms of
corporate systems to manage projects. Despite being divided according to
departments, matrix teams are constantly in cross-departmental cooperation.
That makes it easy for them to achieve the company’s goal. If your software
engineering organization is launching a new product or starting a new marketing
strategy/goal, the matrix team is always an excellent choice.
Product teams:

Product teams are also referred to as division teams. The organizational structure
for software engineering firms requires you to divide your team along product
lines, geographical lines, or service lines, among others.

Each of the divisions will then have their departmental segmentation as with
functional team structure. For example, you can have your firm split according to
products like Mobile Application, Partner Portal, etc.

Q#6: Enlighten the role of 4Ps in software project management

also write the umbrella activities.
The four P’s are :
1. People
2. Product
3. Process
4. Project

People:
People are the primary resource on every project, and a well-managed team can
greatly increase the chances for success. Some of the different
roles people play in project management includes project manager, project team
members and information technology developers.
Product:
The project manager should define the product scope to ensure a successful
outcome.The product of a project can also be something that is intangible; such as
moving a company to a new headquarters or setting up a new company as a
registered legal entity to commence trading activities on day one.
Process:
The third P of project management is Process. Project managers and team members
should have a methodology and plan that outlines their approach. Without a clearly
defined process, team members will not know what to do and when to carry out
project activities.
Project:
The fourth and final P of project management is Project. This is where the project
manager’s roles and responsibilities come into play. He or she must guide team
members to achieve the project’s goals and objectives. The project manager must
delegate tasks, help team members when needed, and ultimately strive to
accomplish all requirements set forth in the project scope.

Umbrella activities consist of different tasks:

Software Project Tracking and Control

Formal Technical Reviews

Software Quality Assurance

SCM or Software configuration management

Document Preparation and Production

Re-usability Management

Measurement and Metrics

Risk Management
Q#7: Explain the different techniques used for proper Project
Management.
Five Helpful Project Management Techniques:

1. Work Breakdown Structure (WBS):

A WBS transforms big project activities into chunks of manageable tasks you and
your team can easily understand and complete.
So if you were constructing a house, like in the example above, you’d divide the
work into segments such as: internal work, external work, and building the
foundation.
From there, you’d break down the work further into work packages, based on
levels and task dependencies.

2. Gantt Charts:
Gantt charts have been around for a very long time, and they’re still a great
project management technique for beginners and pros alike.
It’s another technique that emphasizes visuality.
It’s a visual representation of all the tasks your team has to complete in order to
wrap up the project, visualized together with time spans.
You’ll be able to see task dependencies, how long each task will take, as well as
how its duration will affect the start dates and deadlines.

3. Critical Path Method (CPM):

The Critical Path Method is one of project management techniques used to

accurately schedule all project activities.
 What you’ll be actually doing is calculating the critical path – the shortest route
to project completion, and arranging tasks accordingly. It’s also a great way to
establish task dependencies.
You can combine CPM with PERT (Program Evaluation and Review Technique) to
create three task completion time estimates:
 Shortest amount of time
 Realistic amount of time
 The longest amount of time

4. Waterfall / Linear:
Waterfall is one of the oldest project management techniques.
If you use this project management technique, activities and tasks will linearly
flow through 5 phases:
 Requirements (Get all the necessary documentation)
 Design (Use a WBS to create a list of tasks)
 Implementation (Complete tasks)
 Verification (Review the deliverables)
 Maintenance (Maintain and modify if necessary).

5. Kanban:

Kanban is one of the easiest project management techniques for first-time project
managers.
The whole philosophy is in creating three columns:
 To-do
 Doing
 Done
Then, you and your team can simply shift tasks from one column to another as
you complete them.
Q#8: Compare the LOC and FP estimation techniques.

Function Point (FP) Line of Code (LOC)

Function Point metric is specification-

based. LOC metric is based on analogy.

Function Point metric is language

independent. LOC metric is dependent on language.

Function Point metric is user-

oriented. LOC metric is design-oriented.

Function Point metric is extendible to

Line of Code. It is changeable to FP (i.e, backfiring)

Function Point is used for data LOC is used for calculating the size of the
processing systems computer program

Function Point can be used to portray LOC is used for calculating and comparing the
the project time productivity of programmers.
Q#9: Explain the Cost estimation methods. Identify how algorithmic
method is more accurate than others in cost estimation.
Cost estimation in project management is the process of forecasting the financial and
other resources needed to complete a project within a defined scope. Cost
estimation accounts for each element required for the project—from materials to
labor—and calculates a total amount that determines a project’s budget. An initial
cost estimate can determine whether an organization greenlights a project, and if
the project moves forward, the estimate can be a factor in defining the project’s
scope. If the cost estimation comes in too high, an organization may decide to pare
down the project to fit what they can afford. Once the project is in motion, the cost
estimate is used to manage all of its affiliated costs in order to keep the project on
budget.

Algorithmic Method:
The algorithmic method is designed to provide some mathematical equations to
perform software estimation. The algorithmic methods have been largely studied
and there are a lot of models have been developed, such as COCOMO
models, Putnam model, and function points based models.

General advantages:
1. It is able to generate repeatable estimations.
2. It is easy to modify input data, refine and customize formulas.
3. It is efficient and able to support a family of estimations or a sensitivity
analysis.
4. It is objectively calibrated to previous experience.
Q#10: Discuss the models and models of COCOMO-I

COCOMO (Constructive Cost Model):

- The COCOMO (Constructive Cost Model) is one of the most popularly used
software cost estimation models i.e. it estimates or predicts the effort required
for the project, total project cost, and scheduled time for the project.

- This model depends on the number of lines of code for software product
development. It was developed by software engineer Barry Boehm in 1981.

- The COCOMO estimates the cost for software product development in terms of
effort (resources required to complete the project work) and schedule (time
required to complete the project work) based on the size of the software
product.

- It estimates the required number of Man-Months (MM) for the full development
of software products.

Example of COCOMO Model

Example: A project size of 200 KLOC is to be developed. The software
development team has average experience on similar types of projects. The
project schedule is not very tight. Calculate the Effort, development time, average
staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view
the size,

schedule and experience of development time.

Hence E=3.0(200)1.12=1133.12PM

D=2.5(1133.12)0.35=29.3PM

P= 176 LOC/PM
Q#11: What are the sub Models of COCOMO-II. Elaborate
each.
The sub-models in COCOMO 2 are:

a) Application composition model:

It is used when software is composed of existing parts. Supports prototyping

projects and projects where there is extensive reuse based on standard estimates
of developer productivity in an application (object) points/month. It Takes the
CASE tool use into account. The formula is:

PM = NOP/PROD = (Object Points x (1 - % reuse/100))/PROD

Where PM is the effort in person-months

NOP is the new object points

PROD is productivity.

b) Early design model:

This model is used when requirements are available but the design has not yet
started. In this model, Estimates can be made after the requirements have been
agreed upon. The empirical formula used to calculate a person's month is:
PM=AXSizeBXM

Where M= PERS×RCPX×RUSEXPDIF×PREX×FCILX SCED

A= 2.94 in an initial calibration

Size in KLOC

B varies from 1.1 to 1.24 depending on the novelty of the project, development
flexibility, risk management approaches, and process maturity.

c) Reuse-oriented Model:-

This model is used to compute the effort of integrating reusable components. A

major effort is required to integrate automatically generated code.
The empirical formula is:-

PMAuto = (ASLOC x (AT/100))/ATPROD

Where, ASLOC - No. LOC that has to be adapted

AT - % of adapted code that is automatically generated

d) Post-architecture model.

This model is used once the system architecture has been designed and more
information about the system is available. In this model, we use the same formula
as early design estimates: PM - Ax Size x M

Where Size estimate for the software should be more accurate at this stage. It
takes into consideration the factors like New code to be developed, reworks
required to support change, and the extent of possible reuse.
Q#12: Enlist the areas where risk can happen during development
of software project. Explain the risk management & risk
monitoring activities.
1. Tight Schedules

Often, project managers face the pressure of having to deliver the project
earlier than anticipated. This can happen due to many different reasons – lack
of resources, poor planning, or even technical glitches.

2. Budget Changes

Budget changes are a common occurrence, especially in software

development projects. A common reason why this happens is ‘scope
creep’. Scope creep is when you start off your project with a set of clear, well-
defined requirements, but as you approach the finish line, so many
requirements are added or deleted that all you’re left with is one big mess.

3. Technical Difficulties
Data security, information privacy, large-scale system implementation,
software integration, and compliance are some areas where you are likely to
run into unpredictable problems.

4. Poor Management
This may be a no-brainer but is unfortunately overlooked in many projects.
While many may blame budget overshoots and time constraints as the
reasons why software projects fail, the underlying reason is always poor
management.
Risk Management Activities:
Basically, three types of activities are covered under the risk management
process.

 Risk Identification:
In this stage, the possible project, product and business risks are
identified.

 Risk Analysis:
In this stage or process, the likelihood and consequences of these risks
assessed.

 Risk Control:
In this stage, risk assessments is done continuously and the risk reduction
plan is revised as more information about risk is available.

Risk Monitoring Activities:

Risk monitoring activities implement the risk monitoring strategy by gathering
information through automated or manual means, alerting or reporting on
information relevant to intended purposes for risk monitoring, and
providing inputs to ongoing risk assessment and response processes. Depending
on risk assumptions, constraints, priorities, and tolerance levels, the set of risk
monitoring practices actually implemented at any one time may differ from what
is documented in the risk monitoring strategy. NIST guidance recommends that
organizations consider risk monitoring from an organizational perspective and
coordinate monitoring practices across all three tiers to support the achievement
of overall risk management goals and avoid potential duplication of implemented
monitoring activities
Q#13: Explain your opinion on the following statements:

 Software Quality Assurance.

 Quality standards

 Process vs Product quality

 Quality attributes

 CMMI

Software Quality Assurance:

Software quality assurance (or SQA for short) is the ongoing process that ensures
the software product meets and complies with the organization’s established and
standardized quality specifications. SQA is a set of activities that verifies that
everyone involved with the project has correctly implemented all procedures and
processes.

SQA’s ultimate goal is to catch a product’s shortcomings and deficiencies before

the general public sees it. If mistakes get caught in-house, it means fewer
headaches for the development team and a lot less angry customers.

Quality standards:
Quality management standards are details of requirements, specifications,
guidelines and characteristics that products, services and processes should
consistently meet in order to ensure:

 their quality matches expectations

 they are fit for purpose
  they meet the needs of their users
Standards are an essential element of quality management systems.

Purpose of quality management standards:

Businesses use standards to satisfy their customers' quality requirements and for
a range of other reasons, such as:

 ensuring safety and reliability of their products and services

 complying with regulations, often at a lower cost
 defining and controlling internal processes
 meeting environmental objectives

CMMI:
The Capability Maturity Model Integration (CMMI) is a process and behavioral
model that helps organizations streamline process improvement and encourage
productive, efficient behaviors that decrease risks in software, product, and
service development.

The CMMI was developed by the Software Engineering Institute at Carnegie

Mellon University as a process improvement tool for projects, divisions, or
organizations. The DoD and U.S. Government helped develop the CMMI, which is
a common requirement for DoD and U.S. Government software development
contracts. The CMMI is currently administered by the CMMI Institute, which was
purchased by the ISACA in 2016.

The Capability Maturity Model Integration (CMMI) helps organizations streamline

process improvement, encouraging a productive, efficient culture that decreases
risks in software, product, and service development.
Process vs Product quality:
Let’s see the difference between Product and Process:-

S.
No. Product Process

While the process is a set of

sequence steps that have to be
1. Product is the final production of the project. followed to create a project.

Whereas the process is focused on

completing each step being
2. A product focuses on the final result. developed.

In the case of products, the firm guidelines are In contrast, the process
3. followed. consistently follows guidelines.

Whereas the process tends to be

4. A product tends to be short-term. long-term.

While the purpose of the process

The main goal of the product is to complete the is to make the quality of the
5. work successfully. project better.

A process serves as a model for

Product is created based on the needs and producing various goods in a
6. expectations of the customers. similar way.

A product layout is a style of layout design in When resources with similar

which the materials required to make the processes or functions are
product are placed in a single line depending grouped together, it is referred to
7. on the order of operations. as a process layout.

Product patents are thought to offer a greater A process patent provides the
8. level of protection than process patents. inventor only limited protection.
 Quality attributes:
Quality attributes, or technical requirements, are measurable and testable properties
of the system and the way they satisfy the needs of a user. It is a set of features or
properties to measure the performance and characterize how useful the software in
a specific environment is.

Software quality attributes can be divided into properties visible to a development

team and client or a development team only. For example, such qualities as
reliability and usability are directly experienced by a client. While maintainability is a
quality attribute of a software that can be fully evaluated by a development
organization exclusively. All of them measure product performance or quality
assurance and control.

Some of the major attributes to identify the level of software

development quality are:

 Availability;
 Correctness;
 Interoperability;
 Modifiability;
 Maintainability;
 Performance;
 Usability;
 Reusability;
 Reliability;
 Security;
 Testability.
Q#14: Discuss the risk associate with software projects.
“Risk is future uncertain events with a probability of occurrence and a potential
for loss”.Risk identification and management are the main concerns in every
software project. Effective analysis of software risks will help to effective planning
and assignments of work.

Categories of risks:
Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not
addressed properly. Schedule risks mainly affect on a 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.Unexpected
project scope expansions.

Budget Risk:
Wrong budget estimation. Cost overruns

 Project scope expansion

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 the team.
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.
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 the fund.
 Market development
Other Unavoidable Risks:
All the risks described above are those which can be anticipated to a certain
extended and planned for in advance. However there are certain risks which are
unavoidable in nature.
The reasons for such unavoidable risks are described below.
 Changes in government policy
 Obsolescence of software due to new technology from a rival company