左直拳的马桶_日用桶

RUP（统一过程）

1、系统设计说明书主要是说明系统结构2、数据库设计说明书3、用户手册系统部署

今天参加了一次可以算得上JRP的会议。与会者有甲方最高领导，二号领导，以及各个部门头头，业务专家，监理公司代表，开发方项目总监，执行项目经理，程序员代表等，层级不可谓不高。会议在甲方大会议室进行，里面有个超大的屏幕，已经赶上MAX影院了。每个人面前一只麦克风，可关可开。地上是应该很高级的，估计是羊毛的地毯，我们进去都要套鞋套。总之设备一流。会议有既定议程。甲方二号领导主持，首先甲方代表发言，介绍项目概况和目前的总体情况。接着是开发方介绍技术方案、实施计划，然后演示原型。再接着各部门提意见，这是重点，耗

我司有一个研究生，主要工作是写售前方案。其人并非开发出身，也不是计算机专业，但现在公司各种用于投标的建设方案书，多由她们捉刀，画图，论述，头头是道，井井有条。那么，写这些建设方案，在信息系统里面，算是啥呢？起什么作用？这些个建设方案，算是什么文档？信息系统生命周期，由系统规划、系统开发、系统运维、系统更新与消亡4个阶段组成；其中系统开发阶段是重头戏，又分为总体规划，系统分析，系统设计，系统实施，系统验收几个小阶段。软件开发过程中，每个阶段都有对应的文档。大家熟知的有，系统分析的最终产物是《需求规格说明书

极限编程（XP）和SCRUM大概是2种最著名的敏捷开发方法。二者有啥区别呢？一、XP的特点1、迭代周期更短，并强调持续反馈2、测试驱动，自动化测试3、项目初期迅速生成总体计划，之后迭代发展和完善4、持续演化5、依赖口头交流、测试和源程序进行沟通6、团队紧密协作7、程序员短期利益和项目长期利益取得平衡二、XP最佳实践1）计划游戏2）小型发布3）隐喻4）简单设计5）测试先行6）重构7）结对编程8）集体代码所有制9）持续集成10）每周工作40小时11）现场客户12）编码标

软件（项目）可行性分析报告软件（项目）开发计划/开发任务书软件需求规格说明书接口需求规格说明书系统设计说明书接口设计说明书数据库设计说明书用户手册操作手册测试计划测试报告软件配置管理计划软件质量保证计划开发进度月报项目开发总结报告软件产品规格说明书软件版本说明书...

对于单元测试，我慢慢的用得多起来。前不久，还对这个东西朦朦胧胧，觉得很神秘。现在，我觉得单元测试真是极好的。好在哪里呢？就是好来就是好！靠，这又不是某D某主义，得讲理。怎么个好法，要说出理由。好吧，我觉得单元测试可以 1、保证代码质量 2、提高开发效率比如说，这2天我与另一位同事共同开发某模块。他搞前端，我写服务器端，他要调用我的方法。开发是并行的，我在写方法的时候，他的界面还没好，那怎么确保我

我是酱紫理解的：单元测试是对开发人员来说的。是开发者用于测试自己写的函数、方法的手段。敏捷开发有理论名曰：TDD，测试驱动。即在开发功能代码之前，先编写单元测试用例。注意，是编写单元测试用例，而不是单元测试。单元测试应该是在功能写出来之后，为保证质量做的测试。所谓的测试用例，就是将功能具体化成一系列条件和结果。比如登录功能，我输入个啥，按提交，会出现啥，之类。前不久网上看到有位高手说，需求文档应该是

我好像还没有完全践行过敏捷开发。不过这段时间一通学习下来，结合以往的一些经历，认为敏捷的精髓在于多职能团队和迭代思想。1、多职能团队意味着团队成员参与了整个项目的绝大部分工作：任务领用、需求分析、设计及开发、测试、评审。比如，需求分析，以往都是由一个所谓系统分析员来写；而在敏捷里，是由产品经理在计划会上讲故事，然后由各人报所需工时，任务领用，然后进行开发。这里看上去似乎没有所谓需求分析，有的话，也

敏捷开发里的用语，如果我没有记错的话，是从 "user story"里直译过来的。用户故事，顾名思义，难道是一个有关这个客户的传奇故事？真好笑，显然不是。也许这是西方的一种什么俗称，或者是因为这写在一张卡片或小贴纸上，便于讲故事的原因？不管它，反正敏捷开发里的所谓用户故事，是用于描述用户需求的，描述的格式是：我作为一个。。。的角色，希望有。。。的功能，以便。。。从中可以看出用户故事具备三个元素：1

