CMMi – Requirement Development Part – III

So, what next…well lot of things still left in requirement development, and I guess you are enjoying every bit of this.

After coming up and deciding on every requirement, the components, and associating requirement with product component next in line for us is:

Now we need to analyze and validate our requirement, which give us variety of other question to answer:

How are Operational concepts and scenarios developed and maintained?

This would mean: During the requirement development phase, you should come up with various scenarios, all these scenarios should be augmented with quality attributes.

A scenario is typically a sequence of events that may occur during the use of the product or project, which is used to make needs of the stakeholders as ‘Explicit’. An operational concept for a product usually depends on both the design solution and the scenario.

You need to have FSD (‘Functional Specification Document’) at this stage.

Requirement Development - Engineering

Requirement Development - Engineering

The next question that arise at this level is:

How you define the functional requirements?

Definition of functionality, which is also referred to as “functional analysis,” is the description of what the product is intended to do. In simple terms what do you mean by Functional analysis, which will term as the “Required” functionality of the project / product. The definition of functionality can include the actions, sequence of those actions, inputs required for those actions, outputs, or other information that communicates the manner in which the product will be used.

You need to have FSD (‘Functional Specification Document’) at this stage. <<To be specific you should focus on IDD (Interface description document), and ICD (Interface Control document) which are part of your FSD>>>

Once we have functional specification document, next question we should ask from ourselves is:

How do you analyze whether the requirements are necessary and sufficient?

At this stage we analyze the requirement. We look at the design and talk about feasibility from requirement perspective, or which requirement affects feasibility.

You need to have Requirement Defect Report at this stage, supported by peer reviews comments, proposed requirement changes which will eventually have a change log.

Once we have identified and analyzed the requirement, this is the time for asking few more questions:

How do you analyze whether the requirements balances the user needs and constraints?

Make sure you’ve result of all the conversation, and proof of records showing analysis and negotiations of tradeoffs between requirement, cost, and schedule etc.

And now the last but not the least question:

How do you validate the requirement that your product will meet the user’s needs?

Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

At this stage be ready with Design docs, Simulators, Analysis etc.

CMMi – Project Planning – Identify Risk

Risk: One of the most important component for any of the Project Planning related activities.

Does this scenario seem familiar : “Ah, you know what we planned that we will be able to create this webservice in a week’s time, and suddenly this the Dev is not available!” So? You planned for this…right, this is a risk? Yeah…Ummm…you know what, I didn’t…!!! What???

Well this must be familiar with many of us under various circumstances as we move ahead in our projects. Hence Identifying and analyzing the project risks is a massive opportunity for us as a project manager  to make sure that the deliverable are running on time. So, How do we do this?

Now this is where things gets slightly trickier as we move! The identification of risk involves following two aspects:

  • Monitoring the Risk (This is part of PMC – Project Monitoring and Control)
  • Risk Management (This is part of Risk Management – RSKM)
English: The diagram above represents a generi...

Image via Wikipedia

We will talk about these in near future, but for the sake of this discussion let’s talk about why Risk identification is necessary?

Risks are identified or discovered and analyzed to support project planning. Now this is an exercise which should take place across all plans that affect the project to ensure that there is an interface among all relevant stakeholders on identified risks.

Remember this : While doing project planning, the project plan is supported by various documents, and hence Identifying the Risk is a filler for Project Planning, which means that this filler itself has a procedure to be followed.

  1. We should identify the Risks.
  2. Analysis of the risk, and determination of the impact, probability of occurrence
  3. Giving priority to the risks

Let’s talk about how do we identify the risks:

Examples of risk identification and analysis tools may include the following:

  • Risk assessments
  • Checklists
  • Structured interviews
  • Brainstorming
  • Process, project, and performance models
  • Cost models
Here is the model associated with Risk Management:
CMMI Project Planning – Meta-data model

Image via Wikipedia

Once this is done, then we document the risk, and review and obtain the stakeholders approval and agreement.

Once you’re done with doing Risk identification, you should have answers to the following questions:

How are Risks identified and analyzed?

The answer for this should be:

Well, we have a list of identified risks, and we call this a risk watch list, a risk plan, which has got documented analysis of the risks, and very importantly we do have a Standard set of typical risks for specific type of  projects.

We will be talking about other aspects of Project Planning and probably by the end of this week you all should have better understanding of how to do Project Planning. Cheers!

CMMi – Project Planning

From today onwards, we will see what are Process areas (Like Project Planning, Requirement Management etc.) and how we are going to get these implemented with in our Organization.

Let’s understand this:

At maturity level 2, the projects have

  • ensured that processes are planned and executed in accordance with policy;
  • the projects employ skilled people who have adequate resources to produce controlled outputs;
  • involve relevant stakeholders;
  • been monitored, controlled, and reviewed;
  • been evaluated for adherence to their process descriptions.

This is very important to understand that Maturity level 3 contains all the elements of Maturity level 2 and additional for level 3.

Now as we understand the maturity level 2 have got defined policies, resources, stakeholders, and evaluation procedure. This is so very cool…so far…

Also at maturity level 2, the status of the work products (Example will be Requirement documents, Functional Specs time sheets etc.) are visible to management at defined points (e.g., at major milestones , at the completion of major tasks).

Product

—A work product that is intended for delivery to a customer or end user. The form of a product can vary in different contexts. (See also “customer,” “product component,” “service,” and “work product.”)

Work product

