软件工程实训项目案例--Android移动应用开发

实训过程

角色分工

1.项目经理：负责项目的组织实施，制定项目计划，并进行跟踪管理
2.开发人员：对项目经理及项目负责
3.需求分析员：负责系统的需求获取和分析，并协助设计人员进行系统设计
4.系统设计、架构设计：负责系统设计工作，并指导程序员进行系统的开发工作
5.程序员：一般模块的详细设计、编码测试，并交叉进行模块的白盒测试
6.数据库管理员：负责数据库的建立和数据库的维护工作
7.测试人员：进行项目各阶段的测试工作，包括模块测试、系统需求测试、集成测试、系统测试等工作（对用户需求负责）
8.配置管理员：负责项目的配置管理
9.质量保证人员：有独立的小组进行

需求分析及原型设计

1.需求分析阶段
（1）获取需求
+了解项目所有用户类型及潜在的类型，然后根据用户要求来确定系统的整体目标和系统的工作范围
+将需求分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型
+确认需求获取的结果是否真实地反映了用户的意图

（2）分析需求
+以图形表示的方式描述系统的整体结构，包括系统的边界与接口
+通过原型、页面流或其他方式向用户提供可视化的界面，用户可对需求做出自己的评价
+系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等
+以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容

（3）编写需求文档
+使用自然语言或形式化语言描述
+添加图形的表达方式和模型表征的方式
+需包括用户的所有需求（功能性和非功能性）

用于需求建模的方法有很多种，最常用的包括用例图、实体关系图和数据流图三种。用例图多用在面向对象的开发中，通过描述系统和活动者之间的交互来描述系统的行为，最主要优点在于它是用户导向的，用户可根据自己所对应的用例来不断细化自己的需求，此外，Use Case还可以很方便地得到系统功能的测试用例。

实体关系图（ERD）用于描述系统实体之间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。

DFD数据流图作为结构化系统分析与设计的主要方法，尤其适用于MIS系统的表述。DFD使用4种基本元素描述系统的行为：过程、实体、数据流及数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是无法判断活动的时序关系。

2.原型设计
对于Android项目而言，原型设计的重要性更为突出，界面（美观+易用性）是移动应用的灵魂。
原型设计，绝不仅仅是画几个界面，设计思路应遵循“用户导向+简易操作”原则
+要形成人们希望的产品使用方式，以及人们为什么想用这种产品等问题的见解
+尊重用户知识水平、文化背景和生活习惯
+通过界面设计，让用户明白功能操作，并将作品本身的信息更加顺畅得传递给使用者
+通过界面给用户一种情感传递，使用户在接触作品时产生情感共鸣
+展望未来，要看到产品可能的样子，它们并不必然就像当前这样

需求分析阶段的注意事项：

1.需求分析阶段关注的目标是“做什么”，而不是“怎么做”
2.识别隐含需求（有可能是实现显式需求的前提条件）
3.需求符合系统的整体目标
4.保证需求项之间的一致性，解决需求项之间可能存在的冲突

需求及原型评审

评审重点：
1.功能：软件的用途
2.外部接口：此软件如何与人员、系统硬件、其他硬件及其他软件进行交互
3.性能：不同软件功能都有什么样的速度、可用性、响应时间、恢复时间等
4.属性：在正确性、可维护性、安全性等方面都有哪些事需要考虑
5.是否指定了在需求规格说明书之外的任何需求
6.不应说明任何设计或实施细节
7.不应该对软件附加更多约束
8.需求规格说明书是否合理限制了有效设计的范围而不指定任何特定的设计
9.需求规格说明书是否显示以下特征：
（1）正确性
（2）明确性：每个需求是否都有一种且只有一种解释；是否已使用客户的语言；是否使用图来补充自然语言说明
（3）完全性：需求规格说明书是否包括所有的重要需求；是否已确定并指出所有可能情况的输入值的预期范围；响应是否已同时包括在有效输入值和无效输入值中
所有的图、表和图表是否都包括所有评测术语和评测单元的完整标注、引用和定义？是否已解决或处理所有的未确定因素
（4）一致性
需求规格书是否与前景文档、用例模型和补充规约一致？它是否与更高层的规约一致？它是否保持内部一致，其中说明的个别需求的任何部分都不冲突？
（5）排列需求的能力
每个需求是否都已通过标识符来标注，以表明该特定需求的重要性或稳定性？
是否已标识出正确确定优先级的其他重要属性？
（6）可核实性
在需求规格说明书中说明的所有需求是否可被合适？
是否存在一定数量可节省成本的流程可供人员或机器用来检查软件产品是否满足需求？
（7）可修改性
需求规格说明书的结构和样式是否允许在保留结构和样式不变的情况下方便地对需求进行全面统一的更改？
是否确定和最大限度地减少了冗余，并对其进行交叉引用
（8）可追踪性
每个需求是否都具有明确的标识符
每个需求的来源是否确定
是否通过显式引用早期的工作来维护向后可追踪性
需求规格说明书产生的工件是否具有相当大的向前可追踪性