软件开发模式

软件开发模式龙广宇、夏小游 如何打造一个梦想中心？ 你所熟悉的过程一、定位？时间？资源？目标？出个TOR吧！=可行性研究与计划二、老师要什么？学生要什么？捐赠人要什么？出个需求调研报告吧！=需求分析三、是PAD还是电脑？涂料选啥颜色？要不要加个3D打印机？出个设计稿吧！=设计四、货到了，要找个当地的师傅刷墙、布线、铺地板，出个建设指南吧！=开发 五、书都摆上书架吗？PAD有装错吗？出个竣工报告吧！=测试六、喂，真爱梦想吗？梦想中心电脑坏了，能帮忙重装下系统吗？成立个VOT吧！=运维 瀑布模型瀑布模型是典型的传统软件开发模型之一特点：自上而下，固定次序，逐级下落优点： 开发的各个阶段比较清晰 强调早期计划及需求调查 适合需求稳定的产品开发缺点： 依赖于早期需求调查，不适应需求的变化 在项目各个阶段之间极少有反馈。 风险往往迟至后期才显露，失去尽早纠正的机会 瀑布模型 第一帕、传统软件开发模式 开发模型 边做边改模型（Build-and-Fix Model） 瀑布模型（Waterfall Model） 快速原型模型（Rapid Prototype Model） 增量模型（Incremental Model） 螺旋模型（Spiral Model） 演化模型(evolution model) 喷泉模型(fountain model)更多 螺旋模型 UML（统一建模语言）作用：用于对软件密集型系统的制品进行可视化、详述、构造和文档化的图形语言。特点： UML规范用来描述建模的概念有，类（对象的）、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态。 UML从考虑系统的不同角度出发，定义了10类图：用例图、类图、对象图、包图、状态图、时序图/顺序图、合作图、活动图、构件图、配置图。 建模概念 用例图 类图活动图 状态图序列图 V-MODLE 单元测试：按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译。 集成测试：将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等。 系统测试：把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。 验收测试：用户验收时根据需求、规格说明书来做相应测试，以确定软件达到符合效果的。 V-modle WBS/PBSPBS（产品分解结构）：通过树状结构反映产品的各类部件，每类部件在结构中仅出现一次。WBS（工作分解结构）：对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。 PBS WBS 甘特图作用：可以直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。 横轴表示时间 纵轴表示活动（项目） 线条表示在整个期间上计划和实际的活动完成情况含义： 以图形或表格的形式显示活动。 现在是一种通用的显示进度的方法。 构造时应包括实际日历天和持续时间，并且不要将周末和节假日算在进度之内。 甘特图 软件变更管理主要任务：1、分析变更的必要性和合理性，确定是否实施变更。2、记录变更信息，填写变更控制单。3.、做出更改，并提交审批。 4、修改相应的软件配置项（基线），确立新的版本。 5、评审后发布新版本。 变更表 Q：传统软件开发模式有何优劣势？ Guangyu Long总结“传统软件开发特点是交付阶段明确定义、每环节要求交付件与评审；质量控制严谨；项目周期长；不易管理变更。” 第二帕、敏捷软件开发模式 用户故事第一步、解释故事。1. 用户投入一些钱。2. 售货机显示用户已经投了多少钱。3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。 4. 用户按了某个亮了的按钮。5. 售货机卖出一罐饮料给他。6. 售货机找零钱给他。第二步、评估开发时间-故事点卖饮料 4取消购买 2输入管理密码 1 补充饮料 3取出钱箱里的钱 1安全警报 2打印月销售报表 4总计 17 客户需求：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。” Q：假设一个故事点5人日，有2个开发人员，请预估开发时长？Q：一个迭代（2周10个工作日）之后，完成了2.5个故事点，请重新预估开发时长？Q：故事点与传统工作量的预估方式有何区别？用户故事 极限编程（XP）极限编程（XP）：一种针对业务和软件开发的方法，其作用在于将两者的力量集中在共同的、可以达到的目标上，使XP团队以可持续的步调生产优质的软件。基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践。1. 团队协作(Whole Team)2. 规划策略(The Planning Game)； 3. 结对编程(Pair programming)4. 测试驱动开发(Testing-Driven Development)5. 重构(Refactoring)6. 简单设计(Simple Design)7. 代码集体所有权(Collective Code Ownership) 8. 持续集成(Continuous Integration)9. 客户测试(Customer Tests)10. 小型发布（Small Release）11. 每周40小时工作制（40-hour Week）12. 编码规范（Code Standards） 13. 系统隐喻（System Metaphor） 价值与风险驱动小项目、小团队的开发管理比较纯粹在人员比较多、项目比较复杂的情况下，价值与风险的因素需要有个治理的守候框架 Q：敏捷软件开发模式有何优劣势？ 总结个体和交互 重于 过程和工具可以工作的软件 重于 求全责备的文档客户协作 重于 合同谈判相应变化 重于 循规蹈矩 第三帕、互联网开发模式 特点业务敏捷性开发敏捷性开发测试云自动化 DevOps (软件持续交付)