阅读《构建之法》P384~391

  通过阅读《构建之法》P384~391以及参考阅读杜老师给出的链接,得出一个重要的结论:软件工程师的职业道德至关重要。

  软件工程的动态性和需求的前后关系,要求一个规范能对出现的新情形有较强的适应性和适用性。但是即使在这种一般性原则下,本规范也只对那些以文档记录职业道德态度并采取积极行动的软件工程师提供支持;即提供相应开发组中的个人以及整个开发组都可以求助的道德基础。本规范也帮助定义哪些是对软件工程师提出的道德上不适当的要求。

原则1  公众

  软件工程师的行为应与公众的利益一致。

原则2  客户与雇主

  软件工程师应以其客户和雇主利益最大化的方式做事,与公众利益保持一致。

原则3  产品

  软件工程师应当确保自己的产品以及相关的修改满足最高的专业标准。具体来说,软件工程师应当:

    3.01   力求高质量、可接受的成本和合理的计划,确保雇主和客户了解并同意你做的重要折衷,并让用户和公众也能了解这些折衷。

    3.02   确保在开展或提议任何项目时,设定恰当、可行的目标。

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

    3.04   确保自身有足够的资质去参与或准备参与相关项目。这里的资质由相应的教育、培训和经验组合而成

    3.05   确保在参与或准备参与的项目中采用得当的方法。

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

    3.07   力求完全理解参与开发的软件的规格要求。

    3.08   确保软件的规格说明书是完善的、满足用户需求的,也经过了恰当的批准。

    3.09   对于任何正在或计划进行的项目,要在费用、进度、人员质量和产出上进行合乎实际和量化的评估,而且要说明评估的不确定性。

    3.10   确保项目的程序和文档经过足够的测试、调试和复审。

    3.11   确保项目文档齐全,包括所有发现的问题和解决的方法。

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

    3.13   留心只用合乎道德和法律的手段去使用准确的数据,并且只按照被适当授权的方式去使用这些数据。

    3.14   维护数据的完整性,注意过期和有问题的数据。

    3.15   对于任何形式的软件维护工作,要具备同开发新软件时一样的专业精神。

原则4  判断

  软件工程师应当具备完整且独立的专业判断。

原则5  管理

  软件项目的经理和领导人应该提倡并亲自采用符合道德规范的方法来管理软描开发与维护。

原则6  职业

  在与公众利益一致的原则下,软件工程师应当保证其职业的诚信和声誉。

原则7  同事

  软件工程师应当公平对待同侪,并予以支持和帮助。

原则8  自身

  软件工程师应当终生学习以提高自身的专业水平,并在工作实践中推动落实道德准则。

    对于道德问题最好是给出经过深思熟虑的基本准则,而不是仅仅列出许多详细的规定。这些准则应该影响你去更广泛地考虑谁将受到你的工作影响;去检查你和你的同事是否以应有的尊重对待他人;去推测如果公众被恰当地告知,那么他们将怎样审视你所做的决定;去分析你的决定的最低影响力是多少;去考虑是否你的作为够得上软件工程师的理想的职业行为。因为本规范代表那些从事该职业的人的共同意见,所以我们应该重视由那些有见识的、受人尊重的和有经验的同行在掌握全部事实的情况下,他们认为的什么是特定环境中最道德的行为方式,并且只在具有深刻的原因同时又经过认真仔细地判别之后才违反这种常规。

时间: 2024-08-13 01:33:17

阅读《构建之法》P384~391的相关文章

第一次阅读构建之法

    第一次阅读构建之法,把以前很多门课的知识点联系到了一起.      软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.      从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证服务质量的软件服务.源程序是建立在数据结构上的一些算法.构建不仅仅是CC和link命令,一个复杂

阅读构建之法第一章有感

今天阅读了构建之法第一章,感觉到自己其实玩具的阶段都不到,离研究阶段更是差的有段距离.了解到程序其实只是一个藏在你电脑里的数据结构加算法,要想成为软件还得经历软件工程这一阶段,软件工程便是把系统的.有序的,可量化的方法应用到软件开发,运营和维护上的过程中.首先我要进行软件需求分析,一个成功的软件是要有市场需求作为背景的,没有需求你做的软件就是无用的东西,有了需求然后我们对软件进行设计使之安全 可行 基本满足市场的需求.然后我们便对我们的软件进行测试.最后软件在用户手中运行,但是十全十美的软件是不

为什么报计算机还有阅读构建之法的心得

