Software Project Management Manage your people

Software development and maintenance is a complex task: Specific details. Unexpected circumstances. To succeed, manager has to take in mind: People Process Tools Measurements Discarding any one of the previous 4, will lead to a problem in the project.

Software development and maintenance is a complex task:

Specific details.

Unexpected circumstances.

To succeed, manager has to take in mind:

People

Process

Tools

Measurements

Discarding any one of the previous 4, will lead to a problem in the project.

Good management of people will lead to a successful project. The project team is cultural entity : you improve their skills and culture. The project itself is cultural event : you put them in a real circumstances. Part of management is improving every team member.

Good management of people will lead to a successful project.

The project team is cultural entity : you improve their skills and culture.

The project itself is cultural event : you put them in a real circumstances.

Part of management is improving every team member.

1.1 Managing project culture Any project begins from an idea from the top managers, users, or any other people. The role of manager and the team is to make this idea to be a complete up and running project. The role of the manager of the team is to improve the team members, the process and the tools used to build the project.

Any project begins from an idea from the top managers, users, or any other people.

The role of manager and the team is to make this idea to be a complete up and running project.

The role of the manager of the team is to improve the team members, the process and the tools used to build the project.

Every project has its own circumstances and its own culture. Project manager has to understand every project culture in order to use people and tools to make a good process to develop the project. Steps for that: Understand organizational structure. Understand each person in the project and his background: to put him in the suitable place in the project. Match cultural and engineering roles to people. Monitor the whole process

Every project has its own circumstances and its own culture.

Project manager has to understand every project culture in order to use people and tools to make a good process to develop the project.

Steps for that:

Understand organizational structure.

Understand each person in the project and his background: to put him in the suitable place in the project.

Match cultural and engineering roles to people.

Monitor the whole process

Understand the organizational structure: Project culture is influenced by the organizational structure. Understanding culture of your organization may involve asking some questions: How projects normally proceed in this organization. Are project typically successful. How do software engineers deal with projects. How software engineers deal with schedules, CASE tools, measurements, and other things. What difficulties do you face with the four building blocks of software project management.

Understand the organizational structure:

Project culture is influenced by the organizational structure.

Understanding culture of your organization may involve asking some questions:

How projects normally proceed in this organization.

Are project typically successful.

How do software engineers deal with projects.

How software engineers deal with schedules, CASE tools, measurements, and other things.

What difficulties do you face with the four building blocks of software project management.

Understand each team member: Team members usually come from different cultures, so you have to understand each one. (different backgrounds, generation and experience). To asses these different factors, you have to raise up these questions for every member: What type of his educational background. How much his experience. What is his generation. Try to know about his personal life. What are the strengths and weakness points of this person.

Understand each team member:

Team members usually come from different cultures, so you have to understand each one. (different backgrounds, generation and experience).

To asses these different factors, you have to raise up these questions for every member:

What type of his educational background.

How much his experience.

What is his generation.

Try to know about his personal life.

What are the strengths and weakness points of this person.

Determining the previous information of every member in the team, will lead you to make good combinations of those members.

Determining the previous information of every member in the team, will lead you to make good combinations of those members.

Match roles to people Roles in the project may be determined by project manager, members, or from the progress in the project. Typical roles in a project are: Requirement engineer: maintains project requirements during the production of the project (documents, clarifications,…etc). Lead Designer: evaluates, chooses, documents, clarifies, and maintains product design.

Roles in the project may be determined by project manager, members, or from the progress in the project.

Typical roles in a project are:

Requirement engineer: maintains project requirements during the production of the project (documents, clarifications,…etc).

Lead Designer: evaluates, chooses, documents, clarifies, and maintains product design.

Coder: implements the project and correct errors. Quality assurance engineer: measures the quality of the software, determines the level of the quality, by working on the errors in the project. Customer liason: maintains the relationships with users of the project. Tools expert: installs, troubleshoots, upgrades, and maintains project tools. Other: additional roles required by the project.

Coder: implements the project and correct errors.

Quality assurance engineer: measures the quality of the software, determines the level of the quality, by working on the errors in the project.

Customer liason: maintains the relationships with users of the project.

Tools expert: installs, troubleshoots, upgrades, and maintains project tools.

Other: additional roles required by the project.

Project roles can be defined in many ways: Team leader: builds and maintains and effective team. Development leader: produces a superior product. Planning manager: guides the team to produce a plan and tracks progress against the plan. Support manager: ensures the project is properly supported and controlled.

Project roles can be defined in many ways:

Team leader: builds and maintains and effective team.

