时间：2010年12月25日 地点：N210
作为需求分析的一个阶段小结，IBM实训导师与全系10小组展开对于需求分析的评审，分析问题，解决问题。
3小时的评审，总体来说，ZJU_ASIMS组对于文档，开发计划，WBS划分较清晰，运用MS Project是亮点，Medusa组对于需求的粒度划分有心得，不太多去考虑页面原型的内容，排除因场外因素对于需求分析的干扰，IC组需求考虑的比较细致，对于用户的角色定义较清晰，但同时，同学提出，增量开发的提法对于瀑布开发是不适合的，国政TX很勇敢。
听到了10组的报告，想法如下：
- 粒度。需求分析并不是实际开发，所以不需要太多考虑设计方面的问题，即使已经有了页面原型，需求分析是将业主的现实要求转化成物理模型，同时需求分析书需要考虑到各项目干系人的利益需求，平衡各方对于系统的要求。所以粒度考虑需要把握一个度的问题，太过于细化的粒度，对于需求分析阶段是个累赘。
- 用例图。到底是include还是extend，需要切实考虑用例间的关系，例如发布新闻与发送邮件之间，并不需要include的关系，不需要对于每一次新新闻的发布，都需要对用户发送邮件，只是给部分订阅新闻的用户发送即可，所以用extend关系即可。
- 域模型。域模型分析与类图分析，是两个不同概念的分析方法，所以域模型分析时，不需要将属性，方法都考虑清楚，另外，不需要太多依赖的关系。
具体到我们组Newbie，问题主要存在以下方面：
- 考虑不够周到。例如对于订阅新闻的用例，并没有考虑的更深一步，考虑到发送邮件这一用例，但这是并不可少的，但也需要考虑发送邮件的方式与时间，这一点，需要再考虑。
- 角色定义。抽取角色，泛化角色，因为之前在考虑用户这一角色的时候，始终会对用户，普通用户和其他用户的的概念产生歧义，而将所有用户抽取成用户，再泛化出五种角色，这也会方便到开发人员在设计时不会产生异议。
- 用例规约。基本时间流总体写法都是正确的，但是考虑的不够仔细，异常事件流等写法过于抽象，有些敷衍了事的意思。这比会对今后的开发照成困难。
- 团队。这是最大的问题，组员没有百分百的投入项目，PM没有切实履行自己的职责，成员没有需要的项目实训经验，完全还处于一种课程实验的概念，项目会议效率不高，讨论主题不明确，另外队员似乎都不怎么谦虚，这也存在于整个系10组成员中。我觉得这会是我们项目最终成功与否最关键的因素。否则对于想进入IBM实习，都是白日梦。
评审只是一个阶段，是为了能更快捷的找到项目组的问题，希望组员最后能有所行动。
评论已关闭。