Management: Luca Viganò

Management
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 10.05.11
Luca Vigan (Universit di Verona)
Management
Ing. del SW, 10.05.11
1 / 86
Table of contents
1
Project management Management activities Project planning Project scheduling Risk management Summary of key points Managing people (working as individuals and in groups) Selecting staff Motivating people Managing groups The People Capability Maturity Model Summary of key points
Management
Ing. del SW, 10.05.11
2 / 86
Objectives
To explain the main tasks undertaken by project managers. To introduce software project management and to describe its distinctive characteristics. To discuss project planning and the planning process. To show how graphical schedule representations are used by project management. To discuss the notion of risks and the risk management process.
Management
Ing. del SW, 10.05.11
3 / 86
Project management
Outline
1
Management
Ing. del SW, 10.05.11
4 / 86
Project management
Management activities
Software project management
Concerned with activities involved in ensuring that software is delivered on time and on schedule, and in accordance with the requirements of the organizations developing and procuring the software. Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software.
Management
Ing. del SW, 10.05.11
6 / 86
Project management
Software management distinctions
Software engineering is not recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. Some of the distinctions are:
The product is intangible. The product is uniquely exible. The software development process is not standardized. Many software projects are one-off projects.
Management
Ing. del SW, 10.05.11
7 / 86
Project management
Management activities:
Proposal writing. Project planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations.
Management commonalities:
These activities are not peculiar to software management. Many techniques of engineering project management are equally applicable to software project management. Technically complex engineering systems tend to suffer from the same problems as software systems.
Management
Ing. del SW, 10.05.11
8 / 86
Project management
Project stafng
It may not be possible to appoint the ideal people to work on a project.

Project budget may not allow for the use of highly-paid staff. Staff with the appropriate experience may not be available. An organization may wish to develop employee skills on a software project.
Managers have to work within these constraints especially when there are shortages of trained staff.
Management
Ing. del SW, 10.05.11
9 / 86
Project management
Project planning
Project planning
Probably the most time-consuming project management activity. Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available. Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.
Management
Ing. del SW, 10.05.11
11 / 86
Project management
Project planning
Types of project plan
Quality plan: describes the quality procedures and standards that will be used in a project. Validation plan: describes the approach, resources and schedule used for system validation. Conguration management plan: describes the conguration management procedures and structures to be used. Maintenance plan: predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan: describes how the skills and experience of the project team members will be developed.
Management
Ing. del SW, 10.05.11
12 / 86
Project management
Project planning
Project planning process

Establish the project constraints Make initial assessments of the project parameters Dene project milestones and deliverables while project has not been completed or cancelled loop Draw up project schedule Initiate activities according to schedule Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end if end loop
Luca Vigan (Universit di Verona) Management Ing. del SW, 10.05.11 13 / 86
Project management
Project planning
The project plan
The project plan sets out:

The resources available to the project. The work breakdown. A schedule for the work.
Project plan structure:

Introduction. Project organization. Risk analysis. Hardware and software resource requirements. Work breakdown. Project schedule. Monitoring and reporting mechanisms.
Management
Ing. del SW, 10.05.11
14 / 86
Project management
Project planning
Activity organization
Activities in a project should be organized to produce tangible outputs for management to judge progress. Milestones are the end-point of a process activity. Deliverables are project results delivered to customers. The waterfall process allows for the straightforward denition of progress milestones.
Management
Ing. del SW, 10.05.11
15 / 86
Project management
Project planning
Milestones in the requirements engineering process
Management
Ing. del SW, 10.05.11
16 / 86
Project management
Project scheduling
Project scheduling
Split project into tasks and estimate time and resources required to complete each task. Organize tasks concurrently to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. Dependent on project managers intuition and experience.
Management
Ing. del SW, 10.05.11
18 / 86
Project management
Project scheduling
Scheduling problems
Estimating the difculty of problems and hence the cost of developing a solution is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow contingency in planning.
Management
Ing. del SW, 10.05.11
19 / 86
Project management
Project scheduling
Bar charts and activity networks
Graphical notations used to illustrate the project schedule. Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two. Bar charts show schedule against calendar time. They show who is responsible for each activity and when the activity is scheduled to begin and end. Activity networks show task dependencies and the critical path. They show the dependencies between the different activities making up the project.
Management
Ing. del SW, 10.05.11
20 / 86
Project management
Project scheduling
Example: task durations and dependencies

