1 / 18

Project Management

Project Management. Instructor: Dr. Jerry Gao. Project Management. - The Management Spectrum - People - The Players - Team Leaders - The Software Team - Coordination and Communication Issues - The Problem - Software Scope - Problem Decomposition - The Process

denis
Télécharger la présentation

Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project Management Instructor: Dr. Jerry Gao

  2. Project Management - The Management Spectrum - People - The Players - Team Leaders - The Software Team - Coordination and Communication Issues - The Problem - Software Scope - Problem Decomposition - The Process - Melding the Problem and the Process - Process Decomposition - The Project (the 90-90 rule) Jerry Gao, Ph.D. Jan. 1999

  3. The Management Spectrum - People - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - People: Software engineering work is an intensely human endeavor. A people management capability maturity model (PM-CMM) --> key practice areas for software people: - recruiting, selection, performance, management, training, compensation, career development, organization and work design, and team/culture development The most important contributor to a successful software project --> having smart people with good skills Organizations with high levels of maturity in the people management ---> implementing effective software engineering practice

  4. The Management Spectrum - The Problem - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - Problem (related to a project): Before starting a project, we need to define and identify its - Objectives and scope - Alternative solutions - Technical and management constraints Considering other factors: delivery deadlines, budgetary restrictions, personnel availability technical interfaces, and so on. Without these information, it is impossible - To define reasonable estimates of the cost - To conduct an effective assessment of risk - To do realistic breakdown of project tasks - To come out a manageable project schedule

  5. The Management Spectrum - The Process - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - Process: A software process provides the framework --> a comprehensive plan for software development A number of different tasks sets applicable to all software projects: - tasks, milestones, deliverables, and quality assurance points Umbrella activities -> occurs throughout the process: - software quality assurance - software configuration management - measurement

  6. People - The Players - In a software process, there are five types of players: - Senior managers, who defines the business issues. (strong influence on the project) - Practitioners, who deliver the technical skills for engineering software - Project (technical) managers, who must plan. Motivate, organize and control the practitioners. - Customers, who specify the requirements for the software. - End users, who interact with the software once it is released for use.

  7. People - Team Leaders - Project management is a people-intensive activity. How to select a good team manager? MOI model of leadership suggested by Jerry Weinberg [WEi86]: - Motivation - the ability to encourage technical people. - Organization - the ability to mold existing processes that will enable initial concept to be translated into a final product. - Ideas or innovation - the ability to encourage people to create and feel creative. Software managers should concentrate on - understanding the problem to be solved, - managing the flow of ideas, - letting everyone on the team know that quality counts. Four important key traits to be an effective project manager: - Problem solving - Managerial identity - Achievement - Influence and team building

  8. People - The Software Team Mantei [MAN81] suggests three generic team organizations: - Democratic decentralized (DD): - the software engineering team has no permanent leader. - decision is made by group consensus. - communication among team members is horizontal. - Controlled decentralized (CD): - has a leader -> coordinates specific tasks and secondary leaders. - secondary leaders have responsibility for subtasks. - horizontal communications among subgroups and individuals. - vertical communication in the control structure - decision is made by leaders. - Controlled centralized (CC): - team leader manages top-level problem solving and internal team coordination. - communication between the leader and team members is vertical.

  9. People - The Software Team DD: group CC: Team leader DC: Team leader secondary team leader communication group group

  10. People - The Software Team Functional tasks FT1 FTm X P1 X X X X Pn X Project manager + n engineers + m tasks team engineer FT1 FTm T1 Tm X X P1 P1 X X Pn X X X Pn X Project manager + team leaders Project manager+ informal teams with coordinator

  11. People - The Software Team Mantie’s seven project factors related to project team structure: - the difficulty of the problem to be solved. - the size of the resultant programs - the modularity of problem - the reliability of the software - the team life time - the rigidity of the delivery date - the degree of sociability (communication overhead) Team Type DD CD CC Difficulty High Low Low Size Small Large Large Team Life Time Long Short Short Modularity Low High High Reliability High High Low Delivery date Lax Lax Strict Sociability High Low Low

  12. People - The Software Team Constantine [CON’93] suggests four “organization paradigms” for software engineering teams: - A closed paradigm: a team with a traditional hierarchy of authority (like CC) - The random paradigm: a team loosely and depends on individual initiative of the team members - The open paradigm: heavy communication + control structure like CC - The synchronous paradigm: relies on the nature compartmentalization of a problem + little active communications Chief programmer team (by Harlan Mills described in Baker’s [BAK72]) : a senior engineer (1), technical staff (2-5), a backup engineer, support staff (e.g. technical writers), software librarian (1). Book “Peopleware” by DeMarco and Lister discussed “jelled team”: A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts… They don’t need managed in a traditional way, they don’t need to be motivated. They got momentum.

  13. People - Coordination and Communication Issues Many failure causes of a software project. Here are some of them related to communications and coordination of a project: - The large scale of development efforts --> complexity, confusion, and significant difficulties in coordination of teams. - Uncertainty is common due to the changes of requirements and team status - Interoperability --> interoperations among systems Good and effective formal and informal communication mechanisms: - Formal impersonal approaches documents, deliverables, memos, project milestones, schedules, project control tools, change requests, and related documents, error tracking reports and data. - Formal, interpersonal procedures quality assurance activities (code & design inspection, review meeting) - Informal, interpersonal procedures informal group meeting (such as meeting with customers and users) - Electronic communication (email, web sites, video-based conference) - Interpersonal network

  14. Problem - Software Scope A software project manager is confronted with a dilemma at the beginning of a software engineering project. - Software scope: (a) Context: - How does the software to be built fit into a large system, product, or business? - What constraints are imposed as a result of the context? (b) Information objectives: - What customer-visible data objects are produced as output from the software? - What data objects are required for input? ( c) Function and performance: - What function does the software perform to transform input data into output? - Are any special performance characteristics to be addressed?

  15. Problem Decomposition Problem decomposition --> problem partitioning. Problem decomposition --> two areas: - the functionality of the delivery software system - the process that will be used to deliver the system - Functional decomposition: - Identify and define the functional scope of the system in terms of functional features and/or sub-functional systems. - Apply decomposition method on each feature. An example of the function features for a word processing system: - spell checking - sentence grammar checking - reference checking for large documents - section and chapter reference validation for large documents.

  16. Process - Melding the Problem and the Process Each function to be engineered by the software team must pass through the set of framework activities: - customer communication - tasks to establish effective communications with customers. - planning - tasks to define resources, timelines, an so on. - risk analysis - tasks to assess both technical and management risks. - engineering - tasks to build the application system - construction and release - installation, release control, and customer support. - customer evaluation - task to obtain customer feedback and evaluation result. Process decomposition: - Select a software process model for the project. - Define a preliminary project plan based on the set of common process framework activities. - Partition the software process based on the tasks and activities common process framework (CPF)

  17. Process - Process Decomposition Each function to be engineered by the software team must pass through the set of framework activities: - customer communication - tasks to establish effective communications with customers. - planning - tasks to define resources, timelines, an so on. - risk analysis - tasks to assess both technical and management risks. - engineering - tasks to build the application system - construction and release - installation, release control, and customer support. - customer evaluation - task to obtain customer feedback and evaluation result. Process decomposition: - Select a software process model for the project. - Define a preliminary project plan based on the set of common process framework activities. - Partition the software process based on the tasks and activities common process framework (CPF)

  18. Process - Process Decomposition A small project may require the following work tasks: - Develop list of clarification issues. - Meet with customer to address clarification issues. - Jointly develop a statement of scope. - Review the state of scope with all concerned. - Modify the statement of scope as required. A complex project may require the following work tasks: - Review the customer request. - Plan and schedule a formal, facilitated meeting with the customer. - Conduct research to define proposed solutions and existing approaches. - Prepare a “working document” and an agenda for the formal meeting. - Conduct the meeting. - Jointly develop mini-spec for correctness, consistency, and lack of ambiguity. - Assemble the min-specs into a scoping document. - Review the scoping document with all concerned. - Modify the scoping document as required.

More Related