A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm just this guy, ok? I've spent my years solving problems using my own brand of logic. People say I'm good at process and abstract analysis and that I can get business requirements out of people well. I've never taken a course or had training in design analysis, software design, and only a couple courses on C++ and VB.net (which I promptly forgot). Despite the obvious shortcomings, I get by really well and somehow compensate for lack of formality with something akin to skill and raw empathy.
I've recently been asked to be a Lead Analyst on a project and for some inexplicable reason they want documentation (which currently I do in my own non-standard way) and model diagrams and charts, graphs... I can do all this but I don't know what the formal process really is, and it's really time for me to learn... to be a <gulp> team player.
I've searched for books but they are all either strictly about use cases or abstract enough to not be useful about design. There's not a good book for translating my experience into something I can learn from... is there?
So... I'm soliciting "what worked for you" books/seminars/podcasts/psychic downloads from the future/anything that will help me be a better analyst and to model what I know into the diagrams people want.
Thanks. Yes, I know I'm in a world of pain.
Get some of the company's existing documents and use them as templates.
Wednesday, November 15, 2006
If you want diagrams to add to your documentation, there's always Visio. ;-)
I've used Poseidon UML in the past and it's been capable enough for multimillion$ projects. It's commercial, but there's a 'Community Edition' that's free to use.
Definitely find out what they currently use and stick with it. More than likely you are in a situation where they don't have any real process and are looking for you to create/formalize one. If this is the case then just go with Microsoft tools. Use Visio or create documents in Word.
As far as some sort of book teaching this kind of stuff, you will not find anything really helpful in the short term (one week). You can start learning UML and such but it may not rescue you on this particular project.
Either the company already has standards in place or they don't. If they have standards then follow them. If they don't, then don't get too upset about trying to make it perfect. At this point they won't know the difference anyway and are just wanting to start heading down the road to a more formalized process. Don't think that you have to get there in one giant step. Start with Word or Visio using a style that makes sense to you. If they balk at it, ask them to be clearer about what they want. I can't tell you how many times I've seen simply flowcharts or block diagrams used as designs and no one seems to really care that they don't follow any standard conventions. They get the job done and that is what is the most important.
Wednesday, November 15, 2006
Anon & Fiver... thanks for the feedback. The small steps approach is very wise. Could it be you tuned into my perfectionistic "all or nothing" mindset? Most of the (client) documentation work is in Excel and PowerPoint. The company I work for is very tuned into standards and is application agnostic. I'm all about standards, but can make Visio and Word do what I need to (except bullets and numbering, of course).
It seems the best approach is to work TOWARD a better process but in the mean time utilize whatever tools are familiar and acceptable to the client to capture and review business requirements and then talk to the programmers to see what THEY need to do their work well. Then, I can translate appropriately.
Frankly, sometimes it seems useless to do documentation because it seems no one ever reads it or it requires so much discussion/rationalization to describe it that there's no point. This tells me there's something wrong with the documentation--or the people who are 'trying' to comprehend it. But, at the same time, documentation is a life-saver when it comes down to you-said/we-said and in validating information on large projects.
In any case, it seems useful to learn UML, so that's one step I can take toward the ultimate requirements machine I am destined to become. :) Thanks.
One of the critical steps on the way towards a set of standards is simply defining what the various symbols mean, and establishing... well, the rules of the sandbox.
For example, some of your customers (or readers) will want to see things from a workflow or task based perspective; Role A does certain steps, then hands off to Role B. Other people want to see things from a data model perspective; The phone number collected in this field is used here, here and here.
If this is a large project, they may also want to see the cost of doing certain steps, or the time duration for those steps as in "if we do A, B, C and D instead of X, Y and Z, we'll save this much money/time."
The biggest mistake I typically see is when an analyst tries to cram all of these perspectives into one document or model. At that point, it becomes gibberish and worse than useless.
If you're just getting started, I would recommend focusing on accomplishing two tasks in parallel:
1) Determine who your audience is, and for each audience create a set of documents that only specify what they need to know. (Managers: workflow, Programmers: data model, etc.)
2) Figure out some way to synchronize these documents such that if you make a change in one, it's easy to update the others.
Thursday, November 16, 2006
Personally, I'm fond of Scott Ambler's "Agile Modeling". This explains the UML-based diagrams, as well as suggesting efficient use of a subset of the same.
I like using "UMLStudio" (www.pragsoft.com, $500 or so) to make the class diagrams and sequence diagrams -- partly because it can 'round-trip' engineer code from the diagrams. And it costs less than the $5,000 pricepoint set for many of these tools.
I also tend to make Data Flow Diagrams for my systems level analysis, using Visio. Export as 'windows meta file' .WMF files, and import into Word or Powerpoint.
It sounds like you don't want to implement any of the Big Design Up Front methodologies, so adapting what you currently do into a LITTLE more formalism using Ambler's suggestions should be practical.
Friday, November 17, 2006
I would suggest two books to help you out:
1. Code Complete:
2. Exporing Requirements: Quality Before Design
Both will help you get an idea of what good specs, docs and procedures to aim for.
Tuesday, November 21, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz