Cost Estimation in Software Engineering

• Cost estimation in software engineering
• Cost overrun
• Putnam model
• Comparison of development estimation software
• Cone of uncertainty
• Software metric
• Analysis Effort method
• COCOMO
• COSYSMO
• Evidence-based Scheduling Refinement of typical agile estimating techniques using minimal measurement and total time accounting.
• Function Point Analysis
• Parametric Estimating
• PRICE Systems Founders of Commercial Parametric models that estimates the scope, cost, effort and schedule for software projects.
• Proxy-based estimating (PROBE) (from the Personal Software Process)
• Program Evaluation and Review Technique (PERT)
• SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk. Mimimum time and staffing concepts based on Brooks's law
• SLIM
• The Planning Game (from Extreme Programming)
• Weighted Micro Function Points (WMFP)
• Wideband Delphi
• The Use Case Points method (UCP)
• CETIN

Risk Management

Introduction

Risk is inevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided between two types, negative impact risk and positive impact risk.

Not all the time would project managers be facing negative impact risks as there are positive impact risks too. Once the risk has been identified, project managers need to come up with a mitigation plan or any other solution to counter attack the risk.

Project Risk Management

Managers can plan their strategy based on four steps of risk management which prevails in an organization. Following are the steps to manage risks effectively in an organization:

• Risk Identification
• Risk Quantification
• Risk Response
• Risk Monitoring and Control

Risk Identification

Managers face many difficulties when it comes to identifying and naming the risks that occur when undertaking projects. These risks could be resolved through structured or unstructured brainstorming or strategies. It's important to understand that risks pertaining to the project can only be handled by the project manager and other stakeholders of the project.

Risks, such as operational or business risks will be handled by the relevant teams. The risks that often impact a project are supplier risk, resource risk and budget risk. Supplier risk would refer to risks that can occur in case the supplier is not meeting the timeline to supply the resources required.

Resource risk occurs when the human resource used in the project is not enough or not skilled enough. Budget risk would refer to risks that can occur if the costs are more than what was budgeted.

Risk Quantification

Risks can be evaluated based on quantity. Project managers need to analyze the likely chances of a risk occurring with the help of a matrix.

Using the matrix, the project manager can categorize the risk into four categories as Low, Medium, High and Critical. The probability of occurrence and the impact on the project are the two parameters used for placing the risk in the matrix categories. As an example, if a risk occurrence is low (probability = 2) and it has the highest impact (impact = 4), the risk can be categorized as 'High'.

Risk Response

When it comes to risk management, it depends on the project manager to choose strategies that will reduce the risk to minimal. Project managers can choose between the four risk response strategies, which are outlined below.

• Risks can be avoided
• Pass on the risk
• Take corrective measures to reduce the impact of risks
• Acknowledge the risk

Risk Monitoring and Control

Risks can be monitored on a continuous basis to check if any change is made. New risks can be identified through the constant monitoring and assessing mechanisms.

Risk Management Process

Following are the considerations when it comes to risk management process:

• Each person involved in the process of planning needs to identify and understand the risks pertaining to the project.
• Once the team members have given their list of risks, the risks should be consolidated to a single list in order to remove the duplications.
• Assessing the probability and impact of the risks involved with the help of a matrix.
• Split the team into subgroups where each group will identify the triggers that lead to project risks.
• The teams need to come up with a contingency plan whereby to strategically eliminate the risks involved or identified.
• Plan the risk management process. Each person involved in the project is assigned a risk in which he/she looks out for any triggers and then finds a suitable solution for it.

Risk Register

Often project managers will compile a document, which outlines the risks involved and the strategies in place. This document is vital as it provides a huge deal of information.

Risk register will often consists of diagrams to aid the reader as to the types of risks that are dealt by the organization and the course of action taken. The risk register should be freely accessible for all the members of the project team.

Project Risk; an Opportunity or a Threat?

As mentioned above, risks contain two sides. It can be either viewed as a negative element or a positive element. Negative risks can be detrimental factors that can haphazard situations for a project.

Therefore, these should be curbed once identified. On the other hand, positive risks can bring about acknowledgements from both the customer and the management. All the risks need to be addressed by the project manager.

Conclusion

An organization will not be able to fully eliminate or eradicate risks. Every project engagement will have its own set of risks to be dealt with. A certain degree of risk will be involved when undertaking a project.

