軟件項(xiàng)目管理

前言

Preparing the fifth edition of this book has reminded us that project management is not just a crucial element in successful software and IT development, but is also a fascinating topic in its own right. It is an intriguing mixture of the technical and the very human, of the rational and also the intuitive. Initially we offered this topic as an ancillary discipline for software engineers and IT practitioners. We have, however, become increasingly convinced that the discipline should have a more central role: that the question of how systems are implemented is a vital one to be asked at the same time as that of what a system is to do. Not many software books have lasted as long as this one. Clearly the principles of project management are less transient than those of software design and implementation,which have gone through some very major developments over recent years. However,project management has not been immune from change. One development has been the growth in project management bodies of knowledge such as those of the Project Management Institute (PMI) in the United States and the Association for Project Management (APM) in the United Kingdom. There has also been the development of project management standards such as PRINCE2. These developments are to be welcomed as externalizing and codifying good practice - indeed we have included an appendix on PRINCE2. However, we have resisted becoming a 'PMI' book or a 'PRINCE2' book. Partly this is because we believe that software project management, while incorporating all the key elements of generic project management, also has to deal with the peculiar problems associated with creating software. These include the relative intangibility of software, its extreme malleability, the intimate relationship it has with the systems within which it is embedded, and its sheer complexity. We also wanted to avoid means-end inversion where there was a focus on the recall of specific terminology and procedural detail at the expense of an understanding of underlying concepts and purpose. One new development that has been taken on board has been the growing awareness that a project is rarely an isolated activity but is almost always part of a broader programme of work aimed at meeting organizational and business objectives There are also agile approaches, such as extreme programming, which have been a timely reminder that software development is an intensely human activity. In contrast to this emphasis on the highly productive, highly interactive co-located team, there is also a growth of dispersed or virtual projects where all or part of the development team is in another country or even continent. We noted these developments in previous editions but have expanded their treatment in this one this greater emphasis on development team dynamics has led to the creation of a chapter devoted solely to these topics. One major problem has been the conflict between a desire to include all the topics that our reviewers would like to see and the desire for a concise volume that avoids 'bloating'.Sometimes there are topics and standards which appear to be current and of which one feels people should be aware. On closer inspection, the material for various reasons is less useful or relevant than one hoped. In this edition we have dropped an appendix on the British standard BS6079. This is because the new version of this has become what is essentially a general advisory guide on project management practice. As such it duplicates material already covered in this book. Some individual topics have also been dropped because it was felt that they really needed a deeper treatment better conveyed by a more specialist publication than this one: the internal rate of return (IRR) in project evaluation and the Hofstede analysis of national cultural characteristics are examples. In general,though, we have erred on the side of caution in retaining topics. It seems a long time since the first, rather slim, edition published in 1995. As novice authors, Cotterell and Hughes were very indebted to Dave Hatter and Martin Campbell Kelly who had a huge influence on the style of the book. Dave Hatter in particular emphasized the need for each chapter to have clear learning objectives: ideally the reader should finish the chapter feeling they had learnt a new skill. He also instilled the need to explain things clearly - to feel confident in using simple words to explain things that might at first appear complicated. We are aware that we have not always lived up to these values-and have been taken to task by our students and teachers from other institutions who have kindly acted as reviewers.

內(nèi)容概要

本書是經(jīng)典的項(xiàng)目管理課程教材。本版延續(xù)上一版清晰、易懂的敘述風(fēng)格，采用步進(jìn)式策劃方法逐一分析了軟件開發(fā)的各個(gè)環(huán)節(jié)，并通過豐富的實(shí)例和練習(xí)來闡明實(shí)踐過程中軟件項(xiàng)目管理的原則?！　”緯粌H適合作為計(jì)算機(jī)及相關(guān)專業(yè)的本科生和研究生的教材，而且適合于軟件項(xiàng)目管理人員和軟件開發(fā)人員閱讀，還特別適合作為BCS/ISEB專業(yè)考試的參考書?！　榱撕w軟件項(xiàng)目管理的新進(jìn)展，本版進(jìn)行了全面更新，新增和擴(kuò)展的主題如下：　　溝通策劃?！　∶艚莘椒ǎ╔P（極限編程）、Scrum 和 DSDM。　　COCOMO II。　　項(xiàng)目組合管理?！　⌒略鲆徽拢饕顷P(guān)于合作、分散和虛擬團(tuán)隊(duì)管理。　　職業(yè)道德規(guī)范。

作者簡(jiǎn)介

Bob Hughes曾在產(chǎn)業(yè)界和高等教育界擔(dān)任各種職務(wù)，現(xiàn)在是英國(guó)布萊頓大學(xué)信息管理學(xué)院信息系統(tǒng)部的負(fù)責(zé)人。他還是BCS/ISEB項(xiàng)目管理認(rèn)證考試的主考官和相關(guān)培訓(xùn)課程的主講老師。

書籍目錄

Preface Guided tour Acknowledgements I Introduction to software project management 　1.1 Introduction 　1.2 Why is software project management important? 　1.3 What is a project? 　1.4 Software projects versus other types of project 　1.5 Contract management and technical project management 　1.6 Activities covered by software project management 　1.7 Plans, methods and methodologies 　1.8 Some ways of categorizing software projects 　1.9 Stakeholders 　1.10 Setting objectives 　1.11 The business case 　1.12 Project success and failure 　1.13 What is management? 　1.14 Management control 　1.15 Conclusion 　Annex 1 Contents list for a project plan 　1.16 Further exercises 2 Project evaluation and programme management 　2.1 Introduction 　2.2 A business case 　2.3 Project portfolio management 　2.4 Evaluation of individual projects 　2.5 Cost-benefit evaluation techniques 　2.6 Risk evaluation 　2.7 Programme management 　5.8 Managing the allocation of resources within programmes 　2.9 Strategic programme management 　2.10 Creating a programme 　2.11 Aids to programme management 　2.12 Some reservations about programme management 　2.13 Benefits management 　2.14 Conclusion 　2.15 Further exercises 3 An overview of project planning 　3.1 Introduction to Step Wise project planning 　3.2 Step O: Select project 　3.3 Step 1: Identify project scope and objectives 　3.4 Step 2: Identify project infrastructure 　3.5 Step 3: Analyse projec characteristics 　3.6 Step 4: Identify project products and activities 　3.7 Step 5: Estimate effort for each activity 　3.8 Step 6: Identify activity risks 　3.9 Step 7: Allocate resources 　3.10 Step 8: Review/publicize plan 　3.11 Steps 9 and10: Execute plan/lower levels of planning 　3.12 Conclusion 　3.13 Further exercises 4 Selection of an appropriate project approach 　4.1 Introduction 　4.2 Build or buy? 　4.3 Choosing methodologies and technologies 　4.4 Choice of process models 　4.5 Structure versus speed of delivery 　4.6 The waterfall model 　4.7 The spiral model 　4.8 Software prototyping 　4.9 Other ways of categorizing prototypes 　4.10 Incremental delivery 　4.11 Agile methods 　4.12 Atern/Dynamic Systems Development Method 　4.13 Extreme programming (XP) 　4.14 Managing iterative processes 　4.15 Selecting the most appropriate process model 　4.16 Conclusion 　4.17 Further exercises 5 Software effort estimation 　5.1 Introduction 　5.2 Where are estimates done? 　5.3 Problems with over- and under- estimates 　5.4 The basis for software estimating 　5.5 Software effort estimation techniques 　5.6 Bottom-up estimating 　5.7 The top-down approach and parametric models 　5.8 Expert judgement 　5.9 Estimating by analogy 　5.10 Albrecht function point analysis 　5.11 Function points Mark Il 　5.12 COSMIC full function points 　5.13 COCOMO 13: a parametric productivity model 　5.14 Conclusion 　5.1 5 Further exercises 6 Activity planning 　6.1 Introduction 　6.2 The objectives of activity planning 　6.3 When to plan 　6.4 Project schedules 　6.5 Projects and activities 　6.6 Sequencing and scheduling activities 　6.7 Network planning models 　6.8 Formulating a network model 　6.9 Adding the time dimension 　6.10 The forward pass 　6.11 The backward pass 　6.12 Identifying the critical path 　6.1 3 Activity float 　6.14 Shortening the project duration 　6.1 5 Identifying critical activities 　6.16 Activity-on-arrow networks 　6.1 7 Conclusion 　6.16 Further exercises 7 Risk management 　7.1 Introduction 　7.2 Risk 　7.3 Categories of risk 　7.4 A framework for dealing with risk 　7.5 Risk identification 　7.6 Risk assessment 　7.7 Risk planning 　7.8 Risk management 　7.9 Evaluating risks to the schedule 　7.10 Applying the PERT technique 　7.11 Monte Carlo simulation 　7.1 2 Critical chain concepts 　7.1 3 Conclusion 　7.14 Further exercises 8 Resource allocation 　8.1 Introduction 　8.2 The nature of resources 　8.3 Identifying resource requirements 　8.4 Scheduling resources 　8.5 Creating critical paths 　8.6 Counting the cost 　8.7 Being specific 　8.8 Publishing the resource schedule 　8.9 Cost schedules 　8.10 The scheduling sequence 　8.11 Conclusion 　8.12 Further exercises 9 Monitoring and control 　9.1 Introduction 　9.2 Creating the framework 　9.3 Collecting the data 　9.4 Visualizing progress 　9.5 Cost monitoring 　9.6 Earned value analysis 　9.7 Prioritizing monitoring 　9.8 Getting the project back to target 　9.9 Change control 　9.10 Conclusion 　9.11 Further exercises 10 Managing contracts 　10.1 Introduction 　10.2 Types of contract 　10.3 Stages in contract placement 　10.4 Typical terms of a contract 　10.5 Contract management 　10.6 Acceptance 　10.7 Conclusion 　10.8 Further exercises 11 Managing people in software environments 　11.1 Introduction 　11.2 Understanding behaviour 　11.3 Organizationbehaviour: a backgrou nd 　11.4 Selecting the right person for the job 　11.5 Instruction in the best methods 　11.6 Motivation 　11.7 TheOIdham Hackman job characteristics nrodel 　11.8 Stress 　11.9 Health and safety 　11.10 Some ethical and professional concerns 　11.11 Conclusion 　11.12 Further exercises 12 Working in teams 　12.1 Introduction 　12.2 Becoming a team 　12.3 Decision making 　12.4 Organizational structures 　12.5 Coordination dependencies 　12.6 Dispersed and virtual teams 　12.7 Communication genres 　12.8 CommunicationpJans 　12.9 Leadership 　12.10 Conclusion 　12.11 Further exercises 13 Software quality 　13.1 hrtroduc'tion 　13.2 iheplaceofsoftwarequalityin project planning 　13.3 The importance of software quality 　13.4 Defining software quality 　13.5 ISO 9126 　13.6 Product versus process quality management 　13.7 Quality management systems 　13.8 Process capability models 　13.9 Techniques to help enhance software quality 　13.10 resting 　13.11 Quality plans 　13.12 Conclusion 　13.13 Further exercises Appendix A PRINCE2 - an overview Appendix B Answer pointers Further reading Index

章節(jié)摘錄

插圖：The feasibility study assesses whether a project is worth starting -that it has a valid business case. Information is gathered about therequirements of the proposed application. Requirements el icitationcan, at least initially, be complex and difficult. The stakeholders mayknow the aims they wish to pursue, but not be sure about the means ofachievement. The developmental and operational costs, and the valueof the benefits of the new system, will also have to be estimated. With a large system,the feasibility study could be a project in its own right with its own plan. The studycould be part of a strategic planning exercise examining a range of potential softwaredevelopments. Sometimes an organization assesses a programme of developmentmade up of a number of projects.

編輯推薦

《軟件項(xiàng)目管理(英文版·第5版)》：經(jīng)典原版書庫(kù)

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

    軟件項(xiàng)目管理 PDF格式下載

---