Note:- This topic is meant specially for .NET programmers who are looking for better positions rather than simple programmer jobs. Project management is not everybody’s cup of tea. We have seen 10 year good decent technical guys do not get this position easily. But street smart programmers with average technical guys do really well

Click ⭐if you like the project. Pull Request are highly appreciated. Follow me @kansiris87 for technical updates.

Applying knowledge, skills, tools, techniques in project and deliver project deliverables is a short definition of project management. It is basically managing project time, cost, and scope.

Note:- It’s a tricky question, to know how much depth you have regarding costing of projects. Normally in initial stage of projects (requirement and design phase) the cost is very less (as you need maximum business analyst and architecture), but as the project proceeds cost factor starts increasing. The cost is maximum in coding phase (this is where you require programmers, project leads and project manager). Later when the project is in testing and acceptance phase cost is less, as we will need only one or two programmers for removing bugs, than the whole team.

A stakeholder is anyone who has something to gain or lose as a result of the completion failure of this project or phase Note:- It’s not only the end customer the stakeholder. Project managers, Project Lead, even programmers, testing department etc. are stake holders of project. So during project management interview whenever you refer stake holders be clear about the terminology.

Twist: - How many phases are there in software project? There are five stages of any project initiating, planning, executing, controlling, and closeout..

Never say that risk is high through out the project. Risk is high at the start of projects, but by proper POC (Proof of concept), risk is brought in control. Good project managers always have proper risk mitigation plan at the start of project. As the project continues one by one, risks gets eliminated thus bringing down the risk.

Note:- This questions is asked to test that as a project manager do you have a know how of all the project life cycles.In PMP (Project management plan) you have to specify saying which software development model you will follow. Definitely depending on client and project scenarios it’s the project manager’s responsibility to choose a development cycle.

SDLC (System Development Life Cycle) is overall process of developing information systems through multi stage process systems from investigation of initial requirements through analysis, design, implementation, and maintenance. The days are gone when one COBOL programmer used to analyze, test, and implement software systems. Systems have become complex, huge team members are involved, architects, analyst, programmers, testers, users etc. To manage this number of SDLC models have been created.

Following are popular models, which are listed:- ​ Waterfall Model. ​ Spiral Model. ​ Build and Fix model. ​ Rapid prototyping Model. ​ Incremental Model.​ ​ This section we will go into depth of different SDLC models.

Water Fall Model

This is the oldest model. It has sequence of stages; output of one stage becomes input of other. Following are stages in Waterfall model:- • System Requirement: This is initial stage of the project where end user requirements are gathered and documented. • System Design: In this stage detail requirements, screen layout, business rules, process diagram, pseudo code, and other documentations are prepared. This is first step in technical phase. • Implementation: Depending on the design document, actual code is written here. • Integration and Testing: All pieces are brought together and tested. Bugs are removed in this phase. • Acceptance, Installation and Deployment: This is final stage where software is put in production and runs actual business. • Maintenance: This is least glamorous phase, which runs forever. Code Changes, correction, addition etc are done in this phase. Waterfall is suited for low risk in areas of User Interface and performance requirements, but high risk in budget and schedule predictability and control. Waterfall assumes that all requirements can be specified in advance. ut unfortunately, requirement grows and changes through various stages, so it needs feedback from one stage to other.

Spiral Model

Spiral Model removes the drawback of waterfall model, by providing emphasis to go back and reiterate earlier stages a number of times as project progresses. On broader level, it is a series of short waterfall cycles, each producing an early prototype representing a part of entire project. It also helps demonstrate a Proof of Concept at early software life cycle. Build and Fix Model This is the way free-lancers work Write some code and keep modifying it until the customer is happy. This approach can be quite dangerous and risky.

Rapid Prototyping Model

This model is also called as Rapid Application Development. The initial emphasis is on creating prototype that look and acts like the desired product. Prototype can be created by using tools, which is different from those used for final product. Once the prototype is approved, its discarded and real software development is started from scratch. The problem with this model is that sometimes the prototype moves ahead to become the final live product, which can be bad from design point of view. It is a effective model but can have higher costing than other models as you require programmers during the initial phase of the software cycle.

Incremental Model

In this model, we divide products into builds, where section of product are created and tested separately. Here errors are found in requirement phase itself, user feedback is taken for each stage and code is tested after it is written.

Project Management triangle is depicted as Cost, Schedule and scope. These three aspects form the sides of triangle and the customer is the center point. As customer is always concerned about Cost, Scope and Schedule, so in order to get customer satisfaction project manager should deliver all scope in propose schedule and cost. If we want to disturb any one of the legs then the other two legs get affected. Example if customer increases the scope then other two sides of the triangle also get affected a lot. Note:- During project management interviews it’s rare that you will be asked directly about constraint triangle. But when you are asked about what are the main factors that affect customer satisfaction you can refer this triangle.

It defines a logical closure of any deliverable or cycle. Example you have completed the requirement phase with sign off from the client on the requirement document. So you put a baseline and say that further any changes to this document are change request. Versioning of source code is one type of baseline.

Effort Variance = (Actual effort – Estimated Effort) / Estimated Effort. PMP document forms the bible of a project. It has normally these sections:- Project summary Project organization hierarchy WBS / Activity list to be performed with schedule Work product identification (In short who will do what) Project schedule (GANNT chart or PERT chart). Estimated Cost and completion. Project requirements. Risk identification. Configuration management section. Quality section. Action Item status.

There are many techniques available for estimating a project:- ​ Function points ​ Use Case points ​ WBS etc etc.

The basic purpose of CAR is to analyze all defects, problems, and good practices/positive triggers in projects, perform a root cause analysis of the same, identify respective corrective and preventive actions, and track these to closure. The advantage of CAR is that root causes are scientifically identified and their corrective and preventive actions are carried out. CAR needs to be performed at project initiation, all phase and project ends and on a monthly basis. Fishbone diagram is one of the ways you can do CAR.

Decision Analysis and Resolution is to analyze possible decisions using a formal evaluation process that identifies alternatives against established criteria.

Example in a project you are said to use third party tools so you will not depend on only one tool but evaluate three to four more tools so that in case of problems you have alternatives. This is called as DAR

Twist:- What is Ishikawa diagram ? Dr. Kaoru Ishikawa invented the fishbone diagram. Therefore, it can be also referred as Ishikawa diagram.

Fishbone diagram is an analysis diagram, which provides a systematic way of looking at effects and the causes that create or contribute to those effects. Because of the function of the fishbone diagram, it may be referred to as a cause- and-effect diagram. The design of the diagram looks much like the skeleton of a fish. Therefore, it is often referred to as the fishbone diagram.

Fishbone diagram helps in categorizing potential causes of problems or issues in an orderly way and in identifying root causes.

Below is a sample fish bone diagram, which shows why a project dead line was not met. The middle arrow is the main problem “Deadline not met”. Then we start analyzing other problems, which has led to this problem. Example There is client problem -- as he is always changing the requirement -- this is caused because the company did not sign the SRS --- and this happened as proper project management procedures where not at place. So to solve this problem we either appoint a project manager or give training on project management to senior team members.

