project management

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.

• 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.

• 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 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.

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.

– 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.

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).

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.

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.

• 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.

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.

• 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.

• 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.

• 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).

Useful Work

Thrashing without a process

100%

0%

2 People100 people

Thrashing as team size increases when no process is specified

100 people2 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.

• 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.

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

SoftwareConcept

RequirementsDevelopment

ArchitecturalDesign

Stage 1:Detailed Design, Construction and release

Stage 2:Detailed Design, Construction and release

Stage 3:Detailed Design, Construction and release

SoftwareRelease

Staged Implementation Model

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

– 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 itemsand 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 andclassifying 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.

– 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.

– 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.

• 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.

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, andrelatively 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:

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

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

3. 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).

• 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:

1. 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

2. 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

3. 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 microcodingfor device-dependent operations

4. 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.

• 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.