《构建之法》(十三)

软件工程师的誓言(二)

这里接上一篇,摘写具体的软件工程师的誓言中具体应该遵守的规则。即在面对公众、客户与雇主、产品、判断、管理、职业、同事自身

原则1:公众

软件工程师的行为应与公众利益一致。特别地,软件工程师应恰当地做到:

1.1 对自己分内工作负有全部责任

1.2 综合考虑软件工程师,雇主,客户,用户与公众的利益

1.3 软件是安全的,符合规范的,通过适当的测试,不降低生活的质量,不侵犯隐私,不对环境造成伤害;只有当以上条件都能够有充分确认,才认可这个软件。软件的终极效用应该是公益的。

1.4 把任何对用户、公众及与软件和相关文档有联系的外界人员可能造成的危害,告知相关人员或者专家。

1.5 努力合作来解决由软件及其安装、维护、支持和文档 所带来的公众关注的重要问题。

1.6 在所有关系到软件或者相关文件、方法和工具的的声明,尤其是在那些公开声明中,要做到公正并避免欺诈。

1.7 要考虑到由物理缺陷、资源分配、经济劣势和其他一些会降低软件收益的因素所带来的结果。

1.8 鼓励自愿将专业技能用于公益事业,促进公共学科教育的发展。

原则2:客户与雇主

软件工程师应以他们的客户和雇主最大利益化的方式做事,与公众利益一致。特别地,软件工程师应该视情况而定按如下原则工作:

2.1. 在他们的能力范围之内提供服务,诚实和坦率地对待他们经验和教育上的任何局限。

2.2. 不故意使用那些获得或保留的非法或者不道德的软件。

2.3. 只在正确地授权后使用客户或雇主的资产,并且在客户或雇主的知识和允许中进行。

2.4. 确保每一个文档的建立基础都是经过检验的,如果需要的话,由授权人士认证。

2.5 在工作中,对任何机密信息要注意保密,这种保密要与公众利益和法律一致。

2.6 当员工觉得项目将要失败,要及时识别、记录、收集证据并向他们的客户或雇主报告,以证明项目失败的原因。这些原因可能是成本太高,侵犯知识产权,抑或是其它问题。

2.7 当员工意识到在软件或相关文档中涉及某些重大的社会关注问题时,要及时发现、记录并向雇主或客户汇报。

2.8 对主要的雇主负责,不接受影响本职工作的任务。

2.9 尽可能保护雇主或客户的利益,除非出于更高的道德考虑,在这种情况下,向雇主或合适的权力机构反映道德问题。

原则3产品

软件工程师应当确保他们的产品以及相关的修改达到尽可能高的专业标准。具体来说,软件工程师应当:

3.1. 力求高质量,可接受的成本和合理的计划;弄清出你做出的所有影响较大的权衡,并且确保它们被雇主和客户所接受,并且把你的计划提供给用户和公众来考虑。

3.2. 确保在工作或提出任何项目的时候,设立恰当,可以达成的目标。

3.3. 识别,定义和解决各种与项目相关的道德,经济,文化,法律和环境。

3.4. 确保自身因受过合适教育和训练,以及拥有足够经验,而有资格去做他们工作或提出的项目。

3.5. 确保使用一个合适的方法去做他们工作或者提出的项目。

3.6. 只要条件许可,就应当采取专业标准去做手头的任务,除非有道德或者技术上的正当理由来支持你不这么做。

3.7. 力求完全理解你工作的specification。

3.8. 确保软件的specification完善,满足用户需求,也经过恰当的批准。

3.9. 对于任何你工作或者提出的项目,要对费用,调度,人员,质量和产出进行现实的和量化的评估,而且要给出对你的评估的不确定性的估计。

3.10. 确保对于你在做的项目的程序和文档,要有足够的测试,调试和复审。

3.11. 确保对于你在做的项目,要有足够的文档,包括所有你发现的问题和解决的方法。

3.12. 开发尊重用户隐私的软件和文档。

3.13. 留心只用合乎道德和法律的手段获取的准确数据,而且只按照被授权的方式去使用它们。

3.14. 维护数据的完整性,对于过期和有问题的数据要敏感。

3.15. 对于任何形式的软件维护,要有和开发新软件一样的专业精神。

原则4:判断

软件工程师应当完整独立地进行自己的专业判断。具体来说,软件工程师应当:

4.1. 调节所有的技术判断以支撑和维护价值观。

4.2. 只签署并认可这样的文档:要么是自己管理之下的,要么是自己职权范围且已在业内达成共识的。