Activity T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duration (days) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencies
T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)
A hypothetical set of activities, their estimated durations, and their interdependencies. For instance, activity T3 is dependent on activity T1, that is T1 must be completed before T3 starts (e.g. T1 the preparation of a component design, T3 the implementation of that design).
Project management
Project scheduling
Example: activity network
Shows which activities can be carried out in parallel and which must be executed in sequence because of a dependency on an earlier activity. In a sometimes different notation, also called PERT (Program Evaluation and Review Technique) chart. Activities represented as rectangles; milestones and project deliverables are shown with rounded corners. Dates are activity start dates.
Project management
Project scheduling
Act. T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Dur. 8 15 15 10 10 5 20 25 15 15 7 10
Dep.
T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)
All activities in this diagram end in milestones (Mi ): an activity may start when its preceding milestone (that may depend on other activities) has been reached. Before progress can be made from one milestone to another, all paths leading to it must be complete (e.g. when T3 and T6 are nished, then T9 can start). Minimum time required to nish the project can be estimated by considering the longest path in the graph: the critical path is the sequence of dependent activities that denes the time required to complete the project. In this case (emboldened boxes): 11 weeks of elapsed time (or 55 working days).
Project management
Project scheduling
Example (cont.)
The overall schedule of the project depends on the critical path. Any slippage in the completion in any critical activity causes project delays because the following activities cannot start until the delayed activity has been completed. However, delays in activities that do not lie on the critical path do not necessarily cause an overall schedule slippage: so long as these delays do not extend these activities so much that the total time for that activity plus future dependent activities does not exceed the critical path, the project schedule will not be affected. For example, if T8 is delayed by two weeks, it will not affect the nal completion date of the project as it does not lie on the critical path. Most project management tools compute the allowed delays, as shown in the project bar chart. Managers also use activity charts when allocating project work: they can provide insights into activity dependencies that are not intuitively obvious.
Project management
Project scheduling
Example (cont.)
It may be possible to modify the system design so that the critical path is shortened: the project schedule may be shortened because of the reduced amount of time spent waiting for activities to nish. Inevitably, initial project schedules will be incorrect: as a project develops, estimates should be compared with actual elapsed time.
This comparison can be used as a basis for revising the schedule for later parts of the project. When actual gures are known, the activity chart should be reviewed. Later project activities may then be reorganized to reduce the length of the critical path.
Project management
Project scheduling
Activity timeline bar chart

A complementary way of representing project schedule information: a bar chart (also called Gantt chart) showing a project calendar and the start and nish dates of activities. From left to right, the bar chart clearly shows when activities start and end. Shaded bars highlight the exibility in the completion date of these activities: if an activity does not complete on time, the critical path will not be affected until the end of the shaded period. Activities that lie on the critical path have no margin of error and can be identied because they have no associated shaded bar.
Project management
Project scheduling
Staff allocation
In addition to considering schedules, a project manager must also consider resource allocation and, in particular, the allocation of staff to project activities. People dont have to be assigned to a project at all times: during intervening periods they may be on holiday, working on other projects, attending training courses, or engaging in some other activity. Large organizations usually employ a number of specialists who work on a project when needed: e.g. Mary and Jim are specialists who work on only a single project task. This can however cause scheduling problems.
Project management
Risk management
Risk management
Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project. A risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resources. Product risks affect the quality or performance of the software being developed. Business risks affect the organization developing or procuring the software.
Management
Ing. del SW, 10.05.11
29 / 86
Project management
Risk management
Software risks
Risk Staff turnover Management change Hardware unavailability Requirements change Specication delays Size underestimate CASE tool underperformance Technology change Product competition
Affects Project Project Project Project & product Project & product Project & product Product Business Business
Description Experienced staff will leave the project before it is nished. There will be a change of organizational management with different priorities. Hardware that is essential for the project will not be delivered on schedule. There will be a larger number of changes to the requirements than anticipated. Specications of essential interfaces are not available on schedule. The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated. The underlying technology on which the system is built is superseded by new technology. A competitive product is marketed before the system is completed.
Management Ing. del SW, 10.05.11 30 / 86
Project management
Risk management
The risk management process
Risk identication: identify project, product and business risks. Risk analysis: assess the likelihood and consequences of these risks. Risk planning: draw up plans to avoid or minimize the effects of the risk. Risk monitoring: monitor the risks throughout the project.
Project management
Risk management
Risk identication
Technology risks. People risks. Organizational risks. Requirements risks. Estimation risks.
Management
Ing. del SW, 10.05.11
32 / 86
Project management
Risk management
Risks and risk types

