第二部分软件工程项目管理职业道德范文.docx

第二部分软件工程项目管理职业道德范文.docx

《第二部分软件工程项目管理职业道德范文.docx》由会员分享，可在线阅读，更多相关《第二部分软件工程项目管理职业道德范文.docx（10页珍藏版）》请在冰豆网上搜索。

第二部分软件工程项目管理职业道德范文

1软件开发模型-瀑布模型（需求明确）/原型模型（需求不明确）/螺旋模型（快速占领市场）

2软件测试W模型（什么阶段对应什么工作？

）

3常见的软件开发语言：

JAVA、j2ee、.Net、C/C++/C#、JSP、ASP、PHP等等多种语言查询各自的特点。

4立项阶段的主要工作内容

（1）立项准备:

在应用驱动下，经过调查研究和需求分析，准确描述出项目的目标和可交付的成果。

（2）立项申请:

形成立项申请书或者更细化地分成项目建议书和项目可行性研究报告。

（3）立项审批:

根据业务需求、预定目标、可行性、资金实力、效益分析等要素进行。

（4）招投标及合同签订:

进行招标（邀标）、投标、评标（议标）、商务谈判，选定信息系统集成商和信息系统监理单位签订合同。

5项目质量管理的构成-项目质量管理由质量计划编制、质量保证和质量控制三方面构成。

Iso900是企业标准与工程无关

6三方协同的项目管理

7风险识别--首先要识别风险来源，由此可预测风险事件的发生与识别风险症状。

在立项、人员、计划、质量、成本、进度、合同、安全、技术、外包外购、沟通协调等各管理要素中都对应着可能的风险条件。

可采用流程图（或称鱼刺图）和访谈等工具、方法帮助我们识别风险。

8风险分析-风险分析是一种评价风险的过程，帮助项目管理人员决定在具体的风险面前采取什么态度:

应对?

接受?

还是忽略?

要尽量采用量化方法进行风险分析。

通过量化分析，项目管理人员能够按优先顺序排列风险，并建立一个阐值，以决定哪种风险应受到重视。

9风险应对

（1）应对风险的三项基本措施:

规避、接受和减轻。

（2）制定风险应对计划并执行，包括:

风险管理计划、应急计划和应急储备。

10风险控制--风险控制包括:

随时追踪风险己经、正在和将要发生的变化;预测和判断风险的应对是否会引起更新的风险发生;对用于风险管理的资源配置进行调整;调整风险应对计划;采取临时紧急应变措施等。

11UML提供了九种不同的图，分为静态图和动态图两大类。

静态图包括用例图、类图、对象图、组件图和配置图，动态图包括序列图、状态图、协作图和活动图。

（1）用例图（Usecasediagram）

用例图描述系统的功能，由系统、用例和角色（Actor）三种元素组成。

图中显示若干角色以及这些角色和系统提供的用例之间的连接关系。

用例是系统对外提供的功能的描述，是角色和系统在一次交互过程中执行的相关事务的序列。

角色是与系统、子系统或类交互的外部人员、进程或事物。

用例之间存在扩展、使用和组合三种关系。

角色之间可以用通用化关系将某些角色的共同行为抽象为通用行为。

在UML中，用例图是用例视图的重要组成部分。

（2）类图（Classdiagram）

类图用来表示系统中的类以及类与类之间的关系，描述系统的静态结构，用于逻辑视图中。

类是对象的抽象描述。

所谓对象就是可以控制和操作的实体，类是具有共同的结构、行为、关系、语义的一组对象的抽象。

类的行为和结构特征分别通过操作和属性表示。

类与类之间有多种关系，如关联、依赖、通用化、聚合等。

关系提供了对象之间的通信方式。

关联关系用于描述类与类之间的连接，通常是双向的•通用化又称继承，是通用元素和具体元素之间的一种分类关系，具体元素完全拥有通用元素的信息，并且还可以附加其他信息。

聚合关系具有较强的耦合性，描述整体与部分的关系。

