软件开发模式

1、软件开发模式、夏小游如何打造一个梦想中心？你所熟悉的过程一、定位？时间？资源？目标？出个tor吧！=可行性研究与计划二、老师要什么？学生要什么？捐赠人要什么？出个需求调研报告吧！=需求分析三、是pad还是电脑？涂料选啥颜色？要不要加个3d打印机？出个设计稿吧！=设计四、货到了，要找个当地的师傅刷墙、布线、铺地板，出个建设指南吧！=开发五、书都摆上书架吗？pad有装错吗？出个竣工报告吧！=测试六、喂，真爱梦想吗？梦想中心电脑坏了，能帮忙重装下系统吗？成立个vot吧！=运维瀑布模型瀑布模型是典型的传统软件开发模型之一特点：自上而下，固定次序，逐级下落优点：开发的各个阶段比较清晰强调早期计划及需求调

2、查适合需求稳定的产品开发缺点：依赖于早期需求调查，不适应需求的变化在项目各个阶段之间极少有反馈。风险往往迟至后期才显露，失去尽早纠正的机会瀑布模型第一帕、传统软件开发模式开发模型边做边改模型（build-and-fix model）瀑布模型（waterfall model）快速原型模型（rapid prototype model）增量模型（incremental model）螺旋模型（spiral model）演化模型(evolution model)喷泉模型(fountain model)更多螺旋模型uml（统一建模语言）作用：用于对软件密集型系统的制品进行可视化、详述、构造和文档化的图形语

3、言。特点：uml规范用来描述建模的概念有，类（对象的）、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态。uml从考虑系统的不同角度出发，定义了10类图：用例图、类图、对象图、包图、状态图、时序图/顺序图、合作图、活动图、构件图、配置图。建模概念用例图类图活动图状态图序列图v-modle单元测试：按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译。集成测试：将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等。系统测试：把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功

4、能等是否和用户需求相符合，在系统中运行是否存在漏洞等。验收测试：用户验收时根据需求、规格说明书来做相应测试，以确定软件达到符合效果的。v-modlewbs/pbspbs（产品分解结构）：通过树状结构反映产品的各类部件，每类部件在结构中仅出现一次。wbs（工作分解结构）：对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。pbswbs甘特图作用：可以直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。横轴表示时间纵轴表示活动（项目）线条表示在整个期间上计划和实际的活动完成情况含义：以图形或表格的形式显示活动。现在是一种通用的显示进度的方法。构造

5、时应包括实际日历天和持续时间，并且不要将周末和节假日算在进度之内。甘特图软件变更管理主要任务：1、分析变更的必要性和合理性，确定是否实施变更。2、记录变更信息，填写变更控制单。3.、做出更改，并提交审批。 4、修改相应的软件配置项（基线），确立新的版本。 5、评审后发布新版本。变更表q：传统软件开发模式有何优劣势？guangyu long总结“传统软件开发特点是交付阶段明确定义、每环节要求交付件与评审；质量控制严谨；项目周期长；不易管理变更。”第二帕、敏捷软件开发模式用户故事第一步、解释故事。1. 用户投入一些钱。2. 售货机显示用户已经投了多少钱。3. 如果投入的钱足够买某种饮料，这种饮料对

6、应的按钮的灯就会亮。4. 用户按了某个亮了的按钮。5. 售货机卖出一罐饮料给他。6. 售货机找零钱给他。第二步、评估开发时间-故事点卖饮料 4取消购买 2输入管理密码 1补充饮料 3取出钱箱里的钱 1安全警报 2打印月销售报表 4总计 17客户需求：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”q：假设一个故事点5人日，有2个开发人员，请预估开发时长？q：一个迭代（2周10个工作日）之后，完成了2.5个故事点，请重新预估开发时长？q：故事点与传

7、统工作量的预估方式有何区别？用户故事极限编程（xp）极限编程（xp）：一种针对业务和软件开发的方法，其作用在于将两者的力量集中在共同的、可以达到的目标上，使xp团队以可持续的步调生产优质的软件。基于敏捷的核心思想和价值目标，xp要求项目团队遵循13个核心实践。团队协作(whole team)规划策略(the planning game)；结对编程(pair programming)测试驱动开发(testing-driven development)重构(refactoring)简单设计(simple design)代码集体所有权(collective code ownership)持续集成(continuous integration)客户测试(customer tests)小型发布（small release）每周40小时工作制（40-hour week）编码规范（code standards）系统隐喻（system metaphor）价值与风险驱动小项目、小团队的开发管理比较纯粹在人员比较多、项目比较复杂的情况下，价值与风险的因素需要有个治理的守候框架