问题
I've just stumbled into the job of analysing a project for one of my company's clients (an SMB). I am a .Net developer (5 years) with little experience in analysing software (UML from school).
We've just finished two weeks of talking with the users and got a nice big list of requirements. Obviously we've filtered out the most important requirements and had to mark a bunch as 'out of scope'.
I have just started making some usecases, but feel I don't have the required expertise to bring this entire project to a good end. I'd like to know if someone has made the leap from developer to analyst and what goes with it. Also some good resources on analysing a project would be nice.
Thanks.
回答1:
Nobody else seems to be taking a whack at this so I will.
I have to first give you some unwelcome news - being a good analyst is like being a good developer - not everyone can do it. I've known lots of people that were great at writing complicated Windows application code that were useless at finding out what the user wanted, narrowing down those requirements, and coming up with a design. So don't feel bad if you find it hard going.
Which brings me to a second point - you can't separate analysis and design, particularly for modern OO systems, the two are part of a continuum. So you have to be prepared for that.
My third point is not to get too wedded to UML. It is a good tool for explaining your ideas to others (provided they know UML too) but a fairly rotten tool for doing the actual design. For example, use cases can just as easily be maintained in a text file as opposed to those stick-man drawings that UML uses. Instead of UML, I use simple block diagrams to show objects, components and relationships, normally sketched on paper and on a whiteboard.
My last point is that A&D is not a one-man activity. Get someone else involved that you can bounce ideas off. If you can get an experienced analyst/designer to help you for a day or so, so much the better.
Hope that was useful, and not too negative!
回答2:
To soften Neil's bad news, I'd say that the fact you're asking yourselves these questions at all is probably a good sign.
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.
回答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.
回答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.
来源：https://stackoverflow.com/questions/1293109/learning-how-to-analyse-a-project