依赖关系描述两个模型元素之间语义上的连接关系，其中一个元素是独立的，另一个元素依赖于独立的模型元素，独立元素的变化将影响到依赖元素。

（3）对象图（Objectdiagram）

对象图是类图的示例，类图表示类和类与类之间的关系，对象图则表示在某一时刻这些类的具体实例以及这些实例之间的具体连接关系，可以帮助人们理解比较复杂的类图。

对象图也可以用于显示类图中的对象在某一点的连接关系。

对象图常用于用例视图和逻辑视图中。

（4）状态图（Statediagram）

状态图主要用来描述对象、子系统、系统的生命周期。

通过状态图可以了解一个对象可能具有的所有状态、导致对象状态改变的事件，以及状态转移引发的动作。

状态是对象操作的前一次活动的结果，通常由对象的属性值来决定。

事件指的是发生的且引起某些动作执行的事情。

状态的变化称做转移，与转移相连的动作指明状态转移时应该做的事情。

状态图是对类描述的事物的补充说明，用在逻辑视图中描述类的行为。

（5）序列图（Sequencediagram）

面向对象系统中对象之间的交互表现为消息的发送和接收。

序列图反映若干个对象之间的动态协作关系，即随着时间的流逝，消息是如何在对象之间发送和接收的。

序列图表现为二维的形式，其中的纵坐标轴显示时间，横坐标轴显示对象。

序列图中重点反映对象之间发送消息的先后次序，常用在逻辑视图中。

（6）协作图（Collaborationdiagram）

协作图主要描述协作对象之间的交互和链接。

协作图和序列图同样反映对象间的动态协作，也可以表达消息序列，但重点描述交换消息的对象之间的关系，强调的是空间关系而非时间顺序。

（7）活动图（Activitydiagram）

活动图显示动作及其结果，着重描述操作实现中所完成的工作以及用例实例或对象中的活动。

活动图中反映了一个连续的活动流，常用于描述一个操作执行过程中所完成的工作。

活动图也有其他的用途，如显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象，说明一次商务活动中的工人、工作流、组织和对象是如何工作的等。

（8）组件图（Componentdiagram）

组件图用来反映代码的物理结构。

组件可以是源代码、二进制文件或可执行文件，包含逻辑类的实现信息。

实现视图由组件图构成。

（9）配置图（Deploymentdiagram）

配置图用来显示系统中软件和硬件的物理架构。

图中通常显示实际的计算机和设备

及它们之间的关系。

配置图用来构成配置视图，描述系统的实际物理结构。

12软件配置管理质量要求--软件配置管理项是该软件的真正实质性材料，因此必须保持正确性、完备性和可追踪性。

任何软件配置管理项都必须做到“文实相符、文文一致”，以满足“有效性”、“可见性”和“可控性”要求。

13配置管理项--在软件生存周期内所产生的各种管理文档和技术文档、源代码列表和可执行代码，以及运行所需的各种数据，构成软件配置管理项。

14配置管理库--各系统应在其所属各级中建立下列各库。

1.开发库（DL）通常，开发库可仅在项目开发组内设立，并由其负责维护。

2.受控库（CL）通常，受控库以软件配置项为单位建立并维护。

3.产品库（PL）通常，产品库可在系统、子系统级上设立并维护。

各类库中应存放哪些软件成分，应视所开发软件的实际情况酌

15软件配置管理管理规程

软件配置项不论大小都必须实施软件配置管理。

但所管软件实体的多少，实施控制的方式和投入人力多少则与软件配置项的规模等级、安全性关键等级，以及风险大小有关。

必须指出，对于安全性关键等级为A,B级的软件配置项的管理必须从严。

每个计算机系统均应制定软件配置管理规程，至少应明确规定:

（1）各级、各库中所管的软件实体的清单。

（2）保证安全性、可靠性、保密性、正确性、完备性、一致性和可追踪性的具体措施。

（3）入库控制办法和审批手续。

（4）出库条件及其必备的手续。

（5）变更控制办法和审批手续。

