开发方法

• 软件生命周期
  • 　　软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法
    软件生命周期的8个阶段：
    • • 　　　　可行性研究与计划、需求分析、概要设计、详细设计实现、集成测试、确认测试、使用和维护 
        • • （1）可行性研究计划：在决定是否开发软件之前，首先需要进行可行性研究。通过可行性研究，来确定开发此软件的必要性，并根据可行性研究的结果初步确定软件的目标、范围、风险、开发成本等内容。从而制定出初步的软件开发计划。通过可行性研究，如果确定该软件具有研发的必要，则将产生《可行性研究报告》和《软件开发计划》，并进入需求分析的阶段。 
          • （2）需求分析：需求分析是软件开发中的重要阶段。初步确定了软件开发的目标和范围，之后则需要对软件的需求进行细致的分析，来确定软件要做什么。
          • （3）概要设计：高腰设计确定整个软件的技术蓝图，负责将需求分析的结果转换为技术层面的技术方案。在概要设计中，需要去诶的那个系统架构，各子系统间关系，接口规约，数据库模型，编码规范等内容。概要设计的结果将作为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作。
          • （4）详细设计：详细设计完成编码前后的设计，详细设计在概要设计基础上，进行细化，如类设计。详细设计不是开发过程中必需的阶段，在一些规模较小，结构简单的系统中，详细设计往往被省略
          • （5）实现：实现过程包括编码和单元测试。但愿策划四指的是对刚刚编写的一个小程序单元测试。有效的单元测试可以大大提高编码质量，降低软件系统的缺陷率、
          • （6）集成测试：集成测试成为组装测试。通过单元测试程序并不意味着没有缺陷当程序单元被集成到一起进行交互的时候往往会出现单元测试中不能发现问题。
          • （7）确认测试:当完成测试后，软件之间接口方面的错误已经派出，这是需要验证软件是否同需要一致，是否达到预期目标。经过确认测试的软件投入正常使用，并进入维护期、
          • （8）使用和维护：即使通过单元测试，集成测试和确认测试，也不可能发现软件系统缺陷：软件系统的需求也会根据业务的发展变化而变化。因此在软件使用过程中，必须不断对软件进行维护，维护的过程贯穿整个软件的使用过程维护结束，生命结束。
        • 
          
          
          
• 软件开发模型
  • • 　　瀑布模型　

      

      • 　　瀑布模型软件开发的阶段划分是明确的一个阶段倒下一个阶段有明显的分界线。每个阶段结束后，都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后，需要明确的描述软件需求文档；总体设计结束后，需要有描述软件总体的文档；详细设计结束后，需要有可以用来编码的详细设计文档；而编码结束后，代码被作为文档流到下一个阶段，因此也成为瀑布模型是面向文档的软件开发模型。
    • 瀑布V模型：
      • 　　瀑布 V 模型是瀑布模型的一种变体。
        
      • 
      • 演化模型
      • 螺旋模型

        • 

           

           

          演化模型的另一种形式是 增量模型。（在系统的技术架构成熟、风险较低的时候，可以采用增量方式进行系统开发，这也可以提前进行集成测试和系统测试，缩短初期版本的发布周期）

        • 

           

           构建组装模型的优点：

          • • （1）构件的自包容性让系统的扩展变得更加容易
            • （2）设计良好的构建更容易被重用，降低软件的开发成本
            • （3）构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将团队分成若干组，并行地独立开发构件。
        • 构建缺点：
          • • （1）对构件的设计需要经验丰富的架构师，设计不良的构件难以实现构件的优点，降低构件组装模型的重用度。
            • （2）在考虑软件的重用度时，往往会在其他地方做出让步，如性能。
            • （3）第三方构件库的质量会最终影响软件的质量，而第三方的构件质量往往是开发团队难以控制的　　　　
• 统一过程（UP）
  • 　　UP的二维模型

 

 

 

• UP的生命周期
  • （1）目标里程碑。目标里程碑对应着先期阶段的结束，当开发者可以明确软件系统的目标和范围时即达到了该里程碑
  • （2）架构里里程碑。
  • （3）能力里程碑
  • （4）发布里程碑

 

 　　3.UP的特点

　　（1）UP是一个迭代的二维开发模型，在生命周期的每一阶段都可以进行需求、设计等活动

　　（2）采用不同迭代特点使用跟更容易控制软件开发的风险，

　　　架构师在UP中的活动

　　　　（1）同需要人员和项目管理人员密切

　　　　 （2）细化软件架构

　　　　 （3）保持整个架构的概念完整性。具体地说，架构师不但需要设计系统架构，还需要定义设计方法设计指南，编码指南，评审设计等工作。UP也是一架构为中心的开发模型。

 

• 敏捷方法
• 1.XP（极限编程）的组成由价值观、原则、实践、和行为四部分 ,
• 四大价值观:沟通，简单，反馈，勇气---->尊重
• 2.十二个最佳实践
  • （1）计划游戏  （2）小型发布 （3）隐喻（4）简单设计 （5）测试先行（6）重构
  • （7）结对编程（8）集体代码所有制（9）持续集成（10）40H/周（11）现场客户（12）编码标准
• 　　特征驱动（FDD）
• 　　FDD三个要素：人、过程、技术
• FDD角色定义：（1）项目经理 （2）首席架构师（3）主程序员 （4）开发经理 （5）程序员 （6）领域专家[业务]
• 
• Scrum的五个活动：产品代办事项列表梳理；spring计划会议，每日Scrum会议，Sprint评审会议，Sprint回顾会议。
• 水晶方法(Crystal):提倡”机动性“方法
• 水晶方法七个特征
• （1）经常交付
• （2）反思改进
• （3）渗透交流
• （4）个人安全
• （5）焦点
• （6）与专家用户建立方便的联系
• （7）配有自动测试、配置管理和经常集成成功能的技术环境

　　　　　　　　其他敏捷方法：ASD方法：（Adaptive Software Development ）方法其核心是三个非线性，重叠开发阶段:猜测、合作学习

　　　　　　　　常见的软件重用形式包括：

　　　　　　（1）源代码重用 （2）架构重用 （3）应用架构的重用 （4）业务建模的重用 （5）文档及过程的重用 （6）软构建的重用 （7）软件服务的重用

　　　　　　　　构建技术（组件）：是一种自包容、可重复用的程序集。首先，构建是一个程序集，或者说是一组程序的集合。

　　　　　　　　构件的两个重要的特性是自包容与可重用。自包容指的是构件本身是一个功能完整的独立体。构建内部与外部的功能界限清晰明确，可以

• 软件重用
  • 中间件、应用服务器　　
• 基于架构的软件设计（ABSD）是一种驱动方法
• (1):功能的分解ABSD 方法使用自己有的基于模块的内聚和耦合技术 （2） 通过选择架构风格来实现质量和业务需求（3）软件模版的使
• 软件模版是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。
• 用

•  

   ABSD 方法的输入由下列部分组成：
  （1）抽象功能需求，包括变化的需求和通用的需求；
  （2）用例（实际功能需求）；
  （3）抽象的质量和业务需求；
  （4）质量因素（实际质量和业务需求）；
  （5）架构选项；
  （6）约束。

• 

   

   

• 形式化方法

　　

 

来源：https://www.cnblogs.com/yangpengli/p/11545400.html