Risk type Technology Possible risks The database used in the system cannot process as many transactions per second as expected. Software components that should be reused contain defects that limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Organizational The organization is restructured so that different management are responsible for the project. Organizational nancial problems force reductions in the project budget. Tools The code generated by CASE tools is inefcient. CASE tools cannot be integrated. Requirements Changes to requirements that require major design rework are proposed. Customers fail to understand the impact of requirements changes. Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
Project management
Risk management
Risk analysis
Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignicant.
Risk Organizational nancial problems force reductions in the project budget. It is impossible to recruit staff with the skills required for the project. Key staff are ill at critical times in the project. Software components that should be reused contain defects which limit their functionality. Changes to requirements that require major design rework are proposed. The organization is restructured so that different management are responsible for the project.
Luca Vigan (Universit di Verona) Management
Probability Low High Moderate Moderate Moderate High
Effects Catastrophic Catastrophic Serious Serious Serious Serious
Ing. del SW, 10.05.11
34 / 86
Project management
Risk management
Risk analysis (cont.)
Risk The database used in the system cannot process as many transactions per second as expected. The time required to develop the software is underestimated. CASE tools cannot be integrated. Customers fail to understand the impact of requirements changes. Required training for staff is not available. The rate of defect repair is underestimated. The size of the software is underestimated. The code generated by CASE tools is inefcient.
Probability Moderate High High Moderate Moderate Moderate High Moderate
Effects Serious Serious Tolerable Tolerable Tolerable Tolerable Tolerable Insignicant
Management
Ing. del SW, 10.05.11
35 / 86
Project management
Risk management
Risk planning
Consider each risk and develop a strategy to manage that risk. Avoidance strategies: the probability that the risk will arise is reduced. Minimization strategies: the impact of the risk on the project or product will be reduced. Contingency plans: if the risk arises, contingency plans are plans to deal with that risk.
Management
Ing. del SW, 10.05.11
36 / 86
Project management
Risk management
Risk management strategies
Risk Organizational nancial problems Recruitment problems Staff illness Defective components
Strategy Prepare a brieng document for senior management showing how the project is making a very important contribution to the goals of the business. Alert customer of potential difculties and the possibility of delays, investigate buying in components. Reorganize team so that there is more overlap of work and people therefore understand each others jobs. Replace potentially defective components with bought-in components of known reliability.
Management
Ing. del SW, 10.05.11
37 / 86
Project management
Risk management
Risk management strategies (cont.)
Risk Requirements changes Organizational restructuring Database performance
Strategy Derive traceability information to assess requirements change impact, maximize information hiding in the design. Prepare a brieng document for senior management showing how th e project is making a very important contribution to the goals of the business. Investigate the possibility of buying a higher-performance database.
Underestimated Investigate buying in components, investigate use of a prodevelopment gram generator. time
Management
Ing. del SW, 10.05.11
38 / 86
Project management
Risk management
Risk monitoring
Assess each identied risks regularly to decide whether or not it is becoming less or more probable. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings.
Management
Ing. del SW, 10.05.11
39 / 86
Project management
Risk management
Risk indicators
Risk type Technology People Potential indicators Late delivery of hardware or support software, many reported technology problems. Poor staff morale, poor relationships amongst team member, job availability.
Organizational Organizational gossip, lack of action by senior management. Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations.
Requirements Many requirements change requests, customer complaints. Estimation Failure to meet agreed schedule, failure to clear reported defects.
Project management
Summary of key points

