analysis - 学习如何分析项目

Question

我刚刚偶然发现了为我公司的一位客户（SMB）分析项目的工作。我是一名 .Net 开发人员（5 年），在分析软件（来自学校的 UML）方面几乎没有经验。

我们刚刚与用户进行了两周的交谈，并得到了一份很好的需求清单。显然，我们已经过滤掉了最重要的需求，并且不得不将一堆标记为“超出范围”。

我刚刚开始制作一些用例，但我觉得我没有必要的专业知识来完成整个项目。我想知道是否有人从开发人员跃升为分析师，以及随之而来的变化。还有一些关于分析项目的好资源会很好。

谢谢。

Answer 1

似乎没有其他人在这方面受到打击，所以我会的。

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

这让我想到了第二点——你不能将分析和设计分开，特别是对于现代 OO 系统，两者是一个连续体的一部分。所以你必须为此做好准备。

我的第三点是不要过于拘泥于 UML。它是向其他人解释您的想法的好工具（前提是他们也知道 UML），但在进行实际设计时却是一个相当糟糕的工具。例如，与 UML 使用的那些火柴人绘图相反，可以在文本文件中轻松维护用例。我没有使用 UML，而是使用简单的框图来显示对象、组件和关系，通常是在纸上和白板上画出草图。

我的最后一点是，A&D 不是一个人的活动。让其他人参与进来，您可以从中反弹想法。如果你能得到一位经验丰富的分析师/设计师来帮助你一天左右的时间，那就更好了。

希望这是有用的，而不是太消极！

Answer 2

为了缓和尼尔的坏消息，我想说的是，你问自己这些问题的事实可能是一个好兆头。

It might be worth considering some variant of an Agile approach, if you've got a good relationship with your customer (and your management). It could help to mitigate some of the risks of trying to see too far into the future.

Bear in mind that "The customer only realises what he wants when you give him what he asked for" :)

When analysing Strain to avoid thinking like a developer when you're analysing the customer's requirements, and also when you're coming up with ideas for what the new system will look like to him. Technical 'considerations' ("this will be much easier to code", "I could use that new technology X") can really get in the way of designing something that is useful and useable.

When coding Don't panic. Divide the work up into manageable chunks. Not everyone will agree with this, but if you find yourself with an unmanageable chunk that you can't get your head round, just start coding - even if you get half way through and have to start over, you will progress more than if you just sit there waiting for something to happen.

Be careful not to lose sight of the 'goal' - check often that you aren't unconsciously rewriting the specs as you go.

Answer 3

UML is a COMMUNICATION tool, so you should use it to elicit requirements with your users.

You should not overload your diagrams with tiny details nobody will understand. As for me, I avoid using geek ugly diagrams like those from Rational Rose and alike, I draw them myself with graphics tools otherwise as for you you could use something fun like yUML.me (a free online UML Tool), your users should love it.

I have even developped a user friendly language for Business Analysts on top of yUML DSL so that users could express directly in plain english and have it translated to UML like

  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

source code is available here: http://reboltutorial.com/blog/easy-yuml-dialect-for-mere-mortals/

The key is to keep things simple. Many people overcomplicate Diagrams that's why UML has some bad reputation.

Answer 4

I published several posts with the intent of getting fresh designers off to a good start. All the post can be found here: http://aviadezra.blogspot.com/search/label/UML

In most cases you start from modeling the physical architecture of the system using deployment diagrams, the post 'Modeling the System Physical Architecture' starts by showing simple use of the deployment diagram in which we only present the nodes and their inter-relationships, and complete the picture by including the components and the applications that run in the nodes.

In the next stage we describe the logical architecture of the system using component diagrams, the post 'Modeling the System Logical Architecture' starts by showing simple wiring of logical components and complete the picture by including the interfaces exposed/required by the components and illustrating the way in which they are wired together.

In case you’re designing parallel application you start by showing the parallel workflows using activity diagrams, and complete the picture using sequence diagrams and class diagrams, the post 'Modeling Parallel Applications' will walk you through the entire process.

When entering to the detail design stage you use class diagrams to describe the problem domain in terms of types of object (classes) associated with each other in different ways, the post 'Association, Aggregation and Composition' explains the 3 variation of the association connector used in class diagrams.

Next you use sequence diagrams to show how the different objects interact with each other; a common issue with sequence diagrams is how to show conditions and iterations, the post 'Interaction Fragment' explains how interaction fragment operators (Alt, Opt, Par, Loop, and Region) can be used for that matter.