开发与运行

首先，理解两种模式：

无主程序员小组（民主式小组）：所有成员之间相互平等，每个成员都可以与其他成员沟通。所以对于n个成员，沟通路径数是组合数C(n,2)= n*(n-1)/2，因为每两人之间有一条沟通路径。

主程序员负责制小组：有一个主程序员和若干成员，成员之间没有沟通，只能与主程序员沟通。所以沟通路径是主程序员与每个成员之间的路径，即如果有1个主程序员和m个成员，总人数n = 1+m，那么沟通路径数就是m（因为每个成员与主程序员有一条路径），或者说是n-1。

1. 甘特图（Gantt Chart）
   形式：一种横向条形图，横轴表示时间，纵轴列出项目活动，条形长度表示活动的起止时间和持续时间。
   特点：
   直观展示活动的时间安排、重叠关系和进度状态。
   易于理解，适合用于资源分配和进度跟踪。
   但无法清晰显示活动之间的逻辑依赖关系，也难以直接识别关键路径。

2. PERT图（Program Evaluation and Review Technique）
   形式：一种网络图，用节点（通常表示事件）和箭线（表示活动）来描绘活动之间的逻辑关系。
   特点：
   强调活动之间的前后顺序和依赖关系。
   通过三种时间估计（乐观、悲观、最可能）来计算活动工期和项目总工期，适用于不确定性较高的项目。
   可以识别关键路径和浮动时间，便于进行风险分析和资源优化。

   开始 → A(3) → B(5) → C(4)
            ↘ D(2) → E(3) → F(6)

3. 关键路径法（CPM）图
   形式：与PERT图类似，也是网络图，但通常用节点表示活动，箭线表示关系。
   特点：
   假设活动工期是确定的，侧重于计算项目的最短工期和关键路径。
   与PERT的主要区别在于：CPM使用单一时间估计，而PERT使用概率时间估计。

    开始
     | \   \
     |  \   \
     A(3) B(5) C(4)
     |    / \   |
     |   /   \  |
     D(2)   E(3) F(6)
       \    /   / \
        \  /   /   \
         H(1)       I(3)
           \       / \
            \     /   \
             J(2)     K(2)
               \     /
                \   /
                 L(2)
                  |
                 结束

4. 其他工具
   里程碑图（Milestone Chart）：仅标记关键里程碑（重大事件）的时间点，用于高层汇报和总体进度控制。
   工作分解结构（WBS）：以层次化树状结构分解项目工作范围，不涉及时间安排，但是制定进度计划的基础。
   时间线图（Timeline）：类似简化的甘特图，通常只显示主要事件或活动的时间线。
   

估算模型主要基于一个核心关系：
工作量 = (估算的软件规模) × (生产率相关的调节因子)

根据对 “软件规模” 的度量方式不同，主要分为以下几大类：

COCOMO模型（构造性成本模型）

COCOMO基本是静态单变量模型
COCOMO中级是静态多变量模型
详细COCOMO分三层级加额外考虑
功能点分析
从用户外部视角度量软件提供给用户的“功能”规模，与技术实现无关。

五类功能组件：

外部输入：用户输入的数据。
外部输出：系统输出的数据（报告、消息）。
内部逻辑文件：系统内部维护的数据。
外部接口文件：与其他系统交互的数据。
外部查询：输入后立即得到输出的简单交互。
计算步骤：

识别并计数上述五类组件的数量。
根据复杂度（低、中、高）为每个组件分配权重。
计算未调整功能点数。
考虑14个通用系统特性（如数据通信、性能要求等），计算值调整因子。
最终功能点数 = 未调整FP × VAF。
转换为工作量：
工作量(人月) = 最终FP数 / 生产率(FP/人月)
（生产率需根据组织历史数据或行业基准确定）
用例点分析法
适用于基于UML用例图进行需求分析的项目。

计算步骤：

计算未调整用例权重：根据参与者和用例的复杂度（简单、一般、复杂）分配权重并求和。
计算技术复杂度因子和环境复杂度因子。
计算调整后的用例点数。
根据一个用例点对应多少人时的生产率经验值，估算总工作量。

Putnam模型（SLIM）
一种基于瑞利曲线分布和经验数据库的动态多变量模型。

核心思想：工作量在项目生命周期中的分布符合特定曲线。

需要输入：规模、项目时长、一个称为“生产率指数”的环境常量。

可求解在给定规模下，理论上可能的最短开发时间。

建筑图纸 = UML图，让所有工人看懂同一套标准
地铁线路图 = 展示功能流转的路径
微信群聊记录 = 展示系统各部分如何按时间顺序"对话"
UML就是用一套全球通用的图形符号，把看不见摸不着的软件系统变成"可视化"的设计图，让产品经理、程序员、客户都能用同一种语言沟通。

UML到底有啥用？

1. 团队沟通的"普通话"
   避免开发中常见的"鸡同鸭讲"：

产品经理说"要有个智能推荐功能"
程序员可能理解为"基于用户历史的推荐"
老板心里想的是"像抖音那样的算法推荐"
UML图把想法画出来，大家对着图讨论，一图胜千言。

2. 编码前的"彩排"
   没图纸就盖楼，容易盖到一半发现承重墙有问题。写代码前先画UML：
   提前发现逻辑漏洞和设计缺陷
   避免写完代码后大面积返工
   让复杂系统变得清晰可拆解
3. 项目的"设计日记"
   半年后回看代码，你可能忘记"当时为什么这么设计"。UML图就是你的技术档案：
   新人通过图快速理解系统架构
   维护和升级时有据可查
   降低人员交接的成本
   
   例子：设计电商系统时