Good project management is essential for project success. The intangible nature of software causes problems for management. Managers have diverse roles but their most signicant activities are planning, estimating and scheduling. Planning and estimating are iterative processes which continue throughout the course of a project. A project milestone is a predictable state where a formal report of progress is presented to management. Project scheduling involves preparing various graphical representations showing project activities, their durations and stafng. Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats.
Managing people (working as individuals and in groups)
Outline
1
Management
Ing. del SW, 10.05.11
43 / 86
Objectives
To explain some of the issues involved in selecting and retaining staff. To describe factors that inuence individual motivation. To discuss key issues of team working including composition, cohesiveness and communications. To introduce the people capability maturity model (PCMM) a framework for enhancing the capabilities of people in an organization.
Management
Ing. del SW, 10.05.11
44 / 86
Selecting staff
People in the process

People are an organizations most important assets. The tasks of a manager are essentially people-oriented: unless there is some understanding of people, management will be unsuccessful. Poor people management is an important contributor to project failure. People management factors: Consistency: team members should all be treated in a comparable way without favorites or discrimination. Respect: different team members have different skills and these differences should be respected. Inclusion: involve all team members and make sure that peoples views are considered. Honesty: you should always be honest about what is going well and what is going badly in a project.
Selecting staff
Selecting staff
An important project management task is team selection. Information on selection comes from:
Information provided by the candidates. Information gained by interviewing and talking with candidates. Recommendations and comments from other people who know or who have worked with the candidates.
Management
Ing. del SW, 10.05.11
47 / 86
Selecting staff
Staff selection case study I

Alice is a software project manager working in a company that develops alarm systems. This company wishes to enter the growing market of assistive technology to help elderly and disabled people live independently. Alice has been asked to lead a team of 6 developers than can develop new products based around the companys alarm technology. Her rst role is to select team members either from software engineers already in the company or from outside. To help select a team, Alice rst assesses the skills that she will need. These are:
1 2
Experience with existing alarm technology as it is reused. User interface design experience because the users are untrained and may be disabled and hence need facilities such as variable font sizes, etc. Ideally, someone who has experience of designing assistive technology systems. Otherwise, someone with experience of interfacing to hardware units as all systems being developed involve some hardware control.
General purpose development skills.

Selecting staff
Staff selection case study II

The next stage is to try and nd people from within the company with the necessary skills. However, the company has expanded signicantly and has few staff available. The best that Alice can negotiate is to have help from an alarm expert (Fred) for 2 days/week. She therefore decides to advertise for new project staff, listing the attributes that shed like:
1
Programming experience in C. She has decided to develop all the assistive technology control software in C. Experience in user interface design. A UI designer is essential but there may not be a need for a full-time appointment. Experience in hardware interfacing with C and using remote development systems. All the devices used have complex hardware interfaces. Experience of working with hardware engineers. At times, it will be necessary to build completely new hardware.
A sympathetic personality so that they can relate to and work with elderly people who are providing requirements for and are testing the system.
Selecting staff
Lessons
Managers in a company may not wish to lose people to a new project. Part-time involvement may be inevitable. Skills such as UI design and hardware interfacing are in short supply. Recent graduates may not have specic skills but may be a way of introducing new skills. Technical prociency may be less important than social skills.
Management
Ing. del SW, 10.05.11
50 / 86
Selecting staff
Staff selection factors I
Application domain experience: For a project to develop a successful system, the developers must understand the application domain. It is essential that some members of a development team have some domain experience. Platform experience: This may be signicant if low-level programming is involved. Otherwise, not usually a critical attribute. Programming language experience: This is normally only signicant for short duration projects where there is not enough time to learn a new language. While learning a language itself is not difcult, it takes several months to become procient in using the associated libraries and components.
Management
Ing. del SW, 10.05.11
51 / 86
Selecting staff
Staff selection factors II
Problem solving ability: This is very important for software engineers who constantly have to solve technical problems. However, it is almost impossible to judge without knowing the work of the potential team member. Educational background: This may provide an indicator of the basic fundamentals that the candidate should know and of their ability to learn. This factor becomes increasingly irrelevant as engineers gain experience across a range of projects. Communication ability: This is important because of the need for project staff to communicate orally and in writing with other engineers, managers and customers.
Management
Ing. del SW, 10.05.11
52 / 86
Selecting staff
Staff selection factors III
Adaptability: Adaptability may be judged by looking at the different types of experience that candidates have had. This is an important attribute as it indicates an ability to learn. Attitude: Project staff should have a positive attitude to their work and should be willing to learn new skills. This is an important attribute but often very difcult to assess. Personality: This is an important attribute but difcult to assess. Candidates must be reasonably compatible with other team members. No particular type of personality is more or less suited to software engineering.
Management
Ing. del SW, 10.05.11
53 / 86
Motivating people
Motivating people
An important role of a manager is to motivate the people working on a project. Motivation is a complex issue but it appears that there are different types of motivation based on: Basic needs: e.g. food, sleep, etc. Personal needs: e.g. respect, self-esteem. Social needs: e.g. to be accepted as part of a group.
Management
Ing. del SW, 10.05.11
55 / 86
Motivating people
Human needs hierarchy
Need satisfaction: Social:

Provide communal facilities. Allow informal communications.
Esteem:
Recognition of achievements. Appropriate rewards.
Self-realization:
Training people want to learn more. Responsibility.
Management
Ing. del SW, 10.05.11
56 / 86
Motivating people
Individual motivation
Alices assistive technology project starts well. Good working relationships develop within the team and creative new ideas are developed. However, some months into the project, Alice notices that Dorothy, the hardware design expert, starts coming into work late, the quality of her work deteriorates and, increasingly, she does not appear to be communicating with other members of the team. Alice talks about the problem with other team members to try to nd out if Dorothys personal circumstances have changed and if this might be affecting her work. They dont know of anything, so Alice decides to talk with Dorothy to try to understand the problem. After denying that there is a problem, Dorothy admits that she seems to have lost interest in the job. She expected a job where she would develop and use her hardware interfacing skills. However, she is basically working as a C programmer with other team members and she is concerned that she is not developing her interfacing skills. She is worried that she will nd it difcult to nd a job after this project that involves hardware interfacing. Because she does not want to upset the team by revealing that she is thinking about the next project, she has decided that it is best to minimize conversation with them.
Motivating people
Personality types
The needs hierarchy is almost certainly an over-simplication of motivation in practice. Motivation should also take into account different personality types: Task-oriented:
The motivation for doing the work is the work itself.
Self-oriented:
The work is a means to an end which is the achievement of individual goals, e.g. to get rich, to play tennis, to travel etc.
Interaction-oriented:
The principal motivation is the presence and actions of coworkers. People go to work because they like to go to work.
Motivating people
Motivation balance
Individual motivations are made up of elements of each class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal factors but also by being part of a group and culture. People go to work because they are motivated by the people that they work with.
Management
Ing. del SW, 10.05.11
59 / 86
Managing groups
Managing groups
Most software engineering is a group activity: The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. Group interaction is a key determinant of group performance. Flexibility in group composition is limited:
Managers must do the best they can with available people.
Management
Ing. del SW, 10.05.11
61 / 86
Managing groups
Factors inuencing group working
Group composition. Group cohesiveness. Group communications. Group organization.
Management
Ing. del SW, 10.05.11
62 / 86
Managing groups
Group composition
Group composed of members who share the same motivation can be problematic: Task-oriented: everyone wants to do their own thing. Self-oriented: everyone wants to be the boss. Interaction-oriented: too much chatting, not enough work. An effective group has a balance of all types. This can be difcult to achieve as software engineers are often task-oriented. Interaction-oriented people are very important as they can detect and defuse tensions that arise.
Management
Ing. del SW, 10.05.11
63 / 86
Managing groups
Group composition (cont.)

