C#软件开发过程管理和控制

你好，这是一份word文档，可供下载。

这是我自己写的，不一定正确，也不一定实践中可真正执行，供您参考学习。

---

 

软件开发过程管理和控制

 

 

目录

1.    过程控制及管理思想... 

2.    什么是敏捷开发... 

3.    敏捷开发方法采用哪种... 

4.    敏捷开发的适用条件... 

1. 面向对象模型... 
2. 中小规模的软件开发... 
3. 高素质的开发团队... 
4. 集中的开发环境... 
5. 客户合作的项目... 
6. 需求会发生变化... 

5.    软件开发的过程控制及管理... 

1. 整体业务需求确认... 
2. 简单的全局思维导图设计... 
3. 确定里程碑... 
4. 确定迭代计划... 
5. 每日站会... 
6. 简单建模... 
7. 持续集成... 
8. 重构... 
9. 测试... 
10. 编码规范... 
11. 代码审查及共享... 
12. 迭代成果演示... 
13. 迭代回溯管理... 

6.    敏捷开发框架... 

7.    参考文档... 

 

 

1. 过程控制及管理思想

软件开发过程控制管理的思想，主要有传统软件工程以及敏捷开发两种思想。由于传统软件工程思想的弊端，本文档主要以敏捷开发思想为指导编写。

敏捷开发是一种软件工程思想，是虚的，它会指导你软件开发过程中采用什么方式方法来实施软件工程。根据此指导思想，产生了多种敏捷开发方法。

 

2. 什么是敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

 

敏捷开发方法目前主要有以下几种：

l  XP(极限编程)

l  SCRUM

l  Crystal Methods(水晶方法)

l  FDD(特性驱动开发)

l  ASD(自适应软件开发)

l  DSDM(动态系统开发方法)

l  RUP(轻量型过程框架)

 

3. 敏捷开发方法采用哪种

目前各种敏捷开发方法各有优异之处，我们主要参考Scrum方法进行过程控制管理。但实践并不仅限于Scrum，也会吸收其它敏捷开发方法的优点，不宜将流程固化，可以进行灵活变通，达到最适宜公司团队适合的开发方法。

 

4. 敏捷开发的适用条件

根据敏捷开发的特点，其使用也有一定的适用条件：

1)    面向对象模型

这是核心关键。面向对象模型的作用在于快速迭代和持续集成代码，并快速重构和测试。

2)    中小规模的软件开发

中小规模的软件开发，可以减少沟通上的成本，提升敏捷过程

3)    高素质的开发团队

团队不仅对技术能力有要求，更需沟通和团队协作能力

4)    集中的开发环境

集中环境可以有效提升敏捷快速过程

5)    客户合作的项目

需求方(客户)可以及时响应并应答需求问题，可以快速提升敏捷过程

6)    需求会发生变化

敏捷开发更加适用于需求较多变化的项目开发

 

5. 软件开发的过程控制及管理

软件开发控制管理，不宜死板固化，以下流程应根据实际效果进行优化和调整。团队开发人员数量建议5-9人每组。

 

1)    整体业务需求确认

产品需求负责人提出需求，全体开发人员参与，并初步确定产品商业价值顺序。 实际迭代过程中商业价值顺序可调整。

 

2)    简单的全局思维导图设计

这项工作有助于纵观全局，做到整体衔接。防止后期业务复杂后的修改维护成本过高。应将此思想结果传递给全体开发人员。

 

3)    确定里程碑

由团队编写大致工作项，工作项即backlog，可以使用一些工具列出并汇总，然后做出工作量预估，以3个月为一周期，分阶段立项出产品目标，我们称每一个阶段为里程碑。

每一个里程碑会有多次迭代，通过多次迭代开发，最终达到实现阶段性里程碑的目的。

 

4)    确定迭代计划

每个迭代计划尽可能保持在2-4周范围内。每次迭代计划会议应在4小时内结束。根据产品需求负责人确定需求优先级，以及团队对工作量的估算，来决定是否将此次开发计划列入本次迭代计划中

 