用用例图画出用户可以"浏览商品"、"下单"、"支付"
用类图设计"商品"、"订单"、"用户"这些核心对象的关系
用时序图分析下单时从前端到数据库的完整调用流程

UML是软件行业的"标准工程语言"——用图说话，让复杂系统变得清晰可见，磨刀不误砍柴工，前期画图越充分，后期返工就越少。

1.概要设计（高层设计）：考虑 “系统由哪些部分组成，它们之间如何连接”。相当于画房屋的整体结构图（有几层、几个房间、楼梯在哪）。

2.详细设计（底层设计）：考虑 “每个部分内部具体如何实现”。相当于画每个房间的详细装修图（插座位置、水管走向、墙面材料）。

两种设计方法的对比

举个例子：设计一个“在线购物系统”
结构化设计思路
概要设计：
模块划分：用户模块、商品模块、订单模块、支付模块。
数据设计：设计用户表、商品表、订单表。
接口设计：用户模块调用订单模块时需要传递哪些参数。
详细设计：
订单模块内部：用一个链表存储订单项，用快速排序对订单排序等。

面向对象设计思路
概要设计：
识别类：Customer、Product、Order、Payment。
类之间的关系：Order 包含多个 Product，Customer 拥有多个 Order。

详细设计：
细化 Order 类：属性 orderId、totalPrice；方法 calculateTotal()、generateInvoice()。
应用设计模式：比如用 Factory 模式创建 Payment 对象。

核心区别总结
结构化设计：像流水线，关注步骤和功能模块，模块通常是函数或过程。
面向对象设计：像乐高积木，关注事物和对象，模块通常是类和构件。

1. 非直接耦合
   关系：两个模块之间没有直接联系，它们通过一个主控模块或中间模块来协调。

比喻：两个人完全不认识，他们所有的沟通和任务交接都通过一个项目经理（第三方） 来完成。他们彼此独立，互不影响。

代码示例：模块A和模块B都只被主程序调用，它们之间不互相调用，也不共享任何数据。

评价：最理想的耦合，独立性最强。

2. 数据耦合
   关系：模块之间通过参数传递基本数据类型的数据进行通信。

比喻：一个人（A）需要另一个人（B）帮忙计算。A把原始数据（比如一串数字）交给B，B算好后把结果（一个数值）返回给A。A不关心B怎么算，B也不需要知道A的更多信息。

代码示例：result = calculateTax(income, rate); 这里只传递了收入和税率两个基本数据。

评价：理想的耦合，是设计时应该追求的主要方式。

3. 标记耦合
   关系：模块之间通过参数传递一个数据结构（如记录、对象），但被调用模块只用到该结构中的一部分数据。

比喻：A把一个完整的公文包（数据结构）递给B，但B只需要里面的一份文件。公文包里的其他文件对B来说是无用信息。

代码示例：传递一个完整的 Student 对象给 printStudentName() 函数，而这个函数其实只需要 student.name 属性。

评价：比数据耦合稍差，因为产生了不必要的依赖（如果Student结构改变，即使printStudentName逻辑不变，也可能需要重新编译或检查）。

4. 控制耦合
   关系：一个模块向另一个模块传递了控制信息（如标志、开关），目的是直接影响后者的内部逻辑流程。

比喻：A对B说：“这是数据，另外，如果遇到情况X，你就按方案1处理；否则按方案2。” A在控制B的决策。

代码示例：processData(data, isUrgent)，其中 isUrgent 是一个布尔标志，会改变 processData 的内部行为（如走快速通道还是普通通道）。

评价：较强的耦合，因为调用者需要了解被调用者的内部逻辑分支。应尽量避免。

5. 外部耦合
   关系：多个模块都依赖同一个外部环境或全局约定，如共享的通信协议、数据格式、硬件接口等。

比喻：A和B都使用同一种“行业黑话”或同一种特定工具进行交流。他们之间不直接依赖，但都依赖这套外部规则。

代码示例：多个模块都读写同一个特定格式的XML文件，或者都调用同一个操作系统提供的特定API。

评价：耦合度较高，但有时不可避免。关键在于将外部依赖集中管理。

6. 公共耦合
   关系：多个模块都全局性地访问和修改同一块公共数据区（如全局变量、共享数据库表、公共内存）。

比喻：A和B都在一块公共白板上读写信息。A写的东西可能被B无意擦掉或覆盖，反之亦然。他们的行为通过这块白板紧紧绑在一起。

代码示例：多个函数都直接读写一个全局变量 globalConfig。

代码影响：极难调试和理解，因为任何一个模块的行为都可能被远处另一个模块的修改所影响。

评价：糟糕的设计，应严格限制使用。

7. 内容耦合
   关系：一个模块直接修改或依赖另一个模块的内部内容（如直接跳转到另一个模块的内部标号、修改另一个模块的内部数据）。

比喻：A不仅给B下指令，还直接动手篡改B的笔记或大脑里的想法。

代码示例：模块A使用 goto 语句跳转到模块B内部的某个标签；或者通过指针黑客手段直接修改模块B的私有变量。

评价：最差、最致命的耦合，完全破坏了模块的封装性。现代编程语言（如Java, C#）的语法特性已基本杜绝了这种情况。

核心设计原则
在软件设计中，我们的目标是：追求低耦合（松耦合），尤其是数据耦合；警惕并减少控制耦合；尽可能避免公共耦合和内容耦合。 低耦合的系统就像用乐高积木搭成的建筑，一块坏了可以轻松替换，而不像用水泥浇灌的一整块墙体，牵一发而动全身。