Twist: - What is 80/20 principle? Pareto principle also paraphrased as 80/20 principle is simple effective problem tackling way in management. It says that 20% of your problems lead to other 80 % of problems. So rather than concentrating on the 80% of problem if you concentrate on 20% of problems you can save lot of trouble. So in pareto you analyze the problems and only concentrate on 20% of your vital problems. In projects, the first 10% and the last 10% of project form the vital part of project.

Normally change request are handled by preparing an Impact analysis document and then doing re-estimation. Example you have an on going project, which has a customer table. Now customer wants to also have addresses assigned to it. Therefore, you normally raise a change request and then do an impact analysis of the same. Depending on the impact, you estimate and let know the client about the financial aspect of the project. Once client sign off or the upper management agrees to the change request you move ahead with implementation.

Internal change request are not normally billable change request, it has no financial gains from the client. Example your architecture division of your company has said in mid of the project that the architecture has to be modified. Definitely this has nothing to do with the client, but you make changes to the project so this is called as Internal change request.

UTP (Unit Test Plan) are done at smallest unit level or stand-alone mode. Example you have Customer and invoicing module. So you will do test on Customer and Invoice module independently. But later when we want test both customer and invoice in one set we integrate them and test it. So that’s is SITP (System Integration Test Plan)

UTP can be done using NUNIT. Unit testing is done normally by developers and System testing is done normally by testing department in integration mode.

Many companies have there own software defined. There are many project management software available at this moment in market but this can vary from company to company

Worst it can very from project to project. But Microsoft project is the most used software at this moment. So just brush your skills on Microsoft project, its used heavily across industry.

Twist: - What metrics will you look at in order to see the project is moving successfully? Most metric sets deal with a variation of these attributes and are chosen to help project managers gain insight into their product (size, software quality, and rework), process (rework, software quality), and project (effort, schedule).

But below is a broader classification:-

Project Management Metrics

Milestone metrics

number of milestones

number of proved requirements per milestone

controlling level metrics

Risk metrics

probability of resources availability

probability of the requirements validity

risk indicators (long schedules, inadequate cost estimating,excessive paperwork, error-prone modules, canceled projects, excessive schedule pressure, low quality, cost overruns, creeping user requirements, excessive time to market, unused or unusable software, unanticipated acceptance criteria, hidden errors) application risk metrics

Workflow metrics

walkthrough metrics

traceability metrics

variance metrics

Controlling metrics size of control elements structure of control elements documentation level tool application level

Management database metrics data quality metrics management data complexity data handling level (performance metrics) visualization level safety and security metrics

Quality Management Metrics

Customer satisfaction metrics characteristics size metrics characteristics structure metrics empirical evaluation metrics data presentation metrics

Review metrics number of reviews in the process review level metrics review dependence metrics review structure metrics review resources metrics

Productivity metrics actual vs. planned metrics performance metrics productivity vs. quality metrics

Efficiency metrics time behavior metrics resources behavior metrics actual vs. Planned metrics

Quality assurance metrics quality evaluation metrics error prevention metrics measurement level data analysis metrics

Configuration Management Metrics

Change control metrics size of change dependencies of changes change interval metrics revisions metrics

Version control metrics number of versions number of versions per customer version differences metrics releases metrics (version architecture) data handling level

Note:- Following are some questions who do not have a specific answer and vary from person to person or are out of the scope of book. This book will list down the questions just go through them.

Twist: - Two of your resources have conflicts between them how would you sort it out? In such kind of question, they want to see your delegation skills. The best answer to this question is a job of a project manager is managing projects and not problems of people, so I will delegate this work to HR or upper authority.... Thanks to my Project Manager for this beautiful answer.

Black box testing is also termed as functional testing. It ignores how the internal functionality of a system works and depends only what are the outputs on specified inputs. Source code availability is not an important in back box testing. Black box testing is mostly to ensure that it meets the user functionality.

According to IEEE, standards following are characteristics of Black box testing:-

​ “ Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions,”

​ “Testing conducted to evaluate the compliance of a system or component with specified functional requirements.”

One of the way of doing black box testing is Manual testing what the tester performs. For instance, you can install the application on a machine and tester starts testing is a type of black box testing. In our case the tester is completely unaware of the how the program logic flows and how its coded etc.

White box testing is opposite to Black box it requires internal know how of how the logic flows. As this testing needs know how of the internal structure it can only be done programmers. Unit testing is one of the ways of doing White box testing in which programmers use NUNIT or JNUIT to test each class individually. White box testing can be done by programmer by either stepping through the code or testing the classes and components in isolation.

Unit testing is also termed as Component testing. Unit testing ensures that reliable program unit meets their requirements. Unit testing is normally conducted by programmer under the supervision of the project lead or the team Lead. Main objective of this testing is to test each unit in isolation and individually. This is done by knowing what the inputs to the unit are and what the expected outputs for the same. Unit testing is a white box activity. Unit test normally comes in the implementation phase of the project.

For instance in the below figure we are trying to do unit testing on the customer class. So we create the object of Customer class assign “CustomerCode” and “Age” property and check for the response. For instance, in this condition, we tried to pass a non-numeric value to the “Age” property and the class threw an error saying, “Age should be numeric”. So here the basic unit testing entity is your class.

However, unit testing is not limited to a component, object, or function. Therefore, definition of a unit testing will depend on the approach. Below are some examples of unit testing:-

​ Checkpoints in UI like tab orders, error messages, look and feel etc.

​ Class, object, component level testing as said previously.

In case of functional programming can be a simple method or function.

Logic testing for algorithms. Some projects can have some critical algorithm for instance some kind of custom sorting, security implementation etc. Therefore, that logic can be tested independently.

However, the general thumb rule of what is Unit in Unit testing is that the module self-contained and by itself.

Assembly testing goes one-step ahead than unit testing. It demonstrates that can the modules interact in a correct, stable, and proper manner as defined by the functional specifications provided by the client. Assembly testing is Black box testing style and also called as Integration testing. For instance in the above unit test of the “Customer” class, testing was done in isolation. But in actually the “Customer” class is not going to be stand alone rather it will be used more in conjunction with the “Product” class and also will have UI to do the same. So in short, the “Customer” class will work with two more entity one is the “UI” and the other is the “Product” class. So normally, assembly testing is done through UI but not necessarily.

The above figure defines a simple scenario for integration testing. The same “Customer” class is now tested with the “UI” and “Product” to see if the interaction between them matches according to functional specifications.

Regression testing ensures that application function properly even if there are changes or enhancements to system. For instance you change the “Product” class still you will run all the test cases for “Product” , “Customer” and “UI” just to make sure that any changes in “Product” class does not affect interaction with other entities. So you will see when testers do a regression testing they run all the scripts to ensure that nothing has been affected.

V model maps the type of test to the stage of development in a project. V model stressed the point that every phase in project should have a test phase also.

Unit Testing

Starting from the bottom the first test level is "Unit Testing". It involves checking that each feature specified in the "Component Design" has been implemented in the component.

In theory, an independent tester should do this, but in practice, the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co- operating with other parts of the system, which may not have been built yet. To overcome this, the developer either builds, or uses special software to trick the component into believe it is working in a fully functional system. This test maps with the implementation phase and normally developers do the unit testing for the project.