5)    每日站会

每天早上开发团队应开始一个短暂的会议，以15分钟内结束为宜。每个成员应表述以下问题：

(1)  我昨天完成了哪些工作

(2)  我今天准备做哪些工作

(3)  我遇到了什么问题

 

此步骤是为了让团队参与者增进信息共享，并确保问题及时反馈和处理。

 

6)    简单建模

开发者应进行简单建模，这可以让开发者快速了解工作任务，然后开展工作。简单建模还具备与其它开发者沟通交流想法的功能。

简单建模可以让开发者学会架构模式、设计模式和分析方法，并把他们应用在模型之中。这对开发人员的成长很有利，并对项目后期的方便重构埋下伏笔。

建模以简单为理念，可以画在UML上，也可以画在纸上，一切如你愿，方便就好。

 

7)    持续集成

软件开发是整个团队的事情，每个人都会有自己的任务，各个成员的开发成果的兼容性和接口，需要尽可能在较短的时间内进行集成，然后马上做回归测试并进行反馈和修改迭代。

如果等汇集了很多成果后再进行集成，将可能引发大面积的意想不到的问题，且错误定位相对困难。

集成的时间尽可能短，如果可以，一天内多次集成会更好。

 

8)    重构

不可避免的会因为各种原因需要对软件进行修改，这需要调整、优化系统，增加灵活性和提高性能。重构时应尽可能不改变外部行为，而是在内部进行 。

重构应贯穿整个开发流程，每次重构完成应及时进行回归测试。

重构应遵循面向对象思想，否则重构的意义将散失，因为本次重构终将再次重构。

 

9)    测试

软件需要持续测试，不论是单元测试、功能测试还是集成测试等，尽可能实现自动化测试。

测试要及时，结果反馈也要及时。敏捷过程要求时间尽可能短，测试版本尽可能小。

 

10) 编码规范

遵守编码规范，可以让开发人员之间减少不必要的沟通成本，达到敏捷，编码规范也是代码审查及共享的基础。这是编程的重要原则之一。

 

11) 代码审查及共享

应使用人工或者自动化做代码审查，以判断是否符合编码规范。

结对编程有助于开发人员了解整个系统，而不至于任一人员请假或离职时，无法处理问题。

结对编程通常指一个人负责编码，一个人负责审查代码并保证代码的正确性和可读性。结对编程的对子不是固定的，时常流动交换，使得每个开发人员都有编码和审查的机会，这可以让知识和技能在项目中比较好的进行共享和传承。

 

12) 迭代成果演示

在每一个迭代周期(2-4周)结束后，应进行迭代成果演示，参与者为产品需求负责人和全体开发人员，演示开发成果。

通过本次演示，应判断是否达到预期目标，以及存在哪些问题，要如何解决等。为下一个迭代计划做准备。

 

13) 迭代回溯管理

在进行迭代成果演示后，要马上进行(一般在第2天)全体开发人员会议。回顾并反思本次迭代周期所遇到的经验和教训，要如何改进等。

同时开始迭代下一周期的计划会议，会议应在4小时内结束。

 

6. 敏捷开发框架

协助软件进行过程控制的工具有不少，这些工具以敏捷开发框架的形式提供。具有良好的流程控制、任务标记及统计等特性。我所知道的有：

l  华为云

 

 

l  力软

利用这些敏捷框架，可以尽可能的规范开发流程，达到一定的管理控制效果。

 

 

7. 参考文档

无法放链接，请看附件。

 

8. 工具

工作项可以使用Microsoft Office Project；

建模工具可以使用UML；

管控工作项及进度可以使用Microsoft Office Project的甘特图，也可以使用敏捷开发框架自带的燃尽图；

思维导图可以使用XMind

 

附件下载：https://download.csdn.net/download/mazhiyuan1981/13105284

本文地址：https://blog.csdn.net/mazhiyuan1981/article/details/109627083