In creating a group for assistive technology development, Alice is aware of the importance of selecting members with complementary personalities. When interviewing people, she tried to assess whether they were task-oriented, self-oriented, or interaction-oriented. She felt that she was primarily a self-oriented type as she felt that this project was a way in which she would be noticed by senior management and promoted. She therefore looked for 1 or perhaps 2 interaction-oriented personalities with the remainder task-oriented. The nal assessment that she arrived at was: Alice: self-oriented. Brian: task-oriented. Bob: task-oriented. Carol: interaction-oriented. Dorothy: self-oriented. Ed: interaction-oriented. Fred: task-oriented.
Managing groups
Group leadership
Leadership depends on respect not titular status. There may be both a technical and an administrative leader. Democratic leadership is more effective that autocratic leadership.
Management
Ing. del SW, 10.05.11
65 / 86
Managing groups
Group cohesiveness
In a cohesive group, members consider the group to be more important than any individual in it. The advantages of a cohesive group are:
Group quality standards can be developed. Group members work closely together so inhibitions caused by ignorance are reduced. Team members learn from each other and get to know each others work. Ego-less programming where members strive to improve each others programs can be practised.
Management
Ing. del SW, 10.05.11
66 / 86
Managing groups
Team spirit
Alice is an experienced project manager and understands the importance of creating a cohesive group. As the product development is new, she takes the opportunity of involving all group members in the product specication and design by getting them to discuss possible technology with elderly members of their families and to bring these to the weekly group lunch. The group lunch is an opportunity for all team members to meet informally, talk around issues of concern and, generally, get to know each other. The lunch is organized as an information session where Alice tells the group members what she knows about organizational news, policies, strategies, etc. Each team member then briey summarizes what they have been doing and the group then discusses some general topic such as new product ideas from elderly relatives. Every few months, Alice organizes an away day for the group where the team spend two days on technology updating. Each team members prepares an update on some relevant technology and presents it to the group. This is an off-site meeting in a good hotel and plenty time is scheduled for discussion and social interaction.
Managing groups
Developing cohesiveness
Cohesiveness is inuenced by factors such as the organizational culture and the personalities in the group. Cohesiveness can be encouraged through:
Social events. Developing a group identity and territory. Explicit team-building activities.
Openness with information is a simple way of ensuring all group members feel part of the group.
Management
Ing. del SW, 10.05.11
68 / 86
Managing groups
Group loyalties
Group members tend to be loyal to cohesive groups. Group-think is preservation of group irrespective of technical or organizational considerations. Management should act positively to avoid group-think by forcing external involvement with each group.
Management
Ing. del SW, 10.05.11
69 / 86
Managing groups
Group communications
Group communications are essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions. Good communications also strengthens group cohesion as it promotes understanding. Group size: the larger the group, the harder it is for people to communicate with other group members. Group structure: communication is better in informally structured groups than in hierarchically structured groups. Group composition: communication is better when there are different personality types in a group and when groups are mixed rather than single sex. The physical work environment: good workplace organization can help encourage communications.
Managing groups
Group organization
Small software engineering groups are usually organized informally without a rigid structure. For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.
Management
Ing. del SW, 10.05.11
71 / 86
Managing groups
Informal groups
The group acts as a whole and comes to a consensus on decisions affecting the system. The group leader serves as the external interface of the group but does not allocate specic work items. Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience. This approach is successful for groups where all members are experienced and competent.
Management
Ing. del SW, 10.05.11
72 / 86
Managing groups
Extreme programming groups
Extreme programming groups are variants of an informal, democratic organization. In extreme programming groups, some management decisions are devolved to group members. Programmers work in pairs and take a collective responsibility for code that is developed.
Management
Ing. del SW, 10.05.11
73 / 86
Managing groups
Chief programmer teams
Consist of a kernel of specialists helped by others added to the project as required. The motivation behind their development is the wide difference in ability in different programmers. Chief programmer teams provide a supporting environment for very able programmers to be responsible for most of the system development.
Management
Ing. del SW, 10.05.11
74 / 86
Managing groups
Chief programmer teams: problems
This chief programmer approach, in different forms, has been successful in some settings. However, it suffers from a number of problems:
Talented designers and programmers are hard to nd. Without exceptional people in these roles, the approach will fail. Other group members may resent the chief programmer taking the credit for success so may deliberately undermine his/her role. There is a high project risk as the project will fail if both the chief and deputy programmer are unavailable. The organizational structures and grades in a company may be unable to accommodate this type of group.
Management
Ing. del SW, 10.05.11
75 / 86
Managing groups
Working environments
The physical workplace provision has an important effect on individual productivity and satisfaction:
Comfort. Privacy. Facilities.
Health and safety considerations must be taken into account:

Lighting. Heating. Furniture.
Management
Ing. del SW, 10.05.11
76 / 86
Managing groups
Environmental factors
Privacy: each engineer requires an area for uninterrupted work. Outside: awareness people prefer to work in natural light. Personalization: individuals adopt different working practices and like to organize their environment in different ways.
Management
Ing. del SW, 10.05.11
77 / 86
Managing groups
Workspace organization
Workspaces should provide private spaces where people can work without interruption.
Providing individual ofces for staff has been shown to increase productivity.
However, teams working together also require spaces where formal/informal meetings can be held. Example of ofce layout:
Management
Ing. del SW, 10.05.11
78 / 86
The People Capability Maturity Model
The People Capability Maturity Model PCMM
Intended as a framework for managing the development of people involved in software development. PCMM objectives: To improve organizational capability by improving workforce capability. To ensure that software development capability is not reliant on a small number of individuals. To align the motivation of individuals with that of the organization. To help retain people with critical knowledge and skills.
Management
Ing. del SW, 10.05.11
80 / 86
The People Capability Maturity Model
PCMM levels: ve-stage model

Initial: Ad-hoc people management. Repeatable: policies developed for capability improvement. Dened: standardized people management across the organization. Managed: quantitative goals for people management in place. Optimizing: continuous focus on improving individual competence and workforce motivation.
Management
Ing. del SW, 10.05.11
81 / 86

Staff selection factors include education, domain experience, adaptability and personality. People are motivated by interaction, recognition and personal development. Software development groups should be small and cohesive. Leaders should be competent and should have administrative and technical support. Group communications are affected by status, group size, group organization and the gender and personality composition of the group. Working environments should include spaces for interaction and spaces for private working. The People Capability Maturity Model is a framework for improving the capabilities of staff in an organization.
Example solution of the last homework

The following ne statecharts diagram provides a (still pretty coarse) GUI-model for the three editing modes of CSS, which must be handled by the scheduling manager. The renement (with respect to the coarse model) becomes visible in two major aspects: ROOM_VIEW has now sub-states describing the rough internal behavior. The sub-state ADD_DIALOG represents that a new room has to be entered (detailes like entering room features are omitted in this model). The sub-state UPDATE_DIALOG represents a dialog for changing an existing entry in the room database. Both these dialogs may fail if the user res a cancel -action, or if a violation of the constraints of the data-model is detected (Syntax Error). The default-sub-state VIEW shows (and enables browsing in) the complete room database and offers a delete-action for selected rooms.

CLASS_SCHEDULE_VIEW contains the sub-state VIEW, which enables viewing and browsing in a concrete schedule (i.e. the actual class-schedule variant selected out of the table of schedule variants). An EventOffer may be selected and removed from the actual class-schedule. By setting sorting parameters, a redisplay may be forced. Most essential for this view is the possibility of selecting EventOffer s (ADD_EO) that have not yet been used in a class-schedule. Based on these selections, a new bunch of descendant schedules may be produced when ring the overall CREATE_SCHEDULE-Event. The ne diagram also displays some miscellaneous changes with respect to the coarse one. The LOAD-event of state LOAD_ROOMS may fail in this rened version; moreover, a number of control parameters (like the maximal number of descendant versions of a partial class-schedule that can be generated during the SCHEDULES_INIT-action) may be changed by the user.
Management
Ing. del SW, 10.05.11
86 / 86

Management: Luca Viganò

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Management: Luca Viganò

Diunggah oleh

Hak Cipta:

Format Tersedia

Management

Ingegneria del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Software project management

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Software management distinctions

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

It may not be possible to appoint the ideal people to work on a project.

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Types of project plan

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Project planning process

The project plan

The project plan sets out:

Project plan structure:

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Milestones in the requirements engineering process

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Bar charts and activity networks

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Example: task durations and dependencies

Example: activity network

Act. T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

Activity timeline bar chart

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

The risk management process

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Risks and risk types

Probability Low High Moderate Moderate Moderate High

Effects Catastrophic Catastrophic Serious Serious Serious Serious

Ing. del SW, 10.05.11

Risk analysis (cont.)

Probability Moderate High High Moderate Moderate Moderate High Moderate

Effects Serious Serious Tolerable Tolerable Tolerable Tolerable Tolerable Insignicant

Luca Vigan (Universit di Verona)

Ing. del SW, 10.05.11

Luca Vigan (Universit di Verona)