Development leader: produces a superior product.

Planning manager: guides the team to produce a plan and tracks progress against the plan.

Support manager: ensures the project is properly supported and controlled.

Monitor and manage team culture Team cohesion is the first factor in leading teams that influence the productivity. To manage project culture you must: Make each member role to be clear. Understand each person’s personality and try to use that in assigning him a suitable role. State and maintain your view of the team. Recognize problems that might occur before they impact the team. Solve the problems before they impact the project. (if an employee has a problem, then the whole company has a problem).

Team cohesion is the first factor in leading teams that influence the productivity.

To manage project culture you must:

Make each member role to be clear.

Understand each person’s personality and try to use that in assigning him a suitable role.

State and maintain your view of the team.

Recognize problems that might occur before they impact the team.

Solve the problems before they impact the project.

(if an employee has a problem, then the whole company has a problem).

1.2 Managing Good People Difficult task, because you are dealing with people who are talented. You have to balance between authority and respect. There are six guidelines you should follow to manage the team: Gain visibility without micromanagement. Review process and products, not people. Coordinate with talented people. Use your knowledge, not your position of power. Channel people. Focus on their and the project’s needs, not your authority as manager.

Difficult task, because you are dealing with people who are talented.

You have to balance between authority and respect.

There are six guidelines you should follow to manage the team:

Gain visibility without micromanagement.

Review process and products, not people.

Coordinate with talented people.

Use your knowledge, not your position of power.

Channel people.

Focus on their and the project’s needs, not your authority as manager.

1.3 Making Good People Better Deal with team members side by side as you deal with project itself. Steps t make good people better: Make professional development a project goal. Recognize long- and short-term professional development goals. Let each team member specify personal improvement goals. Have team members track their individual time.

Deal with team members side by side as you deal with project itself.

Steps t make good people better:

Make professional development a project goal.

Recognize long- and short-term professional development goals.

Let each team member specify personal improvement goals.

Have team members track their individual time.

Make a professional development a project goal: Professional development of your team includes short-term and long-term goals. Short-term goals focuses on skills needed for this project while long-term goals prepare the team for future projects. Recognize long- and short-term goals: You have to discuss with team members their individual goals for long-term improvement, and then support these goals through the project life cycle. For example, when you have not enough time to give a person coding tasks, you have to give this task to an expert person, and try to assign coding for a person who has little experience in an offline times of the project.

Make a professional development a project goal:

Professional development of your team includes short-term and long-term goals.

Short-term goals focuses on skills needed for this project while long-term goals prepare the team for future projects.

Recognize long- and short-term goals:

You have to discuss with team members their individual goals for long-term improvement, and then support these goals through the project life cycle.

For example, when you have not enough time to give a person coding tasks, you have to give this task to an expert person, and try to assign coding for a person who has little experience in an offline times of the project.

Let each team member specify goals: You have to review with every member in the team where he and how he can improve his skills. This will improve the activity of the member, because you show him that you care about him, and your care is not only for the project. Track individual time: Team members have to use time to track and assess their effort, in order for them to know where is the part in the project that took times from them. You as manager, has to know what are the parts in the project that took a lot of effort. A special piece of software could be used to log activities in the project assigned with times needed to accomplish these tasks.

Let each team member specify goals:

You have to review with every member in the team where he and how he can improve his skills.

This will improve the activity of the member, because you show him that you care about him, and your care is not only for the project.

Track individual time:

Team members have to use time to track and assess their effort, in order for them to know where is the part in the project that took times from them.

You as manager, has to know what are the parts in the project that took a lot of effort.

A special piece of software could be used to log activities in the project assigned with times needed to accomplish these tasks.

1.4 Leading good people Leadership is not as management. People have to obey manager because of his position. Leadership is much more difficult than management. Leadership needs more effort, tasks from the leader in order to follow the right track of project production.

Leadership is not as management.

People have to obey manager because of his position.

Leadership is much more difficult than management.

Leadership needs more effort, tasks from the leader in order to follow the right track of project production.

Now, combining management with leadership, will be better for both people and project. This can be done by 6 steps: Be confident in yourself and the team: you can make them do what you need. Take responsibility for making mistakes and focus on corrective actions: take and give advices, don’t concentrate on individual mistakes. Lead by example. Show the team what do you expect from yourself and from them: don’t leave them working while you are in a rest for launch. Work in groups soul, you can’t finish the project by yourself alone. Complete all your commitments on time: if you couldn’t, explain why.. Don’t mix between friendship and leadership.

Now, combining management with leadership, will be better for both people and project.

This can be done by 6 steps:

Be confident in yourself and the team: you can make them do what you need.

Take responsibility for making mistakes and focus on corrective actions: take and give advices, don’t concentrate on individual mistakes.

Lead by example. Show the team what do you expect from yourself and from them: don’t leave them working while you are in a rest for launch.

Work in groups soul, you can’t finish the project by yourself alone.

Complete all your commitments on time: if you couldn’t, explain why..

Don’t mix between friendship and leadership.

Software Project Management Process Implementation

Preface Software Process: is a sequence of tasks intended to produce a high-quality software product on time and within budget. Software process shows the team members what they have to do, what they did, why they did, what are the consequences and results.

Software Process: is a sequence of tasks intended to produce a high-quality software product on time and within budget.

Software process shows the team members what they have to do, what they did, why they did, what are the consequences and results.

Depending on the answers of the previous questions, the process can be updated. (quality assurance). Processes have to be planed and documented. Just like houses. Processes that are not documented, will lead to a different project. Process is a property for the company and it must be a secret for that company. Software project needs a documented process, that made by all of the members of the team.

Depending on the answers of the previous questions, the process can be updated. (quality assurance).

Processes have to be planed and documented. Just like houses.

Processes that are not documented, will lead to a different project.

Process is a property for the company and it must be a secret for that company.

Software project needs a documented process, that made by all of the members of the team.

Process must be assessed from time to time (quality assurance), by different tools, measures, and different types of inputs.

Process must be assessed from time to time (quality assurance), by different tools, measures, and different types of inputs.

2.1 Putting a process in place: A project must have a process investment, project that has no investments for processes will end up with a thrashing situation. When a project proceeds without a well studied process, thrashing will increase and vice versa. As project length increases, the project typically must require more hardware, software and requirements changes (so there must be a well prepared process to finish the project on time).

2.1 Putting a process in place:

A project must have a process investment, project that has no investments for processes will end up with a thrashing situation.

When a project proceeds without a well studied process, thrashing will increase and vice versa.

As project length increases, the project typically must require more hardware, software and requirements changes (so there must be a well prepared process to finish the project on time).

Project Launch effort 100% 0% Project Conclusion Useful Work Thrashing Thrashing when no process is specified

Thrashing with a process Process Investment Useful Work 100% 0% Effort Project Launch Project Completion Thrashing when a Process is specified

Project process must be specified well, specifying it depends on the size of project, numbers of members in team and time period needed to finish the project. (3 people, 3 months, VS 30 people 3 years project).

Project process must be specified well, specifying it depends on the size of project, numbers of members in team and time period needed to finish the project. (3 people, 3 months, VS 30 people 3 years project).

Useful Work Thrashing without a process 100% 0% 2 People 100 people Thrashing as team size increases when no process is specified

100 people 2 people 0% 100% Effort Thrashing with a process Useful work Process Investment Thrashing as team size increases when a process is specified

A specified process helps control, manage, and archive all activities occurred during the process (audit trail). At the opposite side, team does need a micro specified process that makes the work to be tedious and boring. Team needs a specified process that helps them to control the whole project far a way from routines.

A specified process helps control, manage, and archive all activities occurred during the process (audit trail).

At the opposite side, team does need a micro specified process that makes the work to be tedious and boring.

Team needs a specified process that helps them to control the whole project far a way from routines.

Team leader with team members have to specify one of two ways of processes: Tailor the organizational process to your project. Specify a process for your project (ready well known processes followed by the organization in the past). in the first case, you have to be careful when specifying the process, this process must be compatible with organization’s rules. (ISO).

Team leader with team members have to specify one of two ways of processes:

Tailor the organizational process to your project.

Specify a process for your project (ready well known processes followed by the organization in the past).

in the first case, you have to be careful when specifying the process, this process must be compatible with organization’s rules. (ISO).

Literature has a great processes that can be followed. These processes take in mind many factors such that: Requirements volatility (not fixed). Risk assessment. Scheduling difficulties. Product concurrency. These ready to use processes took in mind the previous 4 problems that might face any software project.

Literature has a great processes that can be followed.

These processes take in mind many factors such that:

Requirements volatility (not fixed).

Risk assessment.

Scheduling difficulties.

Product concurrency.

These ready to use processes took in mind the previous 4 problems that might face any software project.

Following a stage implementation of the product, will lead to more control and great management for the project. Software Concept Requirements Development Architectural Design Stage 1: Detailed Design, Construction and release Stage 2: Detailed Design, Construction and release Stage 3: Detailed Design, Construction and release Software Release Staged Implementation Model

Following a stage implementation of the product, will lead to more control and great management for the project.

The spiral model in specifying processes focuses on risk assessment and works well where risk, technical changes, or other factors might cancel a project. (figure 2.6 in the text book).

The spiral model in specifying processes focuses on risk assessment and works well where risk, technical changes, or other factors might cancel a project. (figure 2.6 in the text book).

2.1.1 tailoring a process: Tailoring requires gathering information, propose changes, integrate feed back on changes, and then settle on a reasonable process specification. Steps followed to tailor a process: Determine how is your project differs from the typical organizational projects. Form two lists: activities your project needs and activities it does not need from the organizational process. Process changes to the organizational process. Provide the team with the new process for review. Integrate the changes to the process.

2.1.1 tailoring a process:

Tailoring requires gathering information, propose changes, integrate feed back on changes, and then settle on a reasonable process specification.

Steps followed to tailor a process:

Determine how is your project differs from the typical organizational projects.

Form two lists: activities your project needs and activities it does not need from the organizational process.

Process changes to the organizational process.

Provide the team with the new process for review.

Integrate the changes to the process.

Determine Project differences: Ask some questions to determine how is the new project differs from the organizational projects such as: How is the size of team compared with other projects? Are the development and target platforms well known within the organization? Is the development environment well understood (OS, languages, tools, system configuration,…etc.)? How is the schedule compared with other projects (in terms of time, effort and proposed changes) ?. Do any contractual requirements differ significantly fro the organizational norm? Do the talented and experienced people fit in this project, as they were in previous projects. Will external parties influence previous projects?

Determine Project differences:

Ask some questions to determine how is the new project differs from the organizational projects such as:

How is the size of team compared with other projects?

Are the development and target platforms well known within the organization?

Is the development environment well understood (OS, languages, tools, system configuration,…etc.)?

How is the schedule compared with other projects (in terms of time, effort and proposed changes) ?.

Do any contractual requirements differ significantly fro the organizational norm?

Do the talented and experienced people fit in this project, as they were in previous projects.

Will external parties influence previous projects?

Make two lists: Once you gathered information from the previous step, make two lists: Tasks in the process that you don’t need. Tasks you need that are not in the process. The criteria for selecting items in both lists should depend on : What will this task cost in terms of time and resources. What benefit will this task provide for the project. Study the two lists well, and give explanations for that.

Make two lists:

Once you gathered information from the previous step, make two lists:

Tasks in the process that you don’t need.

Tasks you need that are not in the process.

The criteria for selecting items in both lists should depend on :

What will this task cost in terms of time and resources.

What benefit will this task provide for the project.

Study the two lists well, and give explanations for that.

Propose Process Changes: Prepare a document that will contain all of the changes that must be applied for all that tasks. Make the document readable, understandable, and to the point. Circulate the process and gather feedback: Don’t do all of the previous steps alone, instead, share your team with that. Receive comments from them, and these comments with them.

Propose Process Changes:

Prepare a document that will contain all of the changes that must be applied for all that tasks.

Make the document readable, understandable, and to the point.

Circulate the process and gather feedback:

Don’t do all of the previous steps alone, instead, share your team with that.

Receive comments from them, and these comments with them.

Integrate changes: Integrate the changes in the process. Reviewing process must end at some point, it must not be endless job.

Integrate changes:

Integrate the changes in the process.

Reviewing process must end at some point, it must not be endless job.

2.1.2 Specifying a Process: Process must be specified by the following steps: Know the goals for specifying the process. Specify a format. Specify the process from the highest level. Include more detail progressively. Use team input to the process specification.

2.1.2 Specifying a Process:

Process must be specified by the following steps:

Know the goals for specifying the process.

Specify a format.

Specify the process from the highest level.

Include more detail progressively.

Use team input to the process specification.

Know your goal: The goals of process specification should: Document a process that will best benefit your project. Communicate to your team the tasks needed for project success. Establish the coordination, quality, and control mechanisms for this project. Explicitly indicate what needs to be completed when.

Know your goal:

The goals of process specification should:

Document a process that will best benefit your project.

Communicate to your team the tasks needed for project success.

Establish the coordination, quality, and control mechanisms for this project.

Explicitly indicate what needs to be completed when.

Specify Format: Process specifications can take several forms. Layered process diagram supports abstraction, encapsulation, and maintenance activities such as adding, deleting, and changing tasks.

Specify Format:

Process specifications can take several forms.

Layered process diagram supports abstraction, encapsulation, and maintenance activities such as adding, deleting, and changing tasks.

