2020总结：软件工程，由分析需求到立项到测试再到？

CoffeeHub，由分析需求到立项到测试再到？

引言

奇幻的2020年不经意间走到了尽头，回顾这一年的软件工程学习，从面向对象理解到软件需求分析，从软件项目管理到软件质量测试与保证。就像走台阶一样，慢慢对“项目”这个概念有了自己的理解。秉持着学了就要去用的原则，何不用一个假想的项目将所学的只是串联起来，从项目的需求分析开始一步步的去分析、理解、学习？于是乎—— CoffeeHub ，Thank you for coming

需求分析

试问哪个程序员，不想坐在软软的沙发上，喝着高浓度咖啡因的咖啡，用着舒适的键盘敲着含百分之八十的bug的代码？相比于星巴克这种传统咖啡馆，Coffee Hub是专为程序员所打造的社区，在这里，你不用嫉妒别人的头发，因为大家都没剩下几根，24小时营业，准备的有睡袋和提神饮料，门口正对着市中心医院的ICU，专属发泄电话间，当您的老板又叫您深夜改代码时，您可以使用里面的沙袋，沙袋自带照片框，旁边就是打印机，房间完全隔音，你可以肆意发泄，无论是对老板还是老板的娘。自带社交属性，您可以向附近发量最少的资深从业者提问。Coffee Hub，做程序猿心中最酷的星巴克
从上段中可以发现，程序员是有需求的，如何提取出所需的需求就是需求分析所要做的事。

Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：项目最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。所以从我们的PROGRAMMER出发，分析他们的需求，是极为重要的。
否则的话，可能会发生：
老板对工程人员说：“我想要一个程序员可以快乐编程而我可以盈利的咖啡店”
这是原始需求，简单明了

施工队建到一半，老板喊停停停，“伙计们，不要吧台区域，太占地方了”
这是中途需求变更

施工队心想“我都快建完了，&@#……”只能慢慢拆
这是改动太大，部分重构

施工队开始准备休息区，老板“休息区给我加个喷泉吧，这不难对吧”
这是低估改动成本

施工队：“@喷泉还要改管道不难个！#@#，我还要重新规划”
这是新需求引入了新成本

老板：“我想了想，还是把吧台修好吧，客人还要点咖啡呢”
这是某一功能点摇摆不定

施工队都硬了，拳头硬了！！
但是还是老老实实的干
这就是甲方需求大于天

老板“这进度有点慢呀”
这是改动造成工期延误

施工队“没看见我在修喷泉的下水管吗？”
开发者请求重新排期

老板说“不行呀，太慢了，喷泉改成花台吧”
因工期过长再次改动需求

施工队“啊这，改花台也要花时间啊”
频繁改动造成大量堆积

老板：“怎么我们的咖啡店没有舞池？我看别的地方有呀”
奇葩需求

施工队满脸问号，但还是照做了舞池
有时候这就是甲方

终于完工了交付，老板“咦？这咖啡店怎么这么像夜店？”
这就是缺乏前期需求分析的恶果

/**
*老板让成员做事情
*/
class BOSS{
  String name;
    void do(PROGRAMMER p){
    while（true）{
        p.work();
        }
    }
    }
    /**
    *程序员老板一叫得工作do
    *得发泄
    *得找个舒服的地方
    */
class PROGRAMMER{
String name;
void do(){
//可能触发ICU方法
}
void abreact（BOOS b）{
}
void choose（COFFEEHUB c）{
}
void ICU（）{
}
}

程序员的需求看似很明确，他们需要有地方能写bug，有人能帮忙，得有地方急救，有地方发泄，而CoffeeHub这个虚拟项目需要满足用户的需求。对于一个合格的需求分析，需要有深入细致的调研和分析，准确理解用户对咖啡馆项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定项目必须做什么的过程。
所以当COFFEEHUB这个对象一定要有

class COFFEEHUB{
int sofa；
int coffee；
int desk；
void goICU（）{
}
void beatBoss（）{
}
void helper（）{
}
void dowork（Computer c，Sofa s，Coffee co）{
}
}

在总结完项目需求后，需要有项目需求文档，它是项目需求分析的最终结果。它的作用主要是：作为开发人员与用户之间事实上的技术合同说明；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。至此，大致的需求分析完成。

