[docs] : add notice and work-flow

luzhixing12345 · luzhixing12345 · commit 7a5fad3d16ca · 2022-06-07T01:39:26.000+08:00
diff --git a/README.md b/README.md
@@ -34,6 +34,8 @@
 
 ## 平时作业
 
+- [公告作业](notice.md)
+
 ## 课程大作业
 
 要求是4人一小组,合作完成一个项目.按照软件工程的基本流程
diff --git a/model.md b/model.md
@@ -1,8 +1,5 @@
 # 软件模型
 
-
-
-
 ## 编码-修补生命周期模型
 
 ![SE3](https://raw.githubusercontent.com/learner-lu/picbed/master/SE3.png)
diff --git a/notice.md b/notice.md
@@ -0,0 +1,101 @@
+# 群公告作业
+
+每一部分对应一次个人作业/小组作业,按时间顺序
+
+## 团队组建思考题
+
+1.个人角色
+请阅读《软件工程：面向对象和传统的方法》第1.3节,了解软件生命周期各阶段的工作内容,并思考：我适合在软件开发中担任什么角色？承担什么工作？
+2.项目组长
+请思考以下问题,为团队组建做好准备：
+⑴ 在软件开发中,软件项目组长/经理完成哪些工作？需要具备什么素质？与哪些人打交道？（如有参考其它参考资料,请注明引文信息。）
+⑵ 我是否适合担任软件开发项目组长/项目经理？
+⑶ 为什么我(不)适合担任软件开发项目组长/项目经理？
+⑷ 我是否愿意在软件工程课程小组实践中锻炼、提升自己的计划、组织、管理和协调能力？
+
+> 这一项会决定是否会担任组长
+
+## 团队组建
+
+请大家在今明两天内完成团队组建。如果遇到组队问题,可以联系辛老师或者我。
+请各小组组长带领组员完成《小组章程》,《小组章程》包括（但不限于）以下内容：
+⑴ 小组成员名单及联系方式
+⑵ 小组组织方式（参看第4章）
+⑶ 小组工作方式
+⑷ 小组管理措施
+⑸ 其它与本小组课程实践相关的内容
+《小组章程》的命名规则：组长学号-组长姓名-小组章程
+
+## 小组实践项目——选题
+
+请各小组组长带领组员完成小组实践项目选题,并做好下周五（3月4日）课堂上报告选题的准备。
+每组报告时间不超过5分钟,内容包括：
+⑴ 选题的领域背景
+⑵ 该领域背景下待解决的问题
+⑶ 选题的用户要求
+⑷ 选题的可行性分析
+⑸ 其它与选题相关的内容
+
+## 需求陈述
+
+请各组在本周内完成小组选题的“需求陈述”（可参考群文件《需求陈述举例》）。
+要求包含以下内容：
+⑴ 用户描述
+每一类用户的特征,以及该类用户使用计算机系统的熟练程度分析。
+⑵ 用户需求
+每一类型的用户使用该系统的目的及基本业务流程。
+⑶ 约束条件
+该系统开发可能存在的各方面约束。
+⑷ 需求优先级
+本选题中需求的优先级。
+⑸ 其它相关内容
+
+## 小组实践——用例模型
+
+1.生产小组
+构建本组选题应用领域（与本系统开发相关）的术语表。
+构建系统用例模型（含用例描述）。
+2.QA小组
+构建用例模型评审表,此表应是可以应用于所有用例模型的评审的,对于生产小组的选题可以有“不适用”的选项。
+3.评审用例模型
+QA小组评审对应生产小组的用例模型。具体过程实施,可参照群文件《技术评审》。时间安排,请QA小组与对应的生产小组协商确定。
+
+## 小组实践——需求分析阶段
+
+1.文档提交
+请各组于4月7日22时前提交需求阶段的组内评分表（请参看群文件《小组编号-组长-YY阶段-组内评分表》）、生产小组提交修订后的分析模型、QA小组提交评审后的分析模型评审表至课程邮箱
+
+## 小组实践——开发计划
+
+1. 生产小组
+估算系统的规模、开发工作量,参照IEEE计划模板制定本组选题的软件系统开发计划,重点部分：
+⑴ 具体工作
+⑵ 人员职责分配
+⑶ 进度安排（以最后一次课为系统交付时间）
+⑷ 风险管理
+要求在计划文档中使用：任务网络图、甘特图、责任矩阵。
+2. QA小组
+制定针对生产小组的验收测试计划。
+3. 评审计划
+QA小组评审对应生产小组的开发计划。具体过程实施,可参照群文件《技术评审》。时间安排,请QA小组与对应的生产小组协商确定。
+
+## 小组实践——验收测试设计
+
+1. 生产小组
+复核本组系统需求的优先级,如有变动,须告知QA小组。
+2. QA小组
+制定针对生产小组系统最高优先级需求的验收测试计划,并设计测试用例。要求每位同学都要参与测试用例的设计。
+
+## 小组实践——设计
+
+1. 完成系统的设计
+包括：软件结构设计、详细设计。
+选用传统结构化方法还是面向对象方法,由小组自定。
+要求：核心功能对应的单元（模块/类）必须有详细设计,小组内每位同学至少完成一个单元的详细设计。
+
+## 小组实践——验收测试的实施
+
+1. 生产小组
+提交本组的可运行系统、需求规格说明、设计文档给QA小组。
+2. QA小组
+请各QA小组于生产小组验收报告前两天之前完成对生产小组系统最高优先级需求的验收测试,完成测试报告；并将测试情况反馈给生产小组,跟踪生产小组对缺陷的修改
diff --git a/work-flow.md b/work-flow.md
@@ -0,0 +1,80 @@
+# 软件工程相关基本概念和流程
+
+## 软件危机(至今还没有被解决)
+
+两个方面的问题
+
+- 如何开发软件以满足用户对软件日益增长的需求
+- 如何维护数量不断膨胀的已有软件
+
+如果说现在有比现有编码技术快10%的新的编码技术,是否采用?
+
+软件工程角度来说需要考虑很多因素
+
+- 要考虑培训费用
+- 考虑将新技术引入开发组织中的花费
+- 考虑引入后的维护问题
+- ...
+
+## 软件生命周期（Software Development LifeCycle）是指软件的产生直到成熟的全部过程
+
+可以分为以下五个阶段(六个   )
+
+1. 需求阶段
+   1. 抽取概念
+   2. 提取客户需求
+2. 分析阶段
+   1. 分析客户需求
+   2. 撰写规格说明文档
+3. 设计阶段
+   1. 结构设计
+   2. 详细设计
+4. 实现阶段
+   1. 编码
+   2. 单元测试
+   3. 集成
+   4. 验收测试
+5. 交付后维护
+   1. 纠错性维护
+   2. 完善性维护
+   3. 适应性维护
+6. 退役
+
+## 关于维护
+
+传统维护的定义比较模糊, 在软件产品安装之后一天发现并纠正一个错误 和 同样的错误是在软件安装之前一天发现并纠正哪个是维护,以及软件产品已经被安装后客户想要增加该软件产品的功能 和 客户想要在软件产品安装之前做相同的变化,是**维护**还是**开发**并不好界定
+
+新的定义是: **是“软件因存在问题或因有改进或适应性需求时,对代码及相应文档所进行修改”的过程**,无论何时,只要软件被修改,就是维护,无论修改是发生在软件产品安装之前还是安装之后
+
+## 传统范型中的计划活动
+
+- 在项目的开始,对需求和分析阶段进行初步计划
+- 当用户签署了规格说明后就可以制定出软件项目管理计划(SPMP)
+- 在后续项目实施过程中,管理者要监督SPMP的执行情况
+
+计划活动贯穿于软件生命周期的始终,不存在独立的计划阶段
+
+## 测试活动
+
+整个流程中没有测试阶段,因为在软件产品准备好交付给客户时才检查它,实在是太晚了,在每个阶段接近结束的时候测试（太晚了,在整个项目结束时测试（更加来不及了
+
+将测试活动贯穿于整个软件生命周期中,测试职责归属于每一个软件从业者,以及软件质量保证小组
+
+## 文档
+
+同样也没有文档阶段,软件产品开发完准备交付给客户时再写文档,那就太晚了,因为
+
+- 关键人员可能在文档完成前离开
+- 如果没有前一阶段的文档,就没办法实施下一阶段
+- 没有文档也没办法测试
+- 没有文档就无法实施维护
+
+文档活动应当伴随着构建软件产品的所有其他开发和维护活动进行,没有单独的文档阶段
+
+## 结构化方法和面向对象方法
+
+结构化方法要么面向操作（例如有穷状态自动机,数据流图）,要么面向数据（例如实体-联系图,Jackson方法）,
+
+面向对象范型将**属性和操作**看作是
+
+> 对象：是一个结合了属性和对该属性的操作的软件组件