Specify from the highest level first: Begin with the levels of the highest abstraction. Layered process Include more detail progressively: Move from the highest to the lowest. Level of details must be specified. Moving from the top most level to the lowest, will make adding new tasks, changing current tasks, deleting unnecessary ones, to be easier and more controlled.

Specify from the highest level first:

Begin with the levels of the highest abstraction.

Layered process

Include more detail progressively:

Move from the highest to the lowest.

Level of details must be specified.

Moving from the top most level to the lowest, will make adding new tasks, changing current tasks, deleting unnecessary ones, to be easier and more controlled.

Use team input: Team members have their own notes about the steps of the process, taking their opinions will enrich the process.

Use team input:

Team members have their own notes about the steps of the process, taking their opinions will enrich the process.

Software Project Management Sketch your schedule

Obviously, a schedule communicates the length of time a team has to complete a project. It also advertises to stakeholders and others what the team has done, is doing, and plans on doing in the future. A schedule supports visibility into project progress, risk assessment, identification of critical events, and rescheduling.

Obviously, a schedule communicates the length of time a team has to complete a project.

It also advertises to stakeholders and others what the team has done, is doing, and plans on doing in the future.

A schedule supports visibility into project progress, risk assessment, identification of critical events, and rescheduling.

Unfortunately, schedules are rarely accurate for long periods of time. As software projects progress your schedule will become out of date and incorrect. This doesn't mean you are a poor scheduler; it only means you need to update your schedule. Iterative and staged development processes specifically assume schedules are incorrect and attempt to solve this problem by scheduling only a limited distance into the future.

Unfortunately, schedules are rarely accurate for long periods of time.

As software projects progress your schedule will become out of date and incorrect.

This doesn't mean you are a poor scheduler; it only means you need to update your schedule.

Iterative and staged development processes specifically assume schedules are incorrect and attempt to solve this problem by scheduling only a limited distance into the future.

Your first task is size estimation. How big is this project? From this number, estimate how long it will take to complete the project. This book introduces the function point method for size estimation and the COCOMO model for effort and schedule estimation. Many if not most software projects have immovable milestones in their schedules before the project is even launched.

Your first task is size estimation. How big is this project? From this number, estimate how long it will take to complete the project.

This book introduces the function point method for size estimation and the COCOMO model for effort and schedule estimation.

Many if not most software projects have immovable milestones in their schedules before the project is even launched.

Immovable milestones force you to estimate how much of the project your team can complete by the milestone date. Once you have this estimate, you need to schedule the tasks required to meet this deadline.

Immovable milestones force you to estimate how much of the project your team can complete by the milestone date.

Once you have this estimate, you need to schedule the tasks required to meet this deadline.

7.1 Estimating Project Size and Effort: You can estimate project size and effort in several ways. One method that has been around for more than twenty years is the function point method One of its most beneficial aspects is that you can tailor it to your organization. you can tailor the basic COCOMO model and COCOMO II to your organization as well.

7.1 Estimating Project Size and Effort:

You can estimate project size and effort in several ways.

One method that has been around for more than twenty years is the function point method

One of its most beneficial aspects is that you can tailor it to your organization.

you can tailor the basic COCOMO model and COCOMO II to your organization as well.

To use these models, follow the following steps: Estimate the Adjusted and Unadjusted Function Points: The function point method can be used to estimate the source lines of code (SLOC) your software product will require.

To use these models, follow the following steps:

Estimate the Adjusted and Unadjusted Function Points:

The function point method can be used to estimate the source lines of code (SLOC) your software product will require.

Estimate the Schedule Length and Effort: The SLOC estimate produced by the function point method can be used by the COCOMO model to estimate the effort and schedule length needed to produce your software.

Estimate the Schedule Length and Effort:

The SLOC estimate produced by the function point method can be used by the COCOMO model to estimate the effort and schedule length needed to produce your software.

Adjust the Estimates as the Project Progresses: Will be covered later. 7.1.1 Function Points: Function points are a way to quantify the amount of functionality of a software product based on its requirements. The basic idea of function points is to count the complexity of the software's interface with the outside world and the complexity of its internal data storage.

Adjust the Estimates as the Project Progresses:

Will be covered later.

7.1.1 Function Points:

Function points are a way to quantify the amount of functionality of a software product based on its requirements.

The basic idea of function points is to count the complexity of the software's interface with the outside world and the complexity of its internal data storage.