项目管理

虽然CoffeeHub有了明确的需求，但我们都知道事情的发展总不是一帆风顺的，我们写的软件也是，如果不提前规划好项目的进程，那么对于一个项目来说是致命的。根据Standish Group（美国专门从事跟踪IT项目成功或失败的权威机构）对50000个项目进行的研究结果表明，19%的项目彻底失败，52%的项目超出经费预算或者超出工期，只有29%的项目获得成功。成功的项目只是少部分，就比如我这种不到DeadLine不干活的程序员，如果没有项目进度计划，那一定会拖，就硬拖。同样的如果没有明确的文档说明，我不知道我是该去买沙发还是建房子，那团队合作就乱了套了，所以一定要有项目团队计划。凡事都有一个额度，项目也一样，成本估算就是为了防止超额支出导致资金链的断裂。所以，做好项目管理是非常重要的。
一个合格的项目，离不开的好的项目管理，我们的CoffeeHub也一样，当总结完软件的需求，完成了项目的计划书后，接下来对项目进行计划，分配任务，确定完成时间。项目管理需要总结出很多文件，方便以后项目的进行。就像盖金字塔，没有合格的管理者，一堆工人抱着砖头瞎转什么也干不好。我们的CoffeeHub在经过“严密”的分析之后，按照项目管理的流程进行。包括启动→规划→执行→监控→收尾

项目启动

盘古没开天之前，世界是一片混沌，项目也是。当一个项目启动时，首先要进行项目背景调查，以CoffeeHub举例，我们需要明确咖啡馆的干什么，怎么干，为谁干，合法吗，有什么战略；然后进行可行性分析—对整个CoffeeHub进行构思，分析成本效益，如何盈利，最后进行立项评审，需要有项目建议书，列出购买或自造计划等，如果购买，需要招投标，如果自造需要立项筹备，当一切流程完成后，才能让一个项目正式确立，同时我们还需要项目章程，来正式批准项目并授权项目经理在活动中使用组织资源。项目确立后，需要选择项目开发策略，选择生存期模型。由于我们的CoffeeHub有明确的需求，但还要根据用户的反馈进行修改，所以我们要选择增量型模型，如果顾客有需要可以更方便我们修改。

项目规划（重点）

1.项目范围计划。

盘古开天只需一挥，但想要构成山川河流，则需要千年的演化，项目规划阶段是对未来的预测。我们无法确定变数，但可通过规划让未来可控。首先要进行的就是项目范围的管理，去界定和控制CoffeeHub可以有什么和不包括什么。就像我老婆新垣结衣很美，即使很多程序员都想她陪着敲代码，但很明显她不能被划在CoffeeHub的范围内；项目范围对项目的影响是决定性的，它确定了项目工作内容的多少。有效的范围管理可以保证项目只做必须做的事情，避免范围蔓延和做无用功，同时也避免不清晰的需求所导致的严重的系统缺陷。 参照之前的需求分析，明确项目范围。
但如果程序员不停地埋怨厕所数量太少，该怎么办？需求管理活动——变更控制，建立变更控制委员会CCB去审查、评价、批准、推迟或否决项目变更。如果CoffeeHub建着建着变成酒吧怎么办？需求管理活动——需求跟踪，建立和维护从用户需求到测试的一致性与完整性，确保实现都以客户需求为基础，实现的需求覆盖了预期的需求，并确保输出与用户需求的符合性。

2.项目进度计划。

讲一个有关游戏的笑话：在《永远的毁灭公爵》跳票的时候，《哈里波特》系列从第1部出到了第7部并且完结，全部7部都被改编成了电影。由此可见，项目进度（时间）管理是多么重要，它是指在项目的具体实施过程中，为了确保项目能够按照计划准时完成而展开的项目活动定义、活动排序与历时估算、制订进度计划、进度控制等方面的管理活动。
为各个相互关联的活动标注了计划日期、持续时间、里程碑和所需资源等。常以图形方式表示，如甘特图、里程碑图、进度网络图等。以下就是甘特图：

如果项目即将超出预期，则需要赶工，需要注意的是，赶工是会增加相应成本的

3.项目质量计划。