—A useful result of a process. This can include files, documents, products, parts of a product, services, process descriptions, specifications, and invoices. A key distinction between a work product and a product component is that a work product is not necessarily part of the product.
We intentionally are not following a step by step “Alphabetical flow” to understand all this. Best is to start with what we do daily in our life, that is planning. Most of us have been involved in Project Planning and associated activities with this, so let’s talk about the same:

But before we do, let’s see what all is contained within the project planning process i.e. PP as a process area:

Project Planning

Project Planning

Now while you are looking at this, let us explain a bit about the terminology:

SG: Specific Goals

SP: Special Practices

All rightie so all set! I am…Let’s get started….My first question to all of you:

How is WBS (Work Breakdown Structure) established.

How are changes to this are controlled.

How is it used?

Cheers 🙂

CMMi Process areas and mapping with Maturity levels

From CMMi Introduction and Maturity level understanding, we are all set to understand the process areas associated with every maturity level. And the jargons will be Process Areas (PAs). Uh ho!, another jargon, again processes and all?

Well don’t worry about this, we have lot to cover and we will on the way keep on explaining as to what these jargons are, for today lets see this section. As this is very important for all of us to understand about the processes, let’s focus on this only for today!

Level

Focus

Key Process Area

Result

5
Optimizing
Continuous Process Improvement
  • Organizational Innovation and Deployment
  • Causal Analysis and Resolution
Highest Quality /
Lowest Risk
4
Quantitatively Managed
Quantitatively Managed
  • Organizational Process Performance
  • Quantitative Project Management
Higher Quality /
Lower Risk
3
Defined
Process Standardization
  • Requirements Development
  • Technical Solution
  • Product Integration
  • Verification
  • Validation
  • Organizational Process Focus
  • Organizational Process Definition
  • Organizational Training
  • Integrated Project Mgmt (with IPPD extras)
  • Risk Management
  • Decision Analysis and Resolution
  • Integrated Teaming (IPPD only)
  • Org. Environment for Integration (IPPD only)
  • Integrated Supplier Management (SS only)
Medium Quality /
Medium Risk
2
Managed
Basic Project Management
  • Requirements Management
  • Project Planning
  • Project Monitoring and Control
  • Supplier Agreement Management
  • Measurement and Analysis
  • Process and Product Quality Assurance
  • Configuration Management
Low Quality /
High Risk
1
Initial
Process is informal and Adhoc Lowest Quality /
Highest Risk

CMMi – A crash course – Introduction to Dev 1.3

Capability and Maturity

CMMI is an acronym for “Capability Maturity Model Integrated.” The last word basically means that CMMI is a fusion of best practices from a number of different capability maturity models that were eventually combined into a single model that is reminicent of the CMM.

Maturity means that whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and perform accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation.

So there are three types of CMMi : Development, Acquisition, and Services. We at Tekriti are going for CMMi Dev Level 1.3

What holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge
of how to do things better.

We all have our problems associated in day-to-day activities, CMMi provides you a way to solve these issues by providing streamlined methods. We will discuss and learn about all this in a matter of time and with every session as we move ahead!

Let’s start talking by Maturity!

Levels of Maturity

Search for CMMI on the web, and you’ll find the five levels of CMMI:

  1. Performed. This is where everyone starts: Our company is making products and you’re earning money, so evidently you’re doing something right. But you’d have a hard time describing precisely how you’re doing it. Your project teams may be managing by the book, but they certainly can’t tell you which book. You’re performing, but you don’t really know why or how well. I mean if I ask you now, do you follow the processes, well you’ll say Aaannn….you know …no! Well I don’t buy your argument then…you’re following processes that is why you ‘re here speaking with us and doing what you are “Supposed” to do :).
  2. Managed. At this level, your company’s project teams are well-functioning according to ordered methods that are well-documented. There’s no guarantee that one project team is managed by the same methods as another team, however, and each time a new project is started, you may find the team reinventing the wheel.
  3. Defined. This is where all of the methods are well-defined across your company, and all of the projects perform according to those methods rather than figuring them out on their own. And this is what we are targeting at Tekriti!
  4. Quantitatively Managed. The projects perform according to the same methods as at the “defined” level, but at the quantitatively managed level the projects will have plenty of hard data to back their decisions and performance. This enables the projects to make sound decisions and quickly identify deviations, and it obviously requires that the defined processes have been followed for a while.
  5. Optimizing. At the last level, the organization continuously focuses on optimizing its work processes. This requires plenty of statistics from the quantitatively managed level.

Since all companies start at level 1, the CMMI model doesn’t state any requirements below level 2. Level 2 is concerned with project planning and processes for managing projects, requirements, and suppliers, and introduces “support” processes that are vital for further maturity: configuration management, metrics and analysis, and quality assurance.

Level 3 introduces a large number of processes. Risk management is added to the project management toolbox, and the project management processes are expanded with processes for integrating separated teams in the management. This level also introduces three processes aimed at defining processes at company level rather than project level. Level 3 also involves processes for constructing products according to well-developed requirements, and for verifying and validating the products.

Level 4 adds processes for assessing objectively how the various processes perform, and for managing according to objective metrics and statistics.

Finally, level 5 provides processes for maintaining an organizational environment for innovation and for identifying and correcting the cause of problems and inefficiencies in the processes.

Well…this is it for today….will catch you soon with other sessions…Happy “Processing” 🙂 Cheers!