To count function points, the following types of information must be collected for a software system: User inputs—The total number of user inputs and their complexity. In practice this would not mean counting every input on a dialog box but rather counting the dialog box as an input and classifying it as simple, average, or complex based on the number of input items and their interaction.

To count function points, the following types of information must be collected for a software system:

User inputs—The total number of user inputs and their complexity. In practice this would not mean counting every input on a dialog box but rather counting the dialog box as an input and classifying it as simple, average, or complex based on the number of input items and their interaction.

User outputs—The total number of user outputs and their complexity. This does not mean counting every output on a report or interface screen but rather counting each report or screen once and classifying it as simple, average, or complex based on the number of output items and their relationships.

User outputs—The total number of user outputs and their complexity. This does not mean counting every output on a report or interface screen but rather counting each report or screen once and classifying it as simple, average, or complex based on the number of output items and their relationships.

User inquiries—The total number of user inputs that generate a software response, such as a word count, search result, or software status. Again, each inquiry is counted once and classified as simple, average, or complex. Files—The total number of external files or internal file structures (internal databases, large complex data structures, etc.) created and used dynamically by the system, each of which is classified as simple, average, or complex.

User inquiries—The total number of user inputs that generate a software response, such as a word count, search result, or software status. Again, each inquiry is counted once and classified as simple, average, or complex.

Files—The total number of external files or internal file structures (internal databases, large complex data structures, etc.) created and used dynamically by the system, each of which is classified as simple, average, or complex.

External interfaces—The total number of external files (data connections, databases, etc.) that connect this software to an external hardware or software system. For example, if the software communicates to a device over a communications port, this would be an external Interface. To put this method to work, count items in each category and then classify them based on consistent criteria. Once you have the function points counted, you can easily total them using the Software Cost Modeling System. Simply enter your counts into the dialog box. COSMOS will provide you with the total unadjusted function points.

External interfaces—The total number of external files (data connections, databases, etc.) that connect this software to an external hardware or software system. For example, if the software communicates to a device over a communications port, this would be an external Interface.

To put this method to work, count items in each category and then classify them based on consistent criteria.

Once you have the function points counted, you can easily total them using the Software Cost Modeling System. Simply enter your counts into the dialog box. COSMOS will provide you with the total unadjusted function points.

You can then adjust your function point count by a set of complexity factors. The complexity factors are: Data communications—The degree to which communication facilities are required for the application. Distributed functions—The existence of distributed functions in the application. Performance—The degree to which performance is a critical issue. Heavily used configuration—The installation of the application on current equipment that is heavily used.

You can then adjust your function point count by a set of complexity factors. The complexity factors are:

Data communications—The degree to which communication facilities are required for the application.

Distributed functions—The existence of distributed functions in the application.

Performance—The degree to which performance is a critical issue.

Heavily used configuration—The installation of the application on current equipment that is heavily used.

Transaction rate—The measurement of the transaction rate. On-line data entry—The complexity of on-line data transactions, giving consideration to the number of screens and functions. End-user efficiency—The degree to which on-line functions promote end user efficiency. On-line update—The use of on-line updates to master files. Complex processing—The amount of complex processing. Complex processing may have many control interactions and decision points, a significant number of logical and mathematical equations, or extensive exception processing.

Transaction rate—The measurement of the transaction rate.

On-line data entry—The complexity of on-line data transactions, giving consideration to the number of screens and functions.

End-user efficiency—The degree to which on-line functions promote end user efficiency.

On-line update—The use of on-line updates to master files.

Complex processing—The amount of complex processing. Complex processing may have many control interactions and decision points, a significant number of logical and mathematical equations, or extensive exception processing.

Reusability—The evaluation of code in terms of reusability. Installation ease—The degree of ease with which the application is installed. Operational ease—The proficiency of the application's general operations, such as startup, backup, recovery, and shutdown. Multiple sites—The number of installations of the application across diverse organizations or sites. Facilitate change—The appraisal (assessment) of the application in terms of how easily it accommodates user modifications, such as providing a flexible query facility or functions for setting and maintaining user defined parameters.

Reusability—The evaluation of code in terms of reusability.

Installation ease—The degree of ease with which the application is installed.

Operational ease—The proficiency of the application's general operations, such as startup, backup, recovery, and shutdown.

Multiple sites—The number of installations of the application across diverse organizations or sites.

Facilitate change—The appraisal (assessment) of the application in terms of how easily it accommodates user modifications, such as providing a flexible query facility or functions for setting and maintaining user defined parameters.

Once you have the function points and complexity factors, choose your development language from the list of available languages to determine the SLOC estimate. COSMOS allows you to adjust these counts for your particular organization, which you should consider during project assessment.