Integration Testing

As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests independently, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers.

Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components.

The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system. Integration test cases are written when design documents are written.

System Testing

Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence, System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact, it is one giant component.

System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements, these may include the following types of testing for the non-functional requirements:

​ Performance - Are the performance criteria met?

​ Volume - Can large volumes of information be handled?

​ Stress - Can peak volumes of information be handled?

​ Documentation - Is the documentation usable for the system?

​ Robustness - Does the system remain stable under adverse circumstances?

There are many others, the need for which is dictated by how the system is supposed to perform. System test plans are written when the specification of the project is going on.

Acceptance Testing

Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus:

Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested.

The customer should always do acceptance testing and not the developer. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It is like getting a green flag from the customer that the software is up to the expectation and ready to be used. Acceptance test plans are written during the requirement phase of the project. In real scenario these test plans should be given by the end customer.

Left to the readers

Left to the readers

The way in which code reviews are done change from person to person and also company to company. However, the normally when a project is started project people define their architecture, coding standards etc in their design document. So before starting the code review you will have go through the standards defined in the project. Reviews are done by two methodologies one is peer review and the other is by external part who is not the member of the project. So we give the standard document to the reviewer he checks it , gives his perspective and logs a review to the development. If the review is critical then the development team can close it or they can wave it off.

It is a collection of instructions an organization can follow with the purpose to gain better control over its software development process.

There are five levels of the CMM. According to the SEI,

Level 1 – Initial

At maturity level 1, processes are usually ad hoc and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.

Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.

Level 2 – Repeatable

At maturity level 2, software development successes are repeatable. The organization may use some basic project management to track cost and schedule.

Process discipline helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).

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.

Level 3 – Defined

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization has set of standard processes, which is the basis for level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.

The organization’s management establishes process objectives based on the organization is set of standard processes and ensures that these objectives are appropriately addressed.

A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

Level 4 – Managed

Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Sub processes are selected that significantly contribute to overall process performance. These selected sub processes are controlled using statistical and other quantitative techniques.

A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Level 5 – Optimizing

Maturity level 5 focuses on persistently improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization set of standard processes are targets of measurable improvement activities.

Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.

Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.

A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.

Note: - I am sure during interview specially the SQA guys expect all the different levels of CMMI to be in mind. So below is the figure, which will help you remembering the same.

CMMI contains 25 key process areas which organization can follow to adapt CMMI.

​ Causal Analysis and Resolution (CAR)

​ Configuration Management (CM)

​ Decision Analysis and Resolution (DAR)

​ Integrated Project Management (IPM)

​ Integrated Supplier Management (ISM)

​ Integrated Teaming (IT)

​ Measurement and Analysis (MA)

​ Organizational Environment for Integration (OEI)

​ Organizational Innovation and Deployment (OID)

​ Organizational Process Definition (OPD)

​ Organizational Process Focus (OPF)

​ Organizational Process Performance (OPP)

​ Organizational Training (OT)

​ Product Integration (PI)

​ Project Monitoring and Control (PMC)

​ Project Planning (PP)

​ Process and Product Quality Assurance (PPQA)

​ Quantitative Project Management (QPM)

​ Requirements Development (RD)

​ Requirements Management (REQM)

​ Risk Management (RSKM)

​ Supplier Agreement Management (SAM)

​ Technical Solution (TS)

​ Validation (VAL)

​ Verification (VER)

The method by which company wants to adapt to CMMI are termed as representation. So either organization can adapt for staged or continuous representation.

In the continuous representation, process areas are organized by functional area. For example, a company interested to improve its Project Management capability would focus on IPM, ISM, IT, PMC, PP, QPM, RSKM and SAM.

Process Management

OID - Organizational Innovation and Deployment

OPD - Organizational Process Definition

OPF - Organizational Process Focus

OPP - Organizational Process Performance

OT - Organizational Training

Project Management

IPM - Integrated Project Management

ISM - Integrated Supplier Management

IT - Integrated Teaming

PMC - Project Monitoring and Control

PP - Project Planning

QPM - Quantitative Project Management

RSKM - Risk Management

SAM - Supplier Management Agreement

Engineering

PI - Product Integration

REQM - Requirements Management

RD - Requirements Development

TS - Technical Solution

VAL - Validation

VER - Verification

Support

CAR - Casual Analysis and Resolution

CM - Configuration Management

DAR - Decision Analysis and Resolution

MA - Measurement and Analysis

OEI - Organizational Environment for Integration

PPQA - Process and Product Quality Assurance

Staged representation

While in staged representation, the concept of levels comes in to picture. In the staged representation process areas are organized by organizational maturity level. For example, a company interested to obtain a Maturity Level 2 rating would require company processes covering all of the Maturity Level 2 process areas.

Maturity Levels 2

CM - Configuration Management

MA - Measurement and Analysis

PMC - Project Monitoring and Control

PP - Project Planning

PPQA - Process and Product Quality Assurance

REQM - Requirements Management

SAM - Supplier Management Agreement

Maturity Level 3

DAR - Decision Analysis and Resolution

IPM - Integrated Project Management

ISM - Integrated Supplier Management

IT - Integrated Teaming

OEI - Organizational Environment for Integration

OPD - Organizational Process Definition

OPF - Organizational Process Focus

OT - Organizational Training

PI - Product Integration

RD - Requirements Development

RSKM - Risk Management

TS - Technical Solution

VAL - Validation

VER - Verification

Maturity Level 4

QPM - Quantitative Project Management

OPP - Organizational Process Performance

Maturity Level 5

CAR - Casual Analysis and Resolution

OID - Organizational Innovation and Deployment

Note: - No one is going to ask such a question. But they would like to know at least the purpose of each KPA. Second they would like to know what you did to attain compatibility to these process areas. For instance you say that you did Organizational Process Definition. They would like to know how you did it. For instance you can justify it by saying that you made standard documents for coding standards which was then followed at the organization level for reference. Normally every one follows process it’s only that they do not know. So try to map the KPA to the process what you follow. The only purpose to paste all the KPA is if in case you are looking for some higher positions in bug companies they really expect you to speak in term of KPA rather than generic term. This whole stuff can be like a quick reference for you before entering the interview room.

Each process area is defined by a set of goals and practices. There are two categories of goals and practices: generic and specific. Generic goals and practices are a part of every process area. Specific goals and practices are specific to a given process area. A process area is satisfied when company processes cover all of the generic and specific goals and practices for that process area. Generic goals and practices are a part of every process area.

GG 1 Achieve Specific Goals

GP 1.1 Perform Base Practices

GG 2 Institutionalize a Managed Process

GP 2.1 Establish an Organizational Policy

GP 2.2 Plan the Process

GP 2.3 Provide Resources

GP 2.4 Assign Responsibility

GP 2.5 Train People

GP 2.6 Manage Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and Control the Process

GP 2.9 Objectively Evaluate Adherence

GP 2.10 Review Status with Higher Level Management

GG 3 Institutionalize a Defined Process

GP 3.1 Establish a Defined Process

GP 3.2 Collect Improvement Information

GG 4 Institutionalize a Quantitatively Managed Process

GP 4.1 Establish Quantitative Objectives for the Process

GP 4.2 Stabilize Subprocess Performance