建好了一个像模像样的咖啡馆，结果进去之后，发现这破破烂烂的，那脏兮兮的，这怎么行？项目是需要保证质量的。质量是一个项目的生命线。质量管理计划就是为了实现项目的质量目标，对项目的质量管理工作所做的全面规划。
项目质量管理是为了保证项目最终能够达到预期的质量目标而进行的一系列的管理过程。 具体过程包括：
制定项目质量计划（规划质量管理）：将与项目有关的质量标准标识出来，提出如何达到这些质量标准和要求的设想。
项目质量保证（管理质量）：将质量管理计划转化为可执行的质量活动，来保证项目执行过程满足预先定义的过程。
项目质量控制：对阶段性的成果进行测试、验证，为质量保证提供参考依据

4.项目成本计划。

最豪华的沙发，买！最好喝的咖啡，买！最好看的女仆，聘！大手大脚的花费过了，什么都追求最后发现项目的成本超出预期，只能烂尾，从软件项目管理的提出到现在，“按时、按预算完成项目”一直事管理者们的最大挑战。项目成本管理是项目管理知识体系的核心部分之一，它是指在项目的具体实施过程中，为了保证完成项目所花费的实际成本不超过预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。
如果你只有100元，你要想的不是1000元的东西多么好，而是全力去让着100元发挥出它最大的价值。如何确定手里该有多少钱呢？我们需要进行软件项目成本估算。但要注意的是，软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。
想要确定软件成本首先要确定项目规模：此时需要WBS(Work Breakdown Structure，任务分解结构)

有了WBS后，还必须对软件规模进行估计。
LOC(Lines of Code)：源代码长度的测量
FP(Function Point)：用系统的功能点数量来测量
（详细的可看我的软件需求分析总结）
有了大致的成本后，还需要进行项目成本控制，因为计划总改不上变化，但不是所有变化我们都能接受的。

5.风险计划。

凡事都有风险，再小的水湾都淹死过人，风险是不可避免的，项目中的风险也一样，一些风险是可预期的，像可能有工人怠工之类的，有些是不可预期的，比如突然隔壁失火，烧到这边了。所以我们要做的，是风险管理。
风险管理是指在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程。
关于风险管理，可分以下几个步骤：
项目风险控制程序
1．建立项目风险事件控制体制
2．确定要控制的具体项目风险
3．确定项目风险的控制责任
4．确定项目风险控制的行动时间
5．制订各具体项目风险的控制方案
6．实施具体项目风险控制方案
7．跟踪具体项目风险的控制结果
8．判断项目风险是否已经消除

项目执行

项目规划完毕后，我们应有《项目需求管理》《项目成本估算》《项目进度计划》《项目质量计划》《项目配置管理计划》《项目管理计划》等文档，通过这些文档，让项目稳步走起来。

项目测试

依据项目管理的计划，我们终于可以将CoffeeHub交付了，但在交付前，我们还需要对CoffeeHub进行测试。测试是很重要的环节，包括了需求测试，单元测试，集成测试，性能测试，压力测试，容量测试，配置测试，回归测试，安装测试和安全性测试。让我们一步一步来。

1. 需求测试：抓到一个程序员，问他想不想去。测试通过
2. 单元测试：利用CoffeeUnit，针对点咖啡这个小单元进行测试。result是一杯coffee，派一个程序员进去点单。测试通过
3. 集成测试：承接上一个测试，将点咖啡和各种各样的服务单元相连接，派一个程序员去点咖啡打boss写bug。测试通过。
4. 性能测试：派100个人去点咖啡，设定时间，看能否按时完成。测试通过
5. 压力测试：利用自动化程序员程序，一会派一个程序员进去，看什么时候程序员挤不进去。测试通过
6. 容量测试：利用自动化程序员程序，一会派一个程序员进去，看什么时候程序员没有位置坐。测试通过
7. 配置测试：CoffeeHub换一个地方看能否正常营业，测试通过
8. 回归测试：换了一种咖啡，在营业试一试。测试通过
9. 安装测试：开好的CoffeeHub，砸了再重新安装，在营业试试。测试通过。
10. 安全测试：派一个小偷小摸的程序员进去试一试 ，看能否逮到。测试通过

正式上线！！！

第一个程序员走进咖啡厅，点了一份泡面，CoffeeHub崩溃，成功运行1分钟