Once you have the function points and complexity factors, choose your development language from the list of available languages to determine the SLOC estimate.

COSMOS allows you to adjust these counts for your particular organization, which you should consider during project assessment.

The function point method is not perfect, Two people may arrive at different estimates. In practice, though, this can be a good thing because each person may have considered factors the other did not, or put different emphases on different factors. An excellent way to get more accurate estimates is to have two or more people count and adjust function points separately, then meet and resolve the differences to form a single estimate.

The function point method is not perfect, Two people may arrive at different estimates.

In practice, though, this can be a good thing because each person may have considered factors the other did not, or put different emphases on different factors.

An excellent way to get more accurate estimates is to have two or more people count and adjust function points separately, then meet and resolve the differences to form a single estimate.

7.1.2 COCOMO I The COCOMO I model requires as input a product SLOC estimate. Using this estimate, COCOMO I produces an estimate of the effort and schedule length for a project. Much like the function point method, the more sophisticated Intermediate COCOMO I model uses additional inputs unique to your project to adjust this basic estimate.

7.1.2 COCOMO I

The COCOMO I model requires as input a product SLOC estimate. Using this estimate, COCOMO I produces an estimate of the effort and schedule length for a project.

Much like the function point method, the more sophisticated Intermediate COCOMO I model uses additional inputs unique to your project to adjust this basic estimate.

COCOMO I actually contains models for three types of projects: 1. Organic-Relatively small projects from stable, familiar, forgiving, and relatively unconstrained environments 2. Semidetached-intermediate-sized projects from less stable, less familiar, less forgiving environments with some rigid constraints 3. Embedded-Ambitious intermediate or large projects from unfamiliar,unforgiving, and tightly constrained environments

COCOMO I actually contains models for three types of projects:

1. Organic-Relatively small projects from stable, familiar, forgiving, and relatively unconstrained environments

2. Semidetached-intermediate-sized projects from less stable, less familiar, less forgiving environments with some rigid constraints

3. Embedded-Ambitious intermediate or large projects from unfamiliar,unforgiving, and tightly constrained environments

You need to classify your project into one of these types in order to use the correct estimation formula. The COCOMO I model estimates effort and schedule for each of these types of projects with slightly different formulas. The formulas (where KSLOC is one thousand SLOC) are: Organic - Effort = 2.4 (KSLOC) 1.05 ; Schedule length = 2.5 (Effort) 0.38 Semidetached - Effort = 3.0 (KSLOC) 1.12 ; Schedule length = 2.5 (Effort) 0-35 Embedded - Effort = 3.6 (KSLOC) 1.2 ; Schedule length = 2.5 (Effort) 0.32

You need to classify your project into one of these types in order to use the correct estimation formula.

The COCOMO I model estimates effort and schedule for each of these types of projects with slightly different formulas. The formulas (where KSLOC is one thousand SLOC) are:

Organic - Effort = 2.4 (KSLOC) 1.05 ; Schedule length = 2.5 (Effort) 0.38

Semidetached - Effort = 3.0 (KSLOC) 1.12 ; Schedule length = 2.5 (Effort) 0-35

Embedded - Effort = 3.6 (KSLOC) 1.2 ; Schedule length = 2.5 (Effort) 0.32

You can immediately see that these formulas are amenable to adjustment to fit your organization if you change the constants and exponents to better fit your historical data. For example, if your organization can complete organic projects with less effort than the standard effort formula, adjust the 1.05 exponent in the effort equation to 1.03. This would reduce a 100.000 SLOC project from 300 person-months (2.4 * (100) 1.05 ) to 273.6 person-months (2.4 * (100) 1.03 ).

You can immediately see that these formulas are amenable to adjustment to fit your organization if you change the constants and exponents to better fit your historical data.

For example, if your organization can complete organic projects with less effort than the standard effort formula, adjust the 1.05 exponent in the effort equation to 1.03. This would reduce a 100.000 SLOC project from 300 person-months (2.4 * (100) 1.05 ) to 273.6 person-months (2.4 * (100) 1.03 ).

If your organization can complete an organic project faster than the standard schedule length, adjust the 0.38 exponent in the schedule length equation to 0.36. This reduces the project length on a 100.000 SLOC project requiring 300 person-months from 21.8 months (2.5 (300) 0.38 ) to 19.4 months (2.5 (100) 0.36 ).

If your organization can complete an organic project faster than the standard schedule length, adjust the 0.38 exponent in the schedule length equation to 0.36. This reduces the project length on a 100.000 SLOC project requiring 300 person-months from 21.8 months (2.5 (300) 0.38 ) to 19.4 months (2.5 (100) 0.36 ).