GG 5 Institutionalize an Optimizing Process

GP 5.1 Ensure Continuous Process Improvement

GP 5.2 Correct Root Causes of Problems

Process areas

The CMMI contains 25 key process areas indicating the aspects of product development that are to be covered by company processes. Casual Analysis and Resolution (CAR)

A Support process area at Maturity Level 5 Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and other problems and take action to prevent them from occurring in the future.

Specific Practices by Goal

SG 1 Determine Causes of Defects

SP 1.1-1 Select Defect Data for Analysis SP 1.2-1 Analyze Causes

SG 2 Address Causes of Defects

SP 2.1-1 Implement the Action Proposals

SP 2.2-1 Evaluate the Effect of Changes

SP 2.3-1 Record Data

Configuration Management (CM)

A Support process area at Maturity Level 2 Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Specific Practices by Goal

SG 1 Establish Baselines

SP 1.1-1 Identify Configuration Items

SP 1.2-1 Establish a Configuration Management System

SP 1.3-1 Create or Release Baselines

SG 2 Track and Control Changes

SP 2.1-1 Track Change Requests

SP 2.2-1 Control Configuration Items

SG 3 Establish Integrity

SP 3.1-1 Establish Configuration Management Records

SP 3.2-1 Perform Configuration Audits

Decision Analysis and Resolution (DAR)

A Support process area at Maturity Level 3 Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

SG 1 Evaluate Alternatives

SP 1.1-1 Establish Guidelines for Decision Analysis

SP 1.2-1 Establish Evaluation Criteria

SP 1.3-1 Identify Alternative Solutions

SP 1.4-1 Select Evaluation Methods

SP 1.5-1 Evaluate Alternatives

SP 1.6-1 Select Solutions

Integrated Project Management (IPM)

A Project Management process area at Maturity Level 3 Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes.

Specific Practices by Goal

SG 1 Use the Project's Defined Process

SP 1.1-1 Establish the Project's Defined Process

SP 1.2-1 Use Organizational Process Assets for Planning Project Activities

SP 1.3-1 Integrate Plans

SP 1.4-1 Manage the Project Using the Integrated Plans

SP 1.5-1 Contribute to the Organizational Process Assets

SG 2 Coordinate and Collaborate with Relevant Stakeholders

SP 2.1-1 Manage Stakeholder Involvement

SP 2.2-1 Manage Dependencies

SP 2.3-1 Resolve Coordination Issues

SG 3 Use the Project's Shared Vision for IPPD

SP 3.1-1 Define Project's Shared Vision for IPPD

SP 3.2-1 Establish the Project's Shared Vision

SG 4 Organize Integrated Teams for IPPD

SP 4.1-1 Determine Integrated Team Structure for the Project

SP 4.2-1 Develop a Preliminary Distribution of Requirements to Integrated Teams

SP 4.3-1 Establish Integrated Teams

Integrated Supplier Management (ISM)

A Project Management process area at Maturity Level 3 Purpose

The purpose of Integrated Supplier Management (ISM) is to proactively identify sources of products that may be used to satisfy the project's requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship.

Specific Practices by Goal

SG 1 Analyze and Select Sources of Products

SP 1.1-1 Analyze Potential Sources of Products

SP 1.2-1 Evaluate and Determine Sources of Products

SG 2 Coordinate Work with Suppliers

SP 2.1-1 Monitor Selected Supplier Processes

SP 2.2-1 Evaluate Selected Supplier Work Products

SP 2.3-1 Revise the Supplier Agreement or Relationship

Integrated Teaming (IT)

A Project Management process area at Maturity Level 3 Purpose The purpose of Integrated Teaming (IT) is to form and sustain an integrated team for the development of work products.

Specific Practices by Goal

SG 1 Establish Team Composition

SP 1.1-1 Identify Team Tasks

SP 1.2-1 Identify Needed Knowledge and Skills SP 1.3-1 Assign Appropriate Team Members SG 2 Govern Team Operation

SP 2.1-1 Establish a Shared Vision

SP 2.2-1 Establish a Team Charter

SP 2.3-1 Define Roles and Responsibilities

SP 2.4-1 Establish Operating Procedures

SP 2.5-1 Collaborate among Interfacing Teams

Measurement and Analysis (MA)

A Support process area at Maturity Level 2 Purpose

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.

Specific Practices by Goal

SG 1 Align Measurement and Analysis Activities SP 1.1-1 Establish Measurement Objectives

SP 1.2-1 Specify Measures

SP 1.3-1 Specify Data Collection and Storage Procedures SP 1.4-1 Specify Analysis Procedures

SG 2 Provide Measurement Results

SP 2.1-1 Collect Measurement Data

SP 2.2-1 Analyze Measurement Data SP 2.3-1 Store Data and Results

SP 2.4-1 Communicate Results

Organizational Environment for Integration (OEI)

A Support process area at Maturity Level 3 Purpose

The purpose of Organizational Environment for Integration (OEI) is to provide an Integrated Product and Process Development (IPPD) infrastructure and manage people for integration.

Specific Practices by Goal

SG 1 Provide IPPD Infrastructure

SP 1.1-1 Establish the Organization's Shared Vision

SP 1.2-1 Establish an Integrated Work Environment

SP 1.3-1 Identify IPPD-Unique Skill Requirements

SG 2 Manage People for Integration

SP 2.1-1 Establish Leadership Mechanisms

SP 2.2-1 Establish Incentives for Integration

SP 2.3-1 Establish Mechanisms to Balance Team and Home Organization Responsibilities

Organizational Innovation and Deployment (OID)

A Process Management process area at Maturity Level 5

Purpose

The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization's processes and technologies. The improvements support the organization's quality and process-performance objectives as derived from the organization's business objectives. Specific Practices by Goal

SG 1 Select Improvements

SP 1.1-1 Collect and Analyze Improvement Proposals

SP 1.2-1 Identify and Analyze Innovations

SP 1.3-1 Pilot Improvements

SP 1.4-1 Select Improvements for Deployment

SG 2 Deploy Improvements

SP 2.1-1 Plan the Deployment areas

SP 2.2-1 Manage the Deployment

SP 2.3-1 Measure Improvement Effects

Organizational Process Definition (OPD)

A Process Management process area at Maturity Level 3 Purpose

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets. Specific Practices by Goal

SG 1 Establish Organizational Process Assets

SP 1.1-1 Establish Standard Processes

SP 1.2-1 Establish Life-Cycle Model Descriptions

SP 1.3-1 Establish Tailoring Criteria and Guidelines

SP 1.4-1 Establish the Organization's Measurement Repository

SP 1.5-1 Establish the Organization's Process Asset Library

Organizational Process Focus (OPF)

A Process Management process area at Maturity Level 3 Purpose The purpose of Organizational Process Focus (OPF) is to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization's processes and process assets. Specific Practices by Goal

SG 1 Determine Process Improvement Opportunities

SP 1.1-1 Establish Organizational Process Needs

SP 1.2-1 Appraise the Organization's Processes

SP 1.3-1 Identify the Organization's Process Improvements

SG 2 Plan and Implement Process Improvement Activities

SP 2.1-1 Establish Process Action Plans