4.3. 评估任何软件和文档时保持专业的客观性。

4.4. 不参与贿赂、重复收费等不正当的经济行为。

4.5. 把无可避免的利益冲突通知给所有相关群体。

4.6. 拒绝以任何形式(作为成员或提建议者)参加一个任何形式的(私有的,政府的,专业的)和软件相关的组织,如果这个组织或者他的雇员,客户有未公开的潜在利益冲突。

原则5:  

软件项目的经理和领导人员应赞成和促进对软件开发和维护合乎道德规范的管理,特别是在适当的情况下软件工程师应当:

5.1  对其从事的项目保证良好的管理,包括提高质量和减少风险等有效手段;

5.2  保证软件工程师在遵循标准之前便知晓它们;

5.3  保证软件工程师知道雇主是如何保护对雇主或其他人保密的口令、文件和信息的有关策略和方法;

5.4  布置工作任务应先考虑其教育和经验有相应的水平,再加上有进一步教育和成长的要求;

5.5  保证对他们从事或建议的项目,做出现实和定量的估算,包括成本、进度、人员、质量和输出,并对估算的不确定性做出评估;

5.6  在雇佣软件工程师时,需实事求是地介绍雇佣条件;

5.7  提供公正和合理的报酬;

5.8  不能不公正地阻止一个人取得可以胜任的岗位;

5.9  保证对那些在软件、过程、研究、写作、或其它知识产权的所有权方面做出贡献的软件工程师,有一个公平的协议;

5.10  应对违反雇主利益或道德观念的指控,提供正规的听证过程;

5.11  不要求软件工程师去做任何与道德规范相违背的事;

5.12  不能处罚对项目表露出道德关切的人;

原则6   职业

在与公众利益一致的原则下,软件工程师应当保证其职业的完整和声誉,尤其地,在适当的情况下,软件工程师应当:

6.1  协助发展一个适合执行道德规范的组织环境;

6.2  推进软件工程知识的普及;

6.3  通过适当参与各种专业组织、会议和书籍的出版,来扩占软件工程知识;

6.4  作为一名职业人员,支持其他软件工程师努力遵循本守则;

6.5  不以牺牲职业、客户或雇主利益为代价,谋求自身利益;

6.6  服从所有监管作业的法规,在这种要求与公众利益有不一致时例外;

6.7  要准确叙述自己所做的软件的特性,不仅要避免错误的断言,也要防止那些纯理论的、空洞的、欺骗的、误导的或者有疑问的断言;

6.8  对所从事的软件和相关的文档,负起检测、修正和报告错误的责任;

6.9  保证让客户、雇主和主管人员知道软件工程师对本道德规范的遵守,及其带来的后果;

6.10  避免加入与本道德规范有冲突的业务和组织;

6.11 要认识违反本规范是与成为一名专业工程师不相称的;

6.12  在出现明显违反本规范时,应向有关当事人表达自己的担忧,除非在没有可能、会影响生产或有危险时才可例外;

6.13  当与明显违反道德规范的人无法磋商,或者会影响工作或有危险时,应向有关部门报告;

原则7: 同事

软件工程师应当正直地去帮助他们的同事,尤其是:

7.1. 鼓励同事坚持这个准则。

7.2. 在开发过程中帮助同事。

7.3. 对引用别人的工作注明来源,抵制未经允许的引用。

7.4. 代码审查时做到客观、坦诚,并适当地记录。

7.5. 认真对待同事的建议,担心,抱怨。

7.06. 在帮助你的同事时,你应该对有可能产生的安全问题有充足的了解,并有能力控制,例如是遵守规定,保护密码及机密文件等。

7.7. 不能不正当地干涉同事的工作。但是,从老板角度出发,如果前一条与公司或公共利益冲突,软件工程师可以对同事的工作提出置疑。

7.8. 当遇到自己不能胜任的问题时,请教那个领域的专家。

原则8: 自身

软件工程师应当在不违反道德准则的情况下,终生学习以提高自身的专业水平:

8.1. 加强各个方面的能力——分析,标准化、设计、开发、维护、测试、写文档、管理项目进程等。

8.2. 提高能力,在合理的时间内,利用合理的花费,去实现安全、可靠、高质量的软件。

8.3. 提高能力,写出精确、可读、有价值的文档。

8.4. 提高对相关文档、软件、开发环境的理解。

8.5. 加强对相关标准、法律的了解。

8.6. 深入理解这份准则,以及如何将其应用到工作中。

8.7. 不因为偏见而对任何人不公。

8.8. 不参与任何与违反些准则有关的活动。