The Intermediate COCOMO I model adjusts the output of these formulas based on specific cost drivers. These cost drivers fall into four categories: Personnel Analyst capability—The percentile ranking of the analyst's aptitude Software engineer capability—The percentile ranking of the programmer's aptitude Application experience—The number of years of staff background knowledge regarding the application Programming language experience—The number of years of staff experience with the language Virtual machine experience—The number of years of staff experience with the operating system and hardware

The Intermediate COCOMO I model adjusts the output of these formulas based on specific cost drivers. These cost drivers fall into four categories:

Personnel

Analyst capability—The percentile ranking of the analyst's aptitude

Software engineer capability—The percentile ranking of the programmer's aptitude

Application experience—The number of years of staff background knowledge regarding the application

Programming language experience—The number of years of staff experience with the language

Virtual machine experience—The number of years of staff experience with the operating system and hardware

Hardware Time—The measurement of time required for user feedback Run-time performance constraints—The measurement of use of available execution time Memory constraints—The measurement of use of available storage space Virtual machine volatility—The amount the application's environment, such as the operating system and hardware, changes over time Required turnaround time—The measurement of time required for user feedback

Hardware

Time—The measurement of time required for user feedback

Run-time performance constraints—The measurement of use of available execution time

Memory constraints—The measurement of use of available storage space

Virtual machine volatility—The amount the application's environment, such as the operating system and hardware, changes over time

Required turnaround time—The measurement of time required for user feedback

Product Required software reliability—The degree to which software errors can be tolerated. The range for poor reliability can be from slight inconvenience to risk to human life. Size of application database—The ratio of the data storage to the program size Complexity of product—The degree of complexity in the application functions. Simple functions have simple expressions in the computational operations, very little nesting in the control operations, and data management operations that consist of simple arrays in main memory. Complex functions have highly nested control operations, difficult mathematical computations, dynamic data relationships in the data storage, and microcoding for device-dependent operations

Product

Required software reliability—The degree to which software errors can be tolerated. The range for poor reliability can be from slight inconvenience to risk to human life.

Size of application database—The ratio of the data storage to the program size

Complexity of product—The degree of complexity in the application functions. Simple functions have simple expressions in the computational operations, very little nesting in the control operations, and data management operations that consist of simple arrays in main memory. Complex functions have highly nested control operations, difficult mathematical computations, dynamic data relationships in the data storage, and microcoding for device-dependent operations

Project Use of software tools—The richness in features of the tools being used for development. Tools can be very basic and require additional manual involvement or quite comprehensive with auto­mated design, documentation, and coding components. Application of software engineering methods—The degree of commitment of the staff to using software engineering methods Required development schedule—The significance of the project delivery date, a high rating means that early delivery is very desirable or needed.

Project

Use of software tools—The richness in features of the tools being used for development. Tools can be very basic and require additional manual involvement or quite comprehensive with auto­mated design, documentation, and coding components.

Application of software engineering methods—The degree of commitment of the staff to using software engineering methods

Required development schedule—The significance of the project delivery date, a high rating means that early delivery is very desirable or needed.

You will need to rate each of these cost drivers on a scale from very low to nominal to very high. Each cost driver influences the COCOMO I estimate but not in the same way. For example, if you rated software engineer capability very high the estimate would be reduced, which makes sense: If the team of software engineers is very capable they can complete the project in a shorter period of time.

You will need to rate each of these cost drivers on a scale from very low to nominal to very high.

Each cost driver influences the COCOMO I estimate but not in the same way.

For example, if you rated software engineer capability very high the estimate would be reduced, which makes sense: If the team of software engineers is very capable they can complete the project in a shorter period of time.

Once you have used the function point method and the COCOMOI model to estimate product size, effort, and schedule length, you have some idea of what kind of project you are faced with. If your estimates far exceed the schedule you were given, now is the time to sound the alarm. Accepting an impossible schedule dooms you and the team to failure.

Once you have used the function point method and the COCOMOI model to estimate product size, effort, and schedule length, you have some idea of what kind of project you are faced with.

If your estimates far exceed the schedule you were given, now is the time to sound the alarm.

Accepting an impossible schedule dooms you and the team to failure.

Even if you can't change the schedule, make sure you go on record as having used accepted estimation methods to point out the significant risk of tailing to meet it.

Even if you can't change the schedule, make sure you go on record as having used accepted estimation methods to point out the significant risk of tailing to meet it.