|
在整个产品生命周期中，充满了许许多多小规模的迭代，每一次都是从用例需求开始，从用例实现而结束，有三种用例：业务用例、概念用例、系统用例；业务用例用于识别和规定业务需求，概念用来分析需求，系统用例用来规定开发需求，三者是逐一精华的过程。 上次我们说了业务用例，今天来说一下系统用例和概念用例； 1、系统建模 系统建模其实是需求分析的过程，不断的精化、细化，侧重于分析问题、理解需求、定义系统和改进系统、管理需求变更等等活动，这些活动是贯穿整个项目的始终的。 主要解决： 1、 了解要解决的问题和问题的定义、范围：分析问题；将对遇到什么样的问题和谁是参与者达成一致，从业务的角度给出解决方案，对项目商业理由分析，预估能从项目中得到多少的回报； 2、 理解需求来源：需求来自各个方面，客户、合作伙伴、最终用户、领域专家，需要掌握如何准确判断需求来自于哪个方面，如何接近这些来源并且获取信息；比如：现阶段你是在开发内部使用的系统软件，那么就需要和团队专业的专家去沟通，(自己最近负责职评为什么总是改需求的原因之一)；如果你是在开发一个要在市场上出售的产品，那么就必须充分的调动营销人员、以便了解市场中用户的需求(比如华大：加油站系统为什么一直推广渠道有问题，原因之一就是按照壳牌的所有需求在设计国内的加油站系统，有没有需求都不知道，而仅仅从竞品中获取，是有限的，因为竞品的业务是从真实的场景而来，但是每个客户的需求又不一样)：在这里可以使用的技巧：访谈、问卷调查、头脑风暴、设计概念原型、竞品分析 3、 定义系统；解释需求来源、并整理称为要做什么样的东西的说明。包括：需求说明、团队成员、需求的优先级、预计工作量(不同角色，看待这一项是不一样的)，技术风险、设计原型、设计模型，最终用图形表达 4、 改进系统定义：转变成能让需求人明白、认可的方案、不仅仅是具备所有功能、应该合法、可靠、可用、可维护、可支持，那么这一阶段的系统说明文档很重要； 5、 需求管理(这里会有需求的属性)：需求是会变的，不论你怎么样的谨慎小心（我相信做了职评的同学都知道），而变更的需求难以管理，不仅仅是因为一个变更了的需求意味着要花费多少时间来实现而且一个需求的变动可能会影响到其他的需求，这时候一个有弹性的结构就显得很重要了；管理线包括：建立需求池、确定追踪重要的依赖关系、需求池中的每一个项越细分越好 6、 需求收集：一个软件，最终是人机的交互、那么只有人才会有交互，所以搞清楚需求来源很重要，可能你的用户对自己想要的东西一无所知，有可能是个专家，不要紧，你要做的是明白他需要什么样的东西来解决他的痛点，首先：你得知道你的需求来源有哪些，都是谁，可以通过访谈、问卷的方式来收集需求，将收集到的需求分类，不同的用户可能所需要的需求是不一样的，所以“听他们说，不一定按他们的做”； 2、 需求建模 那么为什么要对需求建模呢？作用是什么？目的是什么？
1、 与客户、用户、所需要的产品在内容方面达成一致并保持一致(避免重复改动，一次次的改，费劲吗？费劲) 2、 使得开发人员能够清晰的了解系统所需要的需求(防止因需求的变动而让业务总是来找你) 3、 规则的限定；有些是技术能实现的，有些是某些技术不能实现的，尤其是在这里 4、 估算开发系统所需要的时间和成本 5、 明白用户所需要的重点和目标 3、 设计建模 完成了需求收集、需求分析、我们来到了产品经理最基础要做的事情：产品设计、分析设计建模！ 现在的产品设计，不仅仅包括界面设计和数据库设计，还需要统一过程，而统一过程是一个工作量比较大的事儿，适合于大型项目，对于小项目来说都是一些功能的拼凑，但是大项目内在的互动和影响更为重要，所以小项目只需要设计界面设计和数据库设计可能就够了，但是大项目却不行。害，给你们举个例子：一栋楼坏了一块砖头、看上去可能没什么影响，但是当你家的厨房一块砖坏了，那你看着不别扭吗？ 但是统一过程需要从架构师、产品专家、技术总监等来一起讨论的结果，(可以参考大象UML建模 第六章第三节：设计建模工作流程P176)略过，啊哈哈哈哈哈哈，但是我知道他的目的 1、 将需求转化为未来系统的设计 2、 开发强壮的系统架构 3、 提高软件系统 4、 软件的生命周期和产品的生命周期 软件的生命周期、产品的声明周期；二者是有区别的 迭代周期、里程碑计划:二者也是有区别的 真正的迭代每一次都经历一次完整的软件生命周期，就是每一次迭代都会经历：需求、分析、设计、开发；每一次迭代都会有一个可运行的系统。 而里程碑是：在什么时间完成什么样的任务，比如在第三周完成需求分析、第四周完成设计等等… 4、 软件的瀑布式开发和敏捷开发 传统的瀑布式总是把问题遗留到最后才爆发：例如：一个为期两个月的项目，客户提出一项需求，分析人员认为没有太大的问题，在需求文档中接纳了他，半个月过去了，设计人员也认为没有太大的问题，在设计中接纳了它，一个月过去了，开发开始了工作，指导有一天开发人员发现业务逻辑有问题或者等等问题，这时候才去找客户或者需求提出者讨论改变设计需求或者改变做法，由于该需求实现晚于其他部分，而其他部分又依赖于该需求，于是整个进度不得不陷入停顿状态或者要求更有经验的开发人员接手、压缩测试时间；整个团队忙于应付和抱怨客户提出的需求总是改变，要么按原来的做，要么……. 由于我们要做的未知的事情，所以很多需求会变或者很多的需求客户本身是没有发现的，所以敏捷开发解决了这个问题；试想一下：当福特造汽车的时候只需要跑的够快就好了，为什么会有汽车的性能、舒适度、安全系数等等…..因为客户、用户的需求总是会变的，然而我们怎么能尽可能的避免这个问题？那就是尽快的给出一个可以让他们看得见的软件，当他们使用之后，认为有不合适的地方，我们还有时间去改正；这也就是在互联网产品中的：“多做不如少做”；当需求还在进行中时，我们应该发现客户认为最关键、最不稳定的哪一部分需求，做成MVP产品，让客户或者用户去验证。 中秋节马上要到了，在这里先祝看到文章的小伙伴月饼节快乐，阖家团圆。整个UML建模就到此结束了！ |
|
|