SP 2.2-1 Implement Process Action Plans

SP 2.3-1 Deploy Organizational Process Assets

SP 2.4-1 Incorporate Process-Related Experiences into the Organizational Process Assets

Organizational Process Performance (OPP)

A Process Management process area at Maturity Level 4 Purpose The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of the organization's set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization's projects. Specific Practices by Goal

SG 1 Establish Performance Baselines and Models

SP 1.1-1 Select Processes

SP 1.2-1 Establish Process Performance Measures

SP 1.3-1 Establish Quality and Process Performance Objectives

SP 1.4-1 Establish Process Performance Baselines

SP 1.5-1 Establish Process Performance Models

Organizational Training (OT)

A Process Management process area at Maturity Level 3 Purpose

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so that they can perform their roles effectively and efficiently.

Specific Practices by Goal

SG 1 Establish an Organizational Training Capability SP 1.1-1 Establish the Strategic Training Needs

SP 1.2-1 Determine Which Training Needs Are the Responsibility of the Organization SP 1.3-1 Establish an Organizational Training Tactical Plan

SP 1.4-1 Establish Training Capability

SG 2 Provide Necessary Training

SP 2.1-1 Deliver Training

SP 2.2-1 Establish Training Records

SP 2.3-1 Assess Training Effectiveness

Product Integration (PI)

An Engineering process area at Maturity Level 3 Purpose

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. Specific Practices by Goal

SG 1 Prepare for Product Integration

SP 1.1-1 Determine Integration Sequence

SP 1.2-1 Establish the Product Integration Environment

SP 1.3-1 Establish Product Integration Procedures and Criteria SG 2 Ensure Interface Compatibility

SP 2.1-1 Review Interface Descriptions for Completeness SP 2.2-1 Manage Interfaces

SG 3 Assemble Product Components and Deliver the Product

SP 3.1-1 Confirm Readiness of Product Components for Integration

SP 3.2-1 Assemble Product Components

SP 3.3-1 Evaluate Assembled Product Components

SP 3.4-1 Package and Deliver the Product or Product Component

Project Monitoring and Control (PMC)

A Project Management process area at Maturity Level 2 Purpose

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan.

Specific Practices by Goal

SG 1 Monitor Project against Plan

SP 1.1-1 Monitor Project Planning Parameters

SP 1.2-1 Monitor Commitments

SP 1.3-1 Monitor Project Risks

SP 1.4-1 Monitor Data Management

SP 1.5-1 Monitor Stakeholder Involvement

SP 1.6-1 Conduct Progress Reviews

SP 1.7-1 Conduct Milestone Reviews

SG 2 Manage Corrective Action to Closure SP 2.1-1 Analyze Issues

SP 2.2-1 Take Corrective Action

SP 2.3-1 Manage Corrective Action

Project Monitoring and Control (PMC)

A Project Management process area at Maturity Level 2 Purpose

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities. Specific Practices by Goal SG 1 Establish Estimates

SP 1.1-1 Estimate the Scope of the Project

SP 1.2-1 Establish Estimates of Work Product and Task Attributes SP 1.3-1 Define Project Life Cycle

SP 1.4-1 Determine Estimates of Effort and Cost

SG 2 Develop a Project Plan

SP 2.1-1 Establish the Budget and Schedule

SP 2.2-1 Identify Project Risks

SP 2.3-1 Plan for Data Management

SP 2.4-1 Plan for Project Resources

SP 2.5-1 Plan for Needed Knowledge and Skills

SP 2.6-1 Plan Stakeholder Involvement

SP 2.7-1 Establish the Project Plan

SG 3 Obtain Commitment to the Plan

SP 3.1-1 Review Plans that Affect the Project

SP 3.2-1 Reconcile Work and Resource Levels

SP 3.3-1 Obtain Plan Commitment

Process and Product Quality Assurance (PPQA)

A Support process area at Maturity Level 2 Purpose

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff nd management with objective insight into processes and associated work products.

Specific Practices by Goal

SG 1 Objectively Evaluate Processes and Work Products

SP 1.1-1 Objectively Evaluate Processes

SP 1.2-1 Objectively Evaluate Work Products and Services

SG 2 Provide Objective Insight

SP 2.1-1 Communicate and Ensure Resolution of Noncompliance Issues

SP 2.2-1 Establish Records

Quantitative Project Management (QPM)

A Project Management process area at Maturity Level 4 Purpose

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project's defined process to achieve the project's established quality and process-performance objectives.

Specific Practices by Goal

SG 1 Quantitatively Manage the Project

SP 1.1-1 Establish the Project's Objectives

SP 1.2-1 Compose the Defined Processes

SP 1.3-1 Select the Subprocesses that Will Be Statistically Managed

SP 1.4-1 Manage Project Performance

SG 2 Statistically Manage Subprocess Performance

SP 2.1-1 Select Measures and Analytic Techniques

SP 2.2-1 Apply Statistical Methods to Understand Variation

SP 2.3-1 Monitor Performance of the Selected Subprocesses

SP 2.4-1 Record Statistical Management Data

Requirements Development (RD)

An Engineering process area at Maturity Level 3 Purpose

The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product-component requirements.

Specific Practices by Goal

SG 1 Develop Customer Requirements

SP 1.1-1 Collect Stakeholder Needs

SP 1.1-2 Elicit Needs

SP 1.2-1 Develop the Customer Requirements SG 2 Develop Product Requirements

SP 2.1-1 Establish Product and Product-Component Requirements SP 2.2-1 Allocate Product-Component Requirements

SP 2.3-1 Identify Interface Requirements

SG 3 Analyze and Validate Requirements

SP 3.1-1 Establish Operational Concepts and Scenarios

SP 3.2-1 Establish a Definition of Required Functionality SP 3.3-1 Analyze Requirements

SP 3.4-3 Analyze Requirements to Achieve Balance SP 3.5-1 Validate Requirements

SP 3.5-2 Validate Requirements with Comprehensive Methods

Requirements Management (REQM)

An Engineering process area at Maturity Level 2 Purpose