8.9. 坚信一个专业的软件工程师不会违反此准则。

时间: 2024-10-11 07:09:39

《构建之法》(十三)的相关文章

构建之法十三~十七章

十三章:软件测试 Bug我们经常听到的,要发现解决我们遇到的bug(软件的缺陷),我们必然需要测试.本章我们了解很多基本名词解释及分类. 测试有很多种方式:白箱和黑箱,功能测试和非功能测试等. 书本还提到很多测试方法,书本239~251, 大概有十几种方法那么多,其实我觉得我们可以选择一种适合的方法进行测试. 测试这一方面我们接触的比较少,一般只会针对功能对程序进行测试,测试也会涉及很多测试相关文档. 十四章:质量保障 对于一个软件来说,软件的质量是很重要的,程序的质量=程序的质量+软件工程的质

构建之法第十三~十七章阅读

不知不觉,<构建之法>已经读到了最后..... 十三章:软件测试 本书里面写了好多软件测试的方法,我该怎么选取呢 十四章:质量保障 质量保障可以通过用户的反馈来体现吗 十五章: 稳定和发布阶段 软件发布以后,可以怎样的情况来更新维护 十六章:IT行业的创新 我觉得创新是在你已经对本行业已经有一定的了解,但是我们好多基本的都还没掌握,该怎么创新呢 十七章:绩效和职业道德 在出去工作以后,公司都是以绩效和职业道德来恒定员工的吗

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展

作业5(《构建之法》心得体会)

这学期学习邹欣老师的<构建之法:现代软件工程>一书收获颇多. 第一章 概论 软件 = 程序 + 软件工程 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.软件工程包括:软件求分析.软件设计.软件构建.软件测试和软件维护.软件的特殊性:复杂性.不可见性.易变性.服从性.非连续性. 第二章 个人技术和流程 单元测试(用VSTS写单元测试.好的单元测试的标准)回归测试.效能分析工具.个人软件开发流程(实践最简单的项目:WC). 第三章 软件工程师的成长 个人能力的衡量与

快速阅读《构建之法——现代软件工程》

2017年4月1日,我借阅了<构建之法--现代软件工程>一书,2017年4月13日上午终于快速读完了一遍.书中包含的内容丰富,其中大量的网上链接没有阅读.在我看来,读这本书应该先通览全篇,不能被大量的链接在第一次阅读的时候就打断.网上的链接一个接一个,这样会导致我忘记了最初的阅读目的.也许,这就是万维网的一个弊端吧. 速读<构建之法--现代软件工程>记录日程如下: 星期日 星期一 星期二 星期三 星期四 星期五 星期六             1开始阅读 2 3第二章第三章 4 5

项目管理学习——《构建之法》读书笔记

最近终于有时间来读读书了.买了<构建之法>已经一年多了,这次静下心来读完了,收获很大.现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本,当时由于对于整个行业没有太大的感触,而这本书又全部由专业术语和定义组成,所以当时的课是相当痛苦.而老师通过的这门课程的方式又由各种理论知识考试为准,所以当时学习感觉相当“鸡肋”. 好的地方: 1,情景式.对话式对白,有趣易读.这点非常喜欢,很多实际中碰到的问题在这里可以重现.比如:每日构建,在实际开发中,就会由于各种原因导致不

构建之法第六次随笔

我这个礼拜阅读了构建之法第12,13章. 其中,第十二章讲的是用户体验,我们要考虑用户体验的不同角度,用户的第一印象就很重要,用户第一次使用软件,就很大程度上决定了用户对软件的评价.软件服务始终都要记住用户的选择,从用户的角度考虑,要有一颗同理心.理解用户的处境,心理,动机的能力有着一颗为用户着想的同理心,是好的产品设计的出发点.也不要让用户犯简单的错误,所以要不停改进,高明的设计能让用户不需要花费额外的注意力,也不需要经验与专业知识即可凭借直觉完成正确的操作. 对于一个软件的用户界面,有一些原

初读《构建之法》(Build To Win)有感

最近略读了<构建之法>被作者诙谐幽默的写作风格深深吸引住了,文中有大量通俗易懂.形象鲜明的例子,更好的理解文中提出来的概念与理论.我是第一次接触到软件工程这门课,之前对于软件工程的理解就是编程写出一个应用程序,然而当我对读了本书之后,才对软件工程有了一个大概的了解. 在本书中,作者提出了一种全新的教学理念"Learning by Doing",也就是"做中学",与传统的教学方式不同的是提倡学生在大量的实践中学会知识.应用知识,掌握实用的软件工程技术.同时

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.