软件工程师管理简介
不同的项目各有其特点，因此需要不同的流程模式。
3、项目机构：项目与其他实体以及项目机构之间的关系，均由项目机构来处理。同时，该项目与用户团体、机构总部，很可能与别的机构都有联系。
潜在用户将时刻与项目紧密相连，项目计划明确了用户要提供什么信息，需要为用户提供什么服务以及所配备的设施，以及何时提供。
在项目团体中，形形色色的角色被认定：项目经理，测试员，程序设计员，分析员等等。每个人都必须清楚地描述这些角色以及鉴定各自的职责。如果现有的知识难以满足工作需要时，训练与教育在此时就需要被认定了。不同形式的组织在第五章中有介绍。
4、标准、指导方针、程序： 软件工程是一项庞大的工程。通常情况下，很多都与软件工程紧密相连。因此，这需要一种严格的纪律制度，并且在这种纪律制度下每个人都必须遵守该标准、指导以及程序。除了条文规定，也可以通过工具来支持或是强制实行。其中最重要的是有关文件的明确指示；当文件被传送时，文件质量经过评估，如何确保文件能够跟随潮流？
最大限度来讲：这些标准和程序将在不同文件中阐述，比如说配置控制计划或者是质量保证计划。
5、管理活动是由重大事情及目标所引导的。例如：管理必须提交常规报告，这些报告是有关程序的重要性及其进展。这必将遵循平衡需要、花销、工作计划。
6、潜在危机必须尽可能快的被认定。危机时刻存在：硬件不能及时被传送，合格人选在需要时却不合适，当需要信息时却缺乏不足，如此种种。软件发展项目进展顺利，这种说法很容易让人轻信。甚至在比较好的创业领域中，比如说结构，通常很容易出错。我们应该尽早探究软件工程中所存在的风险，并且提供处理方法，详见第八章。
软件工程中越多不确定，多变的因素，其中的危险越大。
2·1软件发展工程的计划
7、工作人员： 在不同的时间，该项目将需要不同数量的人员及不同的技巧。在一开始，期
限数量以及专业知识的人员要分类列出各自的本项。
8、方法与技巧：在本项的方法和技术上，主要用于在需求工程，设计，执行及测试中结出。通常，该版本和配制方式的软件组件控制在这里也有描述情况。技术文件的大部分将在这阶段产生。因此，国家应该重视这样的文件。测试环境及测试设备的必要性已被提到过。在测试过程中，测试设备中通常会有相当大的压力。因此，这项活动必须经过周密的计划。组件一体化测试也应该有明确说明。此外，在测试当中应遵循相应的程序，测试也要在使用者的监督下才能进行。第十三章我们将对测试进行讨论。
9、质量保证： 哪个组织和程序敢保证软件的发展能满足现在的质量需求呢？质量保证计划中的很多方面，对个别特殊文件也进行处理。第六章将对质量保证的主题进行讨论。
10、工作计划包： 再大的工程也必须切实到具体的实际活动中，易掌控的小型工程应交由个人团体成员负责。每项活动都必须在工程计划中有所体现。该项目的层次分解是在工作分解结构中描述的。（另见8·4）
11、资源： 在每项工程中都需要大量的资源。为了支持该工程，还需要些硬件、CPU周期及一些工具，且这些都在本项中列举出来。
12、预算和进度：该项目的总预算应该在各项活动中都给予适当的分配，且各活动都应有相应的分解结构显示框架。活动应按预定的时间进行。如使用PERT图（见8·4节）。在本项安排显示的情况下，对资源和其他支出方面要进行跟踪调查。成本和时间估算的主题将在
第七章主要讲解。
13、改变：之前已表明改变是不可避免的。一要保证这些变化有序的处理，一要对拟议的
改革程序进行明确的处理。假如每一个过程都很快完成，每一个改变都能涉及到，那么这些将会很轻松的完成。事实上，他们不能看作是改变了。在后来更重要的的过程中，每个提议的改变都必须登记和审查。当一个请求获得批准，那它的影响即成本，必须得事先估计。
最后，这些改变将被体现在工程上。如果改变没经核实检验而进行，那么该工程将会导致严重的结构代码错误、没有足够可参考的文件以及可能会有费用和时间上的超支现象。因为变化将导致双方文档和代码都有不同的版本。应遵守规定的程序，在处理这些变化时往往注意要在配置的控制范围内进行。
14、传递：向客户移交系统时应遵循的程序必须提前声明。
工程计划的目的就是给顾客及工程队提供清晰的工程示意图。如果目标不明确，那么该计划将无法完成。尽管计划很周密，在开工期间也会出现之前无法预料的困难。无论如何，周密的计划总会减少些突出状况，也会减少这些突发状况的发生。工程计划毕竟解决了好多未来事件中可能发生的好多问题。计划提供了这些事件准确的解决方法。以致于达到更准确的预计效果。