The purpose of Requirements Management (REQM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products.

Specific Practices by Goal SG 1 Manage Requirements

SP 1.1-1 Obtain an Understanding of Requirements SP 1.2-2 Obtain Commitment to Requirements

SP 1.3-1 Manage Requirements Changes

SP 1.4-2 Maintain Bidirectional Traceability of Requirements

SP 1.5-1 Identify Inconsistencies between Project Work and Requirements

Risk Management (RSKM)

A Project Management process area at Maturity Level 3 Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Specific Practices by Goal

SG 1 Prepare for Risk Management

SP 1.1-1 Determine Risk Sources and Categories SP 1.2-1 Define Risk Parameters

SP 1.3-1 Establish a Risk Management Strategy SG 2 Identify and Analyze Risks

SP 2.1-1 Identify Risks

SP 2.2-1 Evaluate, Categorize, and Prioritize Risks SG 3 Mitigate Risks

SP 3.1-1 Develop Risk Mitigation Plans

SP 3.2-1 Implement Risk Mitigation Plans

Supplier Agreement Management (SAM)

A Project Management process area at Maturity Level 2 Purpose

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers for which there exists a formal agreement.

Specific Practices by Goal

SG 1 Establish Supplier Agreements

SP 1.1-1 Determine Acquisition Type

SP 1.2-1 Select Suppliers

SP 1.3-1 Establish Supplier Agreements

SG 2 Satisfy Supplier Agreements

SP 2.1-1 Review COTS Products

SP 2.2-1 Execute the Supplier Agreement

SP 2.3-1 Accept the Acquired Product

SP 2.4-1 Transition Products

Technical Solution (TS)

An Engineering process area at Maturity Level 3 Purpose

The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes either alone or in appropriate combination .

Specific Practices by Goal

SG 1 Select Product-Component Solutions

SP 1.1-1 Develop Alternative Solutions and Selection Criteria

SP 1.1-2 Develop Detailed Alternative Solutions and Selection Criteria SP 1.2-2 Evolve Operational Concepts and Scenarios

SP 1.3-1 Select Product-Component Solutions

SG 2 Develop the Design

SP 2.1-1 Design the Product or Product Component SP 2.2-3 Establish a Technical Data Package

SP 2.3-1 Establish Interface Descriptions

SP 2.3-3 Design Interfaces Using Criteria

SP 2.4-3 Perform Make, Buy, or Reuse Analyses SG 3 Implement the Product Design

SP 3.1-1 Implement the Design

SP 3.2-1 Develop Product Support Documentation

Validation (VAL)

An Engineering process area at Maturity Level 3 Purpose

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Specific Practices by Goal SG 1 Prepare for Validation

SP 1.1-1 Select Products for Validation

SP 1.2-2 Establish the Validation Environment

SP 1.3-3 Establish Validation Procedures and Criteria

SG 2 Validate Product or Product Components

SP 2.1-1 Perform Validation

SP 2.2-1 Analyze Validation Results

Verification (VER)

An Engineering process area at Maturity Level 3 Purpose

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements. Specific Practices by Goal

SG 1 Prepare for Verification

SP 1.1-1 Select Work Products for Verification

SP 1.2-2 Establish the Verification Environment

SP 1.3-3 Establish Verification Procedures and Criteria

SG 2 Perform Peer Reviews

SP 2.1-1 Prepare for Peer Reviews

SP 2.2-1 Conduct Peer Reviews

SP 2.3-2 Analyze Peer Review Data

SG 3 Verify Selected Work Products

SP 3.1-1 Perform Verification

SP 3.2-2 Analyze Verification Results and Identify Corrective Action

Sigma means deviation in Greek language. Deviation means how much variations exist in a set of data. For instance let’s say in a software maintenance project out of 100 defects 68 defects are rectified to the mark and remaining bounce back that means your bug fixing process is on “2 Sigma” level. I had described only from bug fixing perspective. But this can be applicable to any process organization.

Therefore, I should only have 3.4 defects in a million defects then I can say I am six sigma.

Six Sigma has two key methodologies DMAIC and DMADV. DMAIC is used to improve an existing business process. DMADV is used to create new product designs or process designs in such a way that it results in a more predictable, mature and defect free performance. DMAIC

Basic methodology consists of the following five phases:

​ Define- formally define the process improvement goals that are consistent with customer demands and enterprise strategy.

​ Measure- to define baseline measurements on current process for future comparison. Map and measure process in question and collect required process data.

​ Analyze- to verify relationship and causality of factors. What is the relationship? Are there other factors that have not been considered?

​ Improve - to optimize the process based upon the analysis using techniques like Design of experiments.

​ Control- setup pilot runs to establish process capability, transition to production and thereafter continuously measure the process and institute control mechanisms to ensure that variances are corrected before they result in defects. DMADV

Basic methodology consists of the following five phases:

​ Define- formally define the goals of the design activity that are consistent with customer demands and enterprise strategy.

​ Measures- to identify CTQs, product capabilities, production process capability, risk assessment, etc.

​ Analyze- to develops and design alternatives, creates high-level design and evaluates design capability to select the best design.

​ Design- to develop detail design, optimize design, and plan for design verification this phase may require simulations.

​ Verify-to design, setup pilot runs, implement production process and handover to process owners. This phase may also require simulations.

Attaining Six Sigma is team effort and can not be attained individually. Driving Six Sigma itself in an organization is huge project as it involves lot of mentoring and change of attitude of the current workers. So when an organization wants to drive the Six Sigma way they appoint persons with certain roles as defined below.

Executive Leadership includes CEO and other key top management team members. They are responsible for setting up a vision for Six Sigma implementation. They also empower the other role holders with the freedom and resources to explore new ideas for breakthrough improvements. Champions are responsible for the Six Sigma implementation across the organization in an integrated manner. The Executive Leadership draws them from the upper management. Champions also act as mentor to Black Belts.

Master Black Belts, identified by champions, act as in-house expert coach for the organization on Six Sigma. They devote 100% of their time to Six Sigma. They assist champions and guide Black Belts and Green Belts. Apart from the usual rigor of statistics, their time is spent on ensuring integrated deployment of Six Sigma across various functions and departments.

Black Belts operate under Master Black Belts to apply Six Sigma methodology to specific projects. They devote 100% of their time to Six Sigma. They primarily focus on Six Sigma project execution, whereas Champions and Master Black Belts focus on identifying projects/functions for Six Sigma.

Green Belts are the employees who take up Six Sigma implementation along with their other job responsibilities. They operate under the guidance of Black Belts and support them in achieving the overall results.

Note: - If you are going for project manager position then you will definitely need to prepare yourself in the area of estimation to a good extent. In the coming sections we will run through estimation related questions which are asked for project manager position. Estimation is a real weakness in software industry today. Different technologies, different company approaches, and custom processes followed by software companies it still does not have a standard. So, we will try to run through the most embraced estimation technologies by software industry.

Twist: - Define Elementary process in FPA?

FPA is breaking huge systems in to smaller pieces and analyzing them. Software application is combination of set of elementary processes. EP is smallest unit of activity that is meaningful to the user. EP must be self-contained and leave the application in a consistent state. Elementary process is not necessarily completely independent or can exist by itself. But it should leave the application in a consistent state.

There are two types of elementary process

​ Dynamic Elementary process

​ Static Elementary process

Dynamic elementary process moves data from internal application boundary to external application boundary or vice-versa.

Examples of dynamic elementary process: Input data screen where user inputs data in to application. Data moves from the input screen inside application.

Transaction exported in export files in XML or any other standard.

Display reports which can come from external application boundary and internal application boundary.

Static elementary process maintains data of application either inside application boundary or in external application boundary.

Examples of static elementary process: • In a customer maintenance screen, maintaining customer data is static elementary process.

The different elements in function points are as follows:-

​ Internal Logical Files (ILF)

​ External Interface File (EIF)

​ Record Element Type (RET)

​ DET (Data element types)

​ File Type Reference (FTR)

​ External Input (EI)

​ External Inquiry (EQ)

​ External Output (EO)​

Let us run in detail through each of them.

Internal Logical Files (ILF)

Following are points to be noted for ILF:-

ILF are logically related data from user point of view. They reside in Internal Application boundary and are maintained through elementary process of application.

​ ILF may have maintenance screen or probably not.

Note: - Do not make a mistake of mapping one to one relationship between ILF and technical database design in that case FPA can go very misleading. The main difference between ILF and technical database is ILF is logical view and database is physical structure (Technical Design). Example Supplier database design will have tables like Supplier, Supplier Address, and Supplier Phone numbers but from ILF point of view, it’s only Supplier. As logically, they are all Supplier details.

External Interface files (EIF)

They are logically related data from user point of view.

​ EIF reside in external application boundary.

​ EIF is used only for reference purpose and are not maintained by internal application.

​ EIF is maintained by external application.

Record Element Type (RET)

Following are points to be noted for RET are : -

​ RET are sub-group element data of ILF or EIF.

​ If there is no sub-group of ILF then count the ILF itself as one RET.

​ A group of RET within ILF are logically related, most probably with a parent Child relationship.

Example: - Supplier had multiple addresses and every address can have multiple phone numbers (see the image below which shows database diagrams). Therefore, Supplier, SupplierAddress and Supplier phone numbers are RET. Note: - The whole database is one supplier ILF as all belong to one logical section.

• RET quantifies the relationship complexity of ILF and EIF.

DET (Data element types)

Following are the points to be noted for DET counting:-

Each DET should be User recognizable. Example in the above given figure we have kept auto increment field (Supplierid) for primary key. Supplierid field from user point of view never exists at all, it’s only from software designing aspect, so does not qualifies for DET. DET should be non-recursive field in ILF. DET should not repeat in the same ILF again, it should be counted only once. Count foreign keys as one DET. “Supplierid” does not qualifies as DET but its relationship in “supplieraddress” table is counted as DET. So “Supplierid_fk” in supplieraddress table is counted as DET. same holds true for “Supplieraddressid_fk”.

File Type Reference (FTR)

Following are points to be noted for FTR:-

​ FTR is files or data referenced by a transaction.

​ FTR should be ILF or EIF. So count each ILF or EIF read during process.

​ If the EP is maintaining an ILF then count that as FTR. So by default you will always have one FTR in any EP.

External Input (EI)

Following are points to be noted for EI:-

It is a dynamic elementary process [For definition see “Dynamic and Static Elementary Process”] in which data is received from external application boundary. Example: -User Interaction Screens, when data comes from User Interface to Internal Application.

EI may maintain ILF of the application, but it is not compulsory rule. Example: - A calculator application does not maintain any data, but still the screen of calculator will be counted as EI.

Most of time User Screens will be EI, again no hard and fast rule. Example: - An import batch process running from command line does not have screen, but still should be counted as EI as it helps passing data from External Application Boundary to Internal Application Boundary.

External Inquiry (EQ)

Following are points to be noted for EQ

It is a dynamic elementary process in which result data is retrieved from one or more ILF or EIF.

In this EP, some input request has to enter the application boundary.

Output results exits the application boundary.

EQ does not contain any derived data. Derived data means any complex calculated data. Derived data is not just mere retrieval but are combined with additional formulae to generate results. Derived data is not part of ILF or EIF, they are generated on fly.

​ EQ does not update any ILF or EIF.

​ EQ activity should be meaningful from user perspective.

​ EP is self-contained and leaves the business in consistent state.

​ DET and processing logic is different from other EQ’s.

​ Simple reports form good base as EQ.

Note: - No hard and fast rules that only simple reports are EQ. Simple view functionality can also be counted as EQ.

External Output (EO)

Following are points to be noted for EO:-

It is a dynamic elementary process in which derived data crosses from Internal Application Boundary to External Application Boundary.

EO can update an ILF or EIF.

Process should be the smallest unit of activity that is meaningful to end user in business.

EP is self-contained and leaves the business in a consistent state.

DET is different from other EO’s. Therefore, this ensures to us that we do not count EO’s twice.

They have derived data or formulae calculated data.

Major difference between EO and EQ is that data passes across application boundary.

Example: - Exporting Accounts transaction to some external file format like XML or some other format. The external accounting software can later import this. Second important difference is in EQ has non-derived data and EO has derived data.

In GSC (General System Characteristic), there are 14 factors, which are rated on 1 to 5 depending on the complexity of the factor.

Below are the 14 factors:-

Data communications: - How many communication facilities are there to aid in the transfer or exchange of information with the application or system?

Distributed data processing: -How are distributed data and processing functions handled?

Performance: -Did the user require response at times or throughout?

Heavily used configuration: - How heavily used is the current hardware platform where the application will be executed?

Transaction rate:-How frequently are transactions executed; daily, weekly, monthly, etc.?

On-Line data entry:-What percentage of the information is entered On-Line?

End-user efficiency:-Was the application designed for end-user efficiency?

On-Line update: - How many ILF’s are updated by On-Line transaction?

Complex processing: - Does the application have extensive logical or mathematical processing?

Reusability:- Was the application developed to meet one or many users needs?

Installation ease: - How difficult is conversion and installation?

Operational ease: - How effective and/or automated are start-up, back up, and recovery procedures?

Multiple sites: - Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?

Facilitate change: - Was the application specifically designed, developed, and supported to facilitate change?

From the GSC we get the VAF i.e. Value added function points by the below formulae. VAF = 0.65 + ((sum of all GSC factor)/100).

Unadjusted function points = ILF + EIF + EI + EQ + EO. Below is the table referred for getting ILF, EIF, EI, EQ and EO.

Below are the steps in function points:- First Count ILF, EIF, EI, EQ, RET, DET, FTR and use the rating tables. After you have counted all the elements, you will get the unadjusted function points.

Put rating values 0 to 5 to all 14 GSC. Adding all total 14 GSC to come out with total VAF. Formula for VAF = 0.65 + (sum of all GSC factor/100).

Finally, make the calculation of adjusted function point. Formula: Total function point = VAF * Unadjusted function point. Make estimation how many function points you will do per day. These is also called as "Performance factor". On basis of performance factor, you can calculate Man/Days.

Twist: - What is your company’s productivity factor?

Left to the readers as every company has his own FP per Day.

Note: - There is a free PDF provided “How to prepare Software Quotations?” Please do refer Function point chapter.

In CD, we have a complete free PDF tutorial of how to prepare software quotation. It has all the estimation technology that today’s software industry uses.

In CD, we have a complete free PDF tutorial of how to prepare software quotation. It has all the estimation technology that today’s software industry uses.

Look for the PDF in the CD.

Left for the readers to answer.

It’s very important during interview to be clear about what position you are targeting. Depending on what positions you are targeting the interviewer shoots you questions. Example if you are looking for a project manager position you will be asked around 20% technical questions and 80% management.

Note: - In small scale software house and mid scale software companies there are chances where they expect a PM to be very much technical. But in big software houses the situations are very much different, interview are conducted according to positions.... Unless the interviewer changes the rule.

Above is a figure of a general hierarchy across most IT companies.

Note: - There are many small and medium software companies which do not follow this hierarchy and they have there own adhoc way of defining positions in the company.

So why is the need of hierarchy in a interview.

So employer is looking for a suitable candidate and candidate looks for a better career. Normally in interviews, the employer is very clear about what type of candidate he is looking for. However, 90% times the candidate is not clear about the positions he is looking for.

How many times it has happened with you that you have given a whole interview and when you mentioned the position you are looking for...pat comes the answer, “ we do not have any requirements for this position”. So be clarified about the position right from when you start the interview.

5. Junior engineers are especially freshers and work under software engineers. Software engineers have around 1 to 2 years of experience. Interviewer expects software engineers to be technically at a medium level.

6. Senior Software Engineers have around 2 to 4 years of experience. Interviewer expects them to technically be very strong.

7. Project leads should handle majority technical aspect of project and should have around 4 to 8 years of experience. They are also indirect architect of the project. Interviewer expects them to be technically strong so that they can drive the architecture part of the project. Interviewer also expects them to have people management skills.

8. Project Manager are expected to be around 40% technically strong and should have experience above 10 years plus. But they are more interviewed from aspect of project management, client interaction, people management, proposal preparation etc.

So now judge where you stand, and where you want to go..........

First impression the last impression

Note : - A sample resume is provided in “SampleResume” folder.

Before even the interviewer meets you he will first meet your resume. Interviewer looking at your resume is almost a 20% interview happening with out you knowing it. I was always a bad guy when it comes to resume preparation. But when I looked at my friends resume they where really good. Now that I am writing series of book on interviews I thought this will be a good point to put in. You can happily skip it if you are confident about your resume. There is no hard and fast rule that you have to follow the same pattern but just see if these all check list are attended.

4. Use plain text when you are sending resumes through email. For instance you sent your resume using Microsoft word and what if the interviewer is using Linux he will never be able to read your resume. You can not be sure both wise, you sent your resume in Word 2000 and the guy has Word 97…uuhhh.

5. Attach a covering letter it really impresses and makes you look traditionally formal.Yes, even if you are sending your CV through email send a covering letter.

5. Start with an objective or summary, for instance, “Working as a Senior Database administrator for more than 4 years. Implemented quality web based application. Follow the industry’s best practices and adhered and implemented processes, which enhanced the quality of technical delivery. Pledge to deliver the best technical solutions to the industry.”

6. Specify your Core strengths at the start of the resume by which the interviewer can make a quick decision are you eligible for the position. For example :-

Looked after data mining and data warehousing department independently. Played a major role in query optimization.

Worked extensively in database design and ER diagram implementation.

Well versed with CMMI process and followed it extensively in projects.

Looking forward to work on project manager or senior manager position.

This is also a good position to specify your objective or position which makes it clear to the interviewer that should he call you for an interview. For instance, if you are looking for senior positions specify it explicitly ‘looking for this job profile’. Any kind of certification like MCP, MCSD etc you can make it visible in this section.

Once you have specified briefly your goals and what you have done its time to specify what type of technology you have worked with. For instance RDBMS, TOOLS, Languages, Web servers, process (Six sigma, CMMI).

After that you can make a run through of your experience company wise that is what company you have worked with, year / month joining and year / month left. This will give an overview to the interviewer what type of companies you have associated your self.

Now its time to mention all your projects you have worked till now. Best is to start in descending order that is from your current project and go backwards. For every project try to put these things:-

Project Name / Client name (It’s sometimes unethical to mention clients name; I leave it to the readers). Number of team members.

Time span of the project.

Tools, language, RDBMS and technology used to complete the project.

Senior people who have huge experience will tend to increase there CV with putting in summary for all project. Best for them is to just put description of the first three projects in descending manner and rest they can say verbally during interview. I have seen CV above 15 pages… I doubt who can read it.

Finally comes your education and personal details.

Trying for onsite, do not forget to mention your passport number.

Some guys tend to make there CV large and huge. I think an optimal size should be not more than 4 to 5 pages.

Do not mention your salary in CV. You can talk about it during interview with HR or the interviewer.

When you are writing your summary for project make it effective by using verbs like managed a team of 5 members, architected the project from start to finish etc. It brings huge weight,

This is essential very essential take 4 to 5 Xerox copies of your resume you will need it now and then.

Just in case take at least 2 passport photos with you. You can escape it but many times you will need it.

Carry all your current office documents specially your salary slips and joining letter.

Ok that’s what we all do it for MONEY… not everyone but still money means a lot. This is probably the weakest area for techno savvy guys. They are not good negotiators. I have seen so many guys at the first instance they will smile and say “NEGOTIABLE SIR”. So here are some points:-

Let the employer first make the salary offer. Try to delay the salary discussion till the end.

If they say what you expect? Come with a figure with a little higher end and say negotiable. Remember never say negotiable on something which you have aimed, HR guys will always bring it down. So negotiate on AIMED SALARY + some thing extra.

The normal trend is that they look at your current salary and add a little it so that they can pull you in. Do your home work my salary is this much and I expect this much so whatever it is now I will not come below this.

Do not be harsh during salary negotiations.

It’s good to aim high. For instance I want 1 billion dollars / month but at the same time be realistic.

Some companies have those hidden cost attached in salary clarify it rather to be surprised at the first salary package.

Many of the companies add extra performance compensation in your basic which can be surprising at times. So have a detail break down.

Best is to discuss on hand salary rather than NET or CTC.

Talk with the employer in what frequency does the hike happen.

Take everything in writing, go back to your house and have a look once with a cool head is the offer worth it of what your current employer is giving.

Do not forget once you have job in hand you can come back to your current employer for negotiation.

Remember the worst part is cribbing after joining the company that your colleague is getting more. So be careful while interview or be sportive to be a good negotiator in the next interview.

One very important thing is that the best negotiation ground is not the new company where you are going but the old company which you are leaving. So once you have offer on hand get back to your old employee and show them the offer and then make your next move. It’s my experience that negotiating with the old employer is easy than the new one….Frankly if approached properly rarely any one will say no as you have spent quiet a amount of time with them. Just do not be aggressive or egoistic that you have an offer on hand.

Top of all some time some things are worth above money: - JOB SATISFACTION. So whatever you negotiate if you think you can get JOB SATISFACTION aspect on higher grounds go for it. I think its worth more than money.

Applicable to Only India

Years of experience

Amount in Rupees CTC (Monthly)

Freshers 8000 to 10000

1 to 2 yrs  15000 to 25000

3 to 4 yrs  30000 to 45000

4 to 6 yrs 45000 to 55000

6 to 8 yrs 60000 to 75000

8 to 10 yrs  75000 to 85000

10 to 15 yrs 90000 to 100000

15 yrs and above 100000 and above. Mostly depends on negotiations.

We have taken bonus as a part of CTC.

Applicable to US Only

Years of experience

Amount in Dollars (Yearly)

Fresher’s 45000 to 55000

2 to 4 yrs 55000 to 60000

4 to 6 yrs 60000 to 65000

6 to 8 yrs 70000 to 80000

8 to 12 yrs 80000 to 90000

12 and above Depends on negotiations

Note: - The above Salary card is based on my experience and some talk which I had with my friends who are in IT industry.

The score card shown above is completely derived from author’s experience and interaction he had in his circle. It is not an approved score card by any authorized body as such and should be taken only has bench mark to measure your success. Also note that these rates are applicable for medium and large software companies. Small company rate cards are very irregular and governed by a single owner of the company. So the above rate card is not applicable for small company. Many people do get mind blowing salaries even with small experience which again the score card does not reflect.