The risk management process should not be compromised at any point, if ignored can lead to detrimental effects. The entire management team of the organization should be aware of the project risk management methodologies and techniques.

Software Requirements Specification (SRS)

A software requirements specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements, and may include a set of use cases that describe interactions the users will have with the software.
Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules
The software requirements specification document enlists enough and necessary requirements that are required for the project development To derive the requirements we need to have clear and thorough understanding of the products to be developed or being developed. This is achieved and refined with detailed and continuous communications with the project team and customer till the completion of the software.
The SRS may be one of a contract deliverable Data Item Descriptions or have other forms of organizationally-mandated content. An example organization of an SRS is as follows:

Introduction
Purpose
Definitions
System overview
References
Overall description
Product perspective
System Interfaces
User Interfaces
Hardware interfaces
Software interfaces
Communication Interfaces
Memory Constraints
Operations
Site Adaptation Requirements
Product functions
User characteristics
Constraints, assumptions and dependencies
Specific requirements
External interface requirements
Functional requirements
Performance requirements
Design constraints
Standards Compliance
Logical database requirement
Software System attributes
Reliability
Availability
Security
Maintainability
Portability
Other requirements

Project Management Plan (PMP)

A project management plan is a formal, approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one or more subsidiary management plans and other planning documents. The objective of a management plan is to define the approach to be used by the Project team to deliver the intended project management scope of the project. The project manager creates the plan following input from the project team and key stakeholders. The plan should be agreed and approved by at least the project team and its key stakeholders.


[On a side note: In many organizations the term "project management plan" and "project schedule" are often used interchangeably. If this is the case in your organization, then please make sure that you understand that for the PMPExam, these are two distinctly different documents.

Project Management Plan as the process of documenting the actions necessary to define, prepare, integrate, and coordinate all subsidiary plans. It defines how the project is executed, monitored and controlled, and closed. The management plan content will vary depending upon the application area and complexity of the project. It is developed through a series of integrated processes until project closure. This process results in a project plan that is progressively elaborated by updates and controlled and approved through the Perform Integrated Change Control process.


The plan typically covers topics used in the project execution system and includes the following main aspects:


* Scope Management

* Schedule Management

* Financial Management

* Quality Management

* Resource Management

* Communications management

* Project Change Management

* Risk Management

* Procurement Management


It is good practice and mostly required by large consulting and professional project management firms, to have a formally agreed and version controlled plan approved in the early stages of the project, and applied throughout the project. Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment.

Differences Between ISNULL() and COALESCE()

ISNULL() Function
The ISNULL() function is used to replace NULL with the specified replacement value. This function contains only two arguments.

Syntax
ISNULL (check_exp, change_value)

Coalesce() Function
The Coalesce() function returns the first non-null value among its arguments. This function doesn't limit the number of arguments, but they must all be of the same data type.

Syntax
COALESCE ( expression [ ,...n ] ) 
COALESCE() function is equivalent to the following CASE expression.CASE
WHEN (exp1 IS NOT NULL) THEN exp1
WHEN (exp2 IS NOT NULL) THEN exp2
...
ELSE expN

1.  The COALESCE() function is based on the ANSI SQL standard whereas ISNULL function is a Transact-SQL function.

2.  An expression involving ISNULL with non-null parameters is considered to be NOT NULL, while expressions involving COALESCE with non-null parameters is considered to be NULL.

3. The ISNULL() function contains only two parameters. The COALESCE() function contains multiple parameters. If we use more than two parameters with the ISNULL function then we must use nested ISNULL functions.

Example
ISNULL() function:
SELECT ISNULL(NULL, ISNULL(NULL, 'Hello'))

COALESCE() function:
SELECT COALESCE(NULL, NULL, 'Hello')

4. The ISNULL() function looks at the first value and the second parameter value is automatically limited to that length but COALESCE() does not have this restriction.
Example
declare @test varchar(3)
select isnull(@test, 'ABCD') AS ISNULLResult
select coalesce(@test, 'ABCD') AS coalesceResult

5. The ISNULL() function contains various types of parameters. The COALESCE() function doesn't limit the number of arguments, but they must all be of the same data type.
Example
ISNULL() function:
DECLARE @a VARCHAR(5)='Hello',
@b INT =5
SELECT ISNULL(@a, @b) AS ISNULLResult