UML有9种图：用例图类图对象图状态图序列图协作图活动图组件图部署图9，在中国是个阳数，通常代表很多的意思。比如说，九九艳阳天，九死而不悔，成吉思汗对功臣的九罪而不罚，天上九头鸟地上湖北佬，等等。现在，又有了UM姆L的神奇九图。传说，UML的神奇九图是伏羲根据灵龟驮出的河图洛书所创，包含天地的奥秘，宇宙的起源，过去、现在、未来，一切的一切，皆蕴含于其中矣：1、用例图用户、角色与功能的关系。是系统的

我们开发二部忙忙碌碌的做了一年半，立志做通用软件产品，很惭愧，做得并不成功。主要有三个产品：网络办公，考勤，网站发布。这三个东西，都基于我们的信息协同平台。从开发思想上看，我认为是正确的。之所以未能打开市场，我认为主要有两个原因。一是产品未成熟，甚至还存在许多漏洞。网络办公是一个巨大的项目，里面包括很多内容，我从来公司时就开始做，一直到现在，那个信息协同平台都未能全部完成。时间比较紧，一年半里，同

       今天主要是写**房管局财会管理系统的方案。财会上的东西，我很不熟悉。这几天，我找了本会计电算化的书看了一下，又在网上看了些相关系统的资料，一轮恶补。更多的是，联系金蝶，问他们财会软件的二次开发接口。大公司就是大公司，这部门那部门，找了N个人，得到的答案是N个版本，就是没有我想要的。写方案嘛，大概就是这样，不停的查资料，打电话，找人。老总曾经对我说：“世间上最难的就是与人打交道。”在我

买酱油与软件工程阶段划分软件工程是一门深奥神秘的学科，这阶段，那阶段；这文档，那文档；说得天花乱坠，高深莫测，头都大了。清华大学出版社的《系统分析员教程》上介绍说，系统开发可以分为以下几个阶段：    总体规划，系统分析，系统设计，系统实施，系统运行及评价。按照我的理解，这几个阶段用通俗一点的说法来描述，就是：    做什么？做成什么样子？怎么做？做吧！做得好吗？并

项目打单时该写什么文挡左直拳清华大学出版社的《系统分析员教程》上介绍说，系统开发可以分为以下几个阶段：总体规划，系统分析，系统设计，系统实施，系统运行及评价。每个阶段都有一定的文挡与之对应，比如，总体规划阶段是《可行性分析报告》，系统分析阶段是《系统分析报告》，等等。阶段划分得很清晰，令人信服。可是，有谁能告诉我，项目在打单时是处于一个什么阶段？又该写什么样的文档？总体规划

造成项目延期大约有下面几个原因：1、对工作量估计不足，其中最主要的原因是没有细化，仔细考虑每一个模块要做哪些工作；2、沟通扯皮耗费不少时间，很多时候，是客户的原因；3、各种突发事件；4、工作量与工作能力不匹配，比如，预想为半天的，可能要整整一个工作日；5、没有牢记所谓的工作日，满

第一要务是拒绝客户不合理的要求，特别是进度的不合理要求，不要答应那种不可能完成的任务，否则会累死自己和同事。

1024x768 Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

现在互联网公司的组织架构以产品经理为核心，市场、销售、研发、运营都围着产品经理转。这种架构，其实就是以产品为中心，产品至上。产品做好了，大家都好，而不是围绕着什么公司管理。以为将公司各个部门管理好了，公司就好了，但其实这有什么用？公司只有提供、卖出热销的产品、服务，才能带来现金流，从而生存、壮大。那么如何开发好的产品？要根据客户群与商业步调，确定产品的功能，适用范围，用迭代和版本的方式，逐步扩展，

公司的目的就是盈利，确实是这样的。没有盈利，产品再好也没有用。程序员技术至上，对待自己的作品精雕细作，仿佛是自己的孩子，或无上的艺术珍品，往往忽略了写软件最主要的目的：把它们卖出去换钱，结果造成时间拖得太长。我以往因为考虑问题的角度，也跟普通程序员一样，也或多或少的犯这种错误。不过，保证软件必要的质量还是非常有必要。软件写得太烂，运行老出错，就要花很多时间来进行后期维护，甚至造成客户失去信心，