代码之家  ›  专栏  ›  技术社区  ›  Peter

学习如何分析项目

  •  2
  • Peter  · 技术社区  · 16 年前

    我刚刚无意中为公司的一个客户(SMB)分析了一个项目。我是一名.Net开发人员(5年),在分析软件(来自学校的UML)方面几乎没有经验。

    我们刚刚完成了两周的与用户的交谈,得到了一个很好的需求清单。很明显,我们已经过滤掉了最重要的需求,并且必须将其中的一部分标记为“超出范围”。

    我刚刚开始做一些用例,但我觉得我没有必要的专业知识来让整个项目有一个好的结局。我想知道是否有人从开发人员跃升为分析师,以及随之而来的是什么。另外,在分析一个项目时提供一些好的资源也很好。

    谢谢

    4 回复  |  直到 16 年前
        1
  •  3
  •   anon anon    16 年前

    似乎没有其他人对这件事有意见,所以我会的。

    我必须首先告诉你一些不受欢迎的消息——做一个好的分析师就像做一个好的开发人员——不是每个人都能做到。我认识很多人,他们擅长编写复杂的Windows应用程序代码,而这些代码在发现用户需要什么、缩小需求范围以及提出设计方案方面毫无用处。所以,如果你觉得很难,不要难过。

    这就引出了第二点——你不能把分析和分析分开 设计,特别是对于现代OO系统,两者是连续统一体的一部分。所以你必须为此做好准备。

    我的第三点是不要太拘泥于UML。这是一个向其他人解释你的想法的好工具(前提是他们也知道UML),但在实际设计中却是一个相当糟糕的工具。例如,用例可以很容易地维护在一个文本文件中,而不是UML使用的那些粘人图。我用简单的方框图代替UML来显示对象、组件和关系,通常在纸上和白板上绘制。

    最后一点是A&D不是一个人的活动。找别人 参与其中,你可以从中获得灵感。如果你能找一位经验丰富的分析师/设计师帮你一天左右,那就更好了。

    希望这是有用的,不要太消极!

        2
  •  2
  •   Benjol    16 年前

    为了缓和尼尔的坏消息,我想说你问自己这些问题可能是个好迹象。

    如果你与你的客户(和你的管理层)有着良好的关系,也许值得考虑一些敏捷方法的变体。这可能有助于减轻试图看得太远的风险。

    记住 “只有当你满足客户的要求时,客户才会意识到他想要什么” :)

    分析时 当你分析客户的需求时,以及当你为新系统在他看来是什么样的想法时,尽量避免像开发人员那样思考。技术“考虑因素”(“这将更容易编码”,“我可以使用新技术X”)确实会妨碍设计有用的东西。

    不要惊慌。将工作分成可管理的部分。不是每个人都会同意这一点,但如果你发现自己有一块无法管理的区域,你就无法恢复理智, just start coding

        3
  •  1
  •   Benjol    16 年前

    你不应该用没有人能理解的微小细节使你的图表过载。至于我,我避免使用像Rational Rose和类似的极客丑陋的图表,我自己用图形工具绘制它们,否则你可以使用一些有趣的东西,比如 yUML.me (一个免费的在线UML工具),你的用户应该喜欢它。

    我甚至在YUMLSL之上为业务分析师开发了一种用户友好的语言,这样用户就可以直接用简单的英语表达,并将其翻译成类似UML的语言

      Blogger is a User
      Admin is a Blogger
      Author is a Blogger
      Subscriber is a User
    
      Admin Manage Site
      Manage Site Include Manage Users
      Manage Site Include Manage Themes
      Manage Site Include Manage Plugins
    

    源代码可在以下位置获得: http://reboltutorial.com/blog/easy-yuml-dialect-for-mere-mortals/

    关键是保持事情简单。许多人过度复杂的图表,这就是为什么UML有一些坏名声。

        4
  •  1
  •   Aviad Ezra    16 年前

    我发表了几篇文章,目的是让新设计师有一个良好的开端。所有帖子都可以在这里找到: http://aviadezra.blogspot.com/search/label/UML

    在大多数情况下,您从使用部署图对系统的物理体系结构进行建模开始,“系统物理体系结构建模”一文从简单使用部署图开始,在部署图中,我们仅显示节点及其相互关系,并通过包含在节点中运行的组件和应用程序来完成此图。

    在下一阶段中,我们使用组件图描述系统的逻辑架构,“系统逻辑架构建模”一文从显示逻辑组件的简单布线开始,并通过包括组件公开/需要的接口以及说明它们连接在一起的方式来完成该图。

    如果您正在设计并行应用程序,首先使用活动图显示并行工作流,然后使用序列图和类图完成该图,“建模并行应用程序”一文将引导您完成整个过程。

    进入详细设计阶段时,您使用类图以不同方式相互关联的对象(类)类型来描述问题域,“关联、聚合和组合”一文解释了类图中使用的关联连接器的3种变体。

    接下来,使用序列图显示不同对象如何相互作用;序列图的一个常见问题是如何显示条件和迭代,POST“交互片段”解释了如何使用交互片段操作符(ALT、OPT、PAR、循环和区域)。

    推荐文章