1.为什么选择计算机这个专业; 当初读本科的时候,一志愿填的是电气工程及其自动化,估计是因为分数太低了被调剂到了网络工程专业.之前的我并没有过多的接触计算机,感觉自己对这方面并没有多大的兴趣,本科的时候自己的学习并没有多么的认真.当时自己还想过要转专业,后来也不了了之了.慢慢的感觉这个专业还可以,也就学了三年,后来到了考研的时候,本来打算考金融专业的,但是跨专业考研难度挺大的,而且最近几年计算机这个专业实在是太火了,毕业之后工作找工作各方面都不错然后就限定决心考了计算机技术.庆幸的是考上了,现在

阅读<构建之法>第三10、11、12章并提出问题

<构建之法>第10.11.12章 第10章: 问题:对我们了解了用户的需求后,但是我们想法和做出来的软件会和用户的需求有偏差,比如风格.界面的修饰等等,那么我们程序猿怎样才能让自己的想法更加靠近用户的想法呢?是设身处境么? 第11章: 问题:我们现在这个阶段是在做四则运算APP,如果按照这章的步骤走下去,每天都要进行进度更新,和每日会议还有每日构建的,会不会不太符合我们现在的处境?毕竟我们的所有时间不能只为一门课程服务,还要大量的时间花在其他的课程上呢. 第12章: 问题:在实际的项目中,我们

阅读&lt;构建之法&gt;10、11、12章

第十章: 典型用户和场景对后面工作有什么帮助吗? 第十一章: 每日构建的目的是什么呢?有没有具体说明? 第十二章: 产品定位人群是否也局限了产品的可拓展性?

阅读&lt;构建之法&gt;第三10、11、12章

第十章典型用户和场景 1.典型场景和典型用户 对用户的认识,例如用户的价值,如何定义用户,用户与场景的结合,在从场景到任务等,还有用户的模板或者故事. 2.规格说明书 (1)功能说明书 定义相关的概念->规范好假设->避免误解,界定一些便界条件->描述主流的用户/软件交互步骤->一些好的功能和副作用->服务质量 (2)功能说明书模板 (3)技术说明书 (4)功能驱动的设计 构建总体模型->构建功能列表->制定开发计划->功能设计阶段->实现具体功能 对

阅读构建之法第六章

      这一小节中有一个图表,对比了敏捷(Agile).计划驱动(Plan-driven).形式化的开发方法(Formal Method)的适用范围.里面提到的形式化的开发方法,其基本步骤是怎样的呢?为什么它能有极高的可靠性呢?下面是一些关于形式化方法特点的说明,从中可以看出它能力的缘由. 形式化方法建立在严格的数学基础上,其目标是希望能使系统具有较高的可信度和正确性,并能使系统具有良好的结构,使其易维护,关键是能较好地满足用户需求."形式化方法"一词虽然一直被广泛地应用,但在不同

阅读&lt;构建之法&gt;第10、11、12章

第十章(P183  10.1) 问题:用户的真实需求是什么?我们要如何理解用户的真实需求? 第十一章(P203) 问题:如何跟客户交流,避免误解? 第十二章(P230) 问题:用户体验设计该从哪方面着手?有哪些步骤?

阅读构建之法读后感第三章

养成一个优秀的程序员必须做到的: 1.代码规范 首先我们需要了解的是我们的代码不只是给机器看的主要还是给人看的,那么我们就需要将我们的代码写的清清楚楚. 代码风格规范:主要是文字上的规范,看似表面文章实际上非常重要.代码风格的原则就是简明,易读,无二义性. 1.缩进,使用tab键,4个空格的距离看着正好. 2.行宽,必须限制行宽. 3.括号,括号清楚的表示逻辑优先级. 4.断行与空白{}行. 5.分行,不要将多条语句放在同一行. 6.命名,必须分清楚类,变量,关键字的命名方式. 7.下划线,用来

阅读&lt;构建之法&gt;13、14、15、16、17章

13章 这么多测试为什么不能整理出一个包括所有功能的测试呢?看着那么多测试都感觉奇怪了. 14章 怎样才能体现一个测试人员的工作价值呢?这样的判断又是否会太独断了? 15章 在时间上,会不会因不同功能板块完成快慢有影响?在后期的问题解决又有何保证措施? 16章 创新并不是每个人都行的,但有时候太执着于此是否进了死胡同呢? 17章 作为领导者的话,做到公平公正也并不像口头上那么简单,有时候是向规则妥协呢还是坚持自己的主见?