16软件测试的目的

（1）通过测试，发现软件错误。

（2）验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及其软件质量特性的要求。

（3）为软件质量的评价提供依据。

17代码审查（包括代码评审和走查）主要依靠有经验的程序设计人员根据软件设计文档，通过阅读程序，发现软件错误和缺陷。

代码审查一般按代码审查单阅读程序，查找错误。

代码审查的内容包括:

检查代码和设计的一致性;检查代码的标准性、可读性:

检查代码逻辑表达的正确性和完整性;检查代码结构的合理性等。

代码审查虽然在发现程序错误上有一定的局限性，但它不需要专门的测试工具和设备，且有一旦发现错误就能定位错误和一次发现一批错误等优点。

18测试组织

《1.软件测试阶段

（1）计算机软件单元测试。

适用对象为任一计算机软件单元

（2）计算机软件集成测试。

适用对象为由计算机软件单元组装得到的计算机软件部件。

（3）计算机软件确认测试。

适用对象为完整的软件。

（4）系统测试。

适用对象为整个计算机系统，包括硬件系统和软件系统。

在软件生存周期各阶段，应开展的软件测试活动如表19-2所示。

《2.测试组织--软件测试应由独立于软件设计开发的人员进行，根据软件项目的规模等级和安全性关键等级，软件测试可由不同机构组织实施。

（1）软件单元测试由承建单位自行组织，一般由软件开发组实施测试。

（2）软件集成测试由承建单位自行组织，软件开发组和软件测试组联合实施测试。

（3）软件确认测试由承建单位自行组织，软件测试组实施测试。

（4）系统测试应由业主单位组织，成立联合测试组（一般由专家组、业主单位、软件评测单位、承建单位等联合组成测试组）实施测试。

19软件评审--内部评审由承建单位组织并实施。

评审人员由软件开发组、质量管理和配置管理人员组成，可邀请业主单位参加。

对规模等级大和安全性关键等级高的软件必须进行外部评审。

外部评审由业主单位主持，承建单位组织，成立评审委员会。

20软件维护

1.纠错性维护（产生工作量但是没有费用）纠正在开发阶段产生而在测试和验收过程没有发现的错误。

其主要内容包括:

（1）设计错误;

（2）程序错误;

（3）数据错误;

（4）文档错误。

2.适应性维护（产生工作量也产生费用）为适应软件运行环境改变而作的修改。

环境改变的主要内容包括:

（1）影响系统的规则或规律的变化;

（2）硬件配置的变化，如机型、终端、外部设备的改变等;

（3）数据格式或文件结构的改变;

（4）软件支持环境的改变，如操作系统、编译器或实用程序的变化等。

3:

完善性维护（产生工作量同时也会产生费用如合同没有明确就不定如支付额外费用按合同价的百分之10以内是合理的）为扩充功能或改善性能而进行的修改。

修改方式有插入、删除、扩充和增强等。

主要内容包括:

（1）为扩充和增强功能而做的修改，如扩充解题范围和算法优化等;

（2）为改善性能而作的修改，如提高运行速度、节省存储空间等;

（3）为便于维护而做的修改，如为了改进易读性而增加一些注释等。

21监理单位的质量体系策划-这一阶段的主要工作是调研监理单位的组织现状，制定建立质量体系的实施计划，选择适用的质量保证模式标准，确定质量方针，调整和完善单位的组织，制定要素的实施办法。

22典型的监理单位的质量体系文件包括质量手册、质量体系程序、详细作业指导书。

质量手册是阐明单位的质量方针，并描述其质量体系的文件，它是质量体系文件中的纲领性文件，通常质量手册至少应包括质量方针、质量手册评审修改控制的规定等内容。

质量体系程序是一套文件化的程序，用以描述为实施质量体系要素所涉及的各职能部门的活动。

程序文件是对与质量有关的管理、技术人员的控制的依据，必须具有可操作性和可检查性。

细作业指导书是描述程序文件中某个具体过程、事物形成的技术性细节的文件，可按照程序文件的要求，结合监理单位的实际情况编制。

23监理单位的行为准则

（1）守法-这是任何一个具有民事行为能力的单位或个人最起码的行为准则，对于监理单位守法就是依法经营，其行为应遵守国家和相应地区的所有法律法规。

（2）公正-主要是指监理单位在处理建设单位与承建单位之间的矛盾和纠纷时，要做到不偏袒任何一方，是谁的责任就由谁承担，该维护谁的权益就维护谁的利益，决不能因为监理单位受建设单位的委托，就偏袒建设单位。

（3）独立-这是信息系统工程监理有别于其他监理的一个特点，监理单位不能参与除监理以外的与本项目有关的业务，而且，监理单位不得从事任何具体的信息系统工程业务。

也就是说，监理单位应该是完全独立于其他双方的第三方机构。

（4）科学-信息系统工程是代表高科技的工程，监理的业务活动要依据科学的方案，运用科学的手段，采取科学的方法，进行科学的总结。

（5）保密-信息系统工程是高新技术领域的工程，在工程设计和实施中会涉及大量的技术、商业、经济等秘密，监理单位有业务对其在工作范围内接触的上述信息保守秘密。

24监理工作的风险类别

1.行为责任风险

行为责任风险来自三个方面:

（1）监理工程师超出建设单位委托的工作范围，从事了自身职责外的工作，并造成了工作上的损失;

（2）监理工程师未能正确地履行合同中规定的职责，在工作中发生失职行为造成损失;

（3）监理工程师由于主观上的无意行为未能严格履行职责并造成了损失。

2.工作技能风险

监理工程师由于他在某些方面工作技能的不足，尽管履行了合同中建设单位委托的职责，实际上并未发现本应该发现的问题和隐患。

现代信息技术日新月异，并不是每一位监理工程师都能及时、准确、全面地掌握所有的相关知识和技能的，无法完全避免这一类风险的发生。

3.技术资源风险

即使监理工程师在工作中没有行为上的过错，仍然有可能承受一些风险。

例如在软件开发过程中，监理工程师按照正常的程序和方法，对开发过程进行了检查和监督，并未发现任何问题，但仍有可能出现由于系统设计留有缺陷而导致不能全部满足实际应用的情况。

众所周知，某些工程上质量隐患的暴露需要一定的时间和诱因，利用现有的技术手段和方法，并不可能保证所有问题都能及时发现。

同时，由于人力、财力和技术资源的限制，监理无法对施工过程的所有部位、所有环节的问题都能及时进行全面细致的检查发现，必然需要面对风险。

4.管理风险

明确的管理目标、合理的组织机构、细致的职责分工、有效的约束机制，是监理组织管理的基本保证。

如果管理机制不健全，即使有高素质的人才，也会出现这样或那样的问题

25监理单位的风险防范方法

1.谨慎签订监理合同

监理单位在签订信息工程监理委托合同之前，应该首先调查建设单位的资信、经营状况和财务状况。

其次，在合同的谈判过程中，要争取主动并采取相应的对策，保护自己的合法利益。

对委托单位提出的合同文本要细细推敲，对重要问题要慎重考虑，积极争取对风险性条款及过于苛刻的条款做出适当调整，不能接受权利与义务不平等的合同，不能为了揽到信息工程监理合同而随意让步，从而丧失公平原则，使自己陷入被动地步。

2.严格履行合同

对于监理工作中涉及的所有合同，监理工程师必须做到心中有数，注意在自身的职责范围内开展工作，不要超越建设单位的委托范围去工作。

3.提高专业技能

监理工程师的职责从客观上要求从业者不断学习，努力提高自身素质，否则就无法适应现代工程建设的要求。

监理工程师应该努力防范由于技能不足带来的风险。

4.提高管理水平

监理单位必须结合所承担工程的具体情况，明确监理工作目标，制定行之有效的内部管理约束机制，尤其是在监理责任的承担方面，机构内所有成员各自应该承担什么责任应该明确，落实到位。

将这方面的风险置于有效的控制之下。

26监理人员的岗位与职责

1.总监理工程师的职责

（1）对信息工程监理合同的实施负全面责任;

（2）负责管理监理项目部的日常工作，并定期向监理单位报告:

（3）确定监理项目部人员的分工;

（4）检查和监督监理人员的工作，根据工程项目的进展情况可进行人员的调配，对不称职的人员进行调换;

（5）主持编写工程项目监理规划及审批监理实施方案;

（6）主持编写并签发监理月报、.监理工作阶段报告、专题报告和项目监理工作总结，主持编写工程质量评估报告;

（7）组织整理工程项目的监理资料;

（8）主持监理工作会议，签发监理项目部重要文件和指令;

（9）审定承建单位的开工报告、系统实施方案、系统测试方案和进度计划;

（10）审查承建单位竣工申请，组织监理人员进行竣工预验收，参与工程项目的竣工验收，签署竣工验收文件;

（11）审核签认系统工程和单元工程的质量验收记录;

（12）主持审查和处理工程变更;

（13）审批承建单位的重要申请和签署工程费用支付证书;

（14）参与工程质量事故的调查;

（15）调解建设单位和承建单位的合同争议，处理索赔，审批工程延期;

（16）负责指定专人记录工程项目监理日志。

2.总监理工程师代表的职责

（1）总监理工程师代表由总监理工程师授权，负责总监理工程师指定或交办的监理工作:

（2）负责本项目的日常监理工作和一般性监理文件的签发;

（3）总监理工程师不得将下列工作委托总监理工程师代表:

•根据工程项目的进展情况进行监理人员的调配，调换不称职的监理人员;

•主持编写工程项目监理规划及审批监理实施方案;

•签发工程开工/复工报审表、工程暂停令、工程款支付证书、工程项目的竣工验收文件;

•审核签认竣工结算;

•调解建设单位和承建单位的合同争议，处理索赔，审批工程延期。

27监理的三大文件

监理大纲是在建设单位选择合适的监理单位时，监理单位为了获得监理任务，在项目监理招标阶段编制的项目监理单位案性文件。

监理规划则是在监理委托合同签订后，由监理单位制定的指导监理工作开展的纲领性文件。

监理实施细则则是在监理规划指导下，监理项目部已经建立，各项专业监理工作责任制己经落实，配备的专业监理工程师已经上岗，再由专业监理工程师根据专业项目特点及本专业技术要求所编制的、具有实施性和可操作性的业务性文件

28监理规划的作用

1）监理规划是监理项目部职能的具体体现

2）监理规划是指导监理项目部全面开展工作的纲领性文件

3）监理规划是信息系统工程监理管理部门对监理单位进行监督管理的主要内容

4）监理规划是建设单位检查监理单位是否能够认真、全面履行信息系统工程监理委托合同的重要依据

5）监理规划是具有合同效力的一种文件

29监理规划的内容

监理规划包括的主要内容有工程项目概况、监理范围、监理内容、监理目标、监理项目部的组织形式、监理项目部的人员配备计划、监理项目部的人员岗位职责、监理依据、监理工作程序、监理工作方法及措施、监理工作制度、监理工具和设施等。

在监理工作实施过程中，如实际情况或条件发生重大变化而需要调整监理规划时，应由总监理工程师组织专业监理工程师研究修改，按原报审程序经过批准后报建设单位。

30监理实施细则的内容

监理实施细则的主要内容包括工程专业的特点、监理流程、监理的控制要点及目标、监理单位法及措施。

31监理单位法及措施

措施即计划采用的监理技术、监理工具和针对工程异常情况的监理措施。

对不同的专业应有不同的监理技术，在不同的工程阶段也有不同的监理手段。

例如，在对综合布线系统的线路连通性进行控制时，可采用一些测试仪器进行抽检;对软件开发进度进行控制时，可通过审查开发过程文档、走查代码来实现;对网络设备价格进行控制时，可审核原始单据，并通过电话核实来确认。