|
System Analysis
Hi,
I did a tech degree in science and now im almost finished with my bachelor in Management Information System. I figured the world needed a manager who understands progamming. ;)
Anyway, I did a lot of courses about system analysis and basically we've learned two ways of doing it. First, there's the structured approach, with your basic Data Flow Diagrams and Entity Relationship Diagrams. Then there's also UML, which is the not-so-new object oriented approach to system analysis. I was wondering how useful this is in the real world, and what are your thoughts on these methods. Also, if anyone knows of other approaches that are commonly used, feel free to bring that up and discuss it.
My Code Has Low "Carbs"
Friday, February 13, 2004
Maybe work as a programmer in the real
world? Otherwise you will not understand
them and you will be able to answer
your own question.
son of parnas
Friday, February 13, 2004
So you think that, without having done any software development, you're equipped to be a manager of software development?
I got news for you, buddy.
Maybe you could apply to be a manager of accounting or medicine or something?
Friday, February 13, 2004
I'm going to agree with the poser above. You may have the skills, but you probably don't have the credentials. Your UML and Entity diagrams are only as good as your Design decisions, and sometimose those take experience. UML is really just a way of expressing your design ideas. Its rare we actual model with a UML tool, but you'll find psuedo-uml all over our whiteboards.
vince
Friday, February 13, 2004
oops. that should be *poster*. ( freudian slip? :-D )
vince
Friday, February 13, 2004
I'd say you're on the fast track to upper management. You know dick about actual programming, but know the right buzzwords. Put in a few years in middle management, brown-nose a bit, get a bunch of H1-B slaves to implement your projects under unrealistic development schedules motivating them with the sword of Damocles (work 80 hours a week to get this done or back to India you go), and make sure to take credit for other people's work whenever possible and you'll be a shoe-in for VP. The Peter Principle virtually guarantees your success.
anon
Friday, February 13, 2004
anon, keep going...
*madly taking notes*
Li-fan Chen
Friday, February 13, 2004
Structured analysis works for me. Another commonly used approach is "implement a[ny] subset of the functionality, then add to it".
Christopher Wells
Friday, February 13, 2004
None of the above. They're all old enough to be taught in a Computer Science course -- meaning they're out of date in the real world.
Try a few courses on long-distance project management and as many law courses as you can cram in. There may be a niche for you here.
By the way, ignore the sore-heads before me. You're not the only one caught with your pants down when they pulled the ball away.
anon
Friday, February 13, 2004
As vince said, these modeling tools are nothing more than a means of communicating with others on a project. I have seen rare instances where documented models serve a purpose after the project is complete. Also, the effort to keep these models in sync can outweigh their benefits for small to medium scale projects.
To answer your original question, both should be considered a somewhat structured approach and really the approach is analyze, design, code, etc. This tends to be the normal way to do software development. The variance often comes in the design, which for the Agile folks seems to take the form of code and for more formal folks lives in expressing design ideas with colleague through modeling languages or simply whiteboard talk.
Most of the focus I have seen for constructing saved models is for the "many boxes with connecting lines" factor that managers like or allowing negotiating with a diverse group of people (organizationally or geographically).
Good luck!
m
Friday, February 13, 2004
Whoops - Is it any surprise I replaced "test" with "etc." ?
m
Friday, February 13, 2004
----"I figured the world needed a manager who understands progamming."-----
And now you've been given a quick foretaste of the kind of people you'll be managing are you sure you didn't just waste three years?
Stephen Jones
Friday, February 13, 2004
You ought to read "Agile Programming" by Beck, which provides a short description of XP (extreme programming). It's debateable how well it scales, and how well it applies to shrink-wrap as opposed to inhouse or custom software, but you need to know the concepts.
You must read "Code Complete" (2nd edition) by Steve McConnell. The galley proofs are still on the website http://www.stevemcconnell.com/books.htm
Particularly read Chapter 6 on NData. It makes it very clear that when you are designing top down you are to think of the problem domain (employees, orders, cigarettes, drugs, custodial sentences whatever) and not the technical implementation details.
The third book you should read is "The Mythical Man Month" by Fred Brooks. This you will need to bang on the desk of your manager, when he starts demanding impossible deadlines.
As somebody has pointed out above any form of analysis is just a tool. You've got to get the problem space right to start with. The same applies to data types in a database. Ferran Pascal once flayed a neophyte who wrote to him asking if his table set up was ok as far as the relational model went. "How the hell am I supposed to know?" he said. "You know what data you have and how it is to be dealt with. The Relational database model is simply a reflection of that reality."
Stephen Jones
Friday, February 13, 2004
To be totally honest with you -- AVOID THE FAD!
Get some real development experience using any type of derivatives of the SDLC (living documents, coding, serious independent testing).
Once you get that on your belt, you can dabble on the fads, and get the best ideas from each.
And yes, there will be people on here objecting to me calling their favorite methodology as fad, but that's the whole point behind fad -- white hot firey devotion that will burn out soon enough.
T.J.
Friday, February 13, 2004
In the off chance that you are experiencing metaphitis...
'Under your belt'
Friday, February 13, 2004
> And now you've been given a quick foretaste of the kind of people you'll be managing are you sure you didn't just waste three years?
No, he wouldn't be managing me, because I am actually a development manager, and I spent many years as a developer before I became a manager.
Friday, February 13, 2004
I'm a bit dispointed that some people just skipped the issue and started trashing me. You don't know jack about me or my credentials, so please try to stick to the issue.
I did work on a lot of personnal projects as well as a larger one on an internship. I also worked 6 months doing maintenance programming, which was the main reason I decided to go back to school.
I had the choice between going into CS or MIS and I chose MIS. What's being taught in CS is not the cutting-edge technology that is in demand right now. Five years from now, most of the technical stuff I would have learned would be outdated and practically useless. In my opinion, the most important thing being taught in CS is how to think like a programmer. Given that I already had that, I figured it would be more useful to learn about the business side of things.
Now you can trash the logic behind my choice all you want, but it's too late for me to go back. Only time will tell if I made the right decision. Lastly, let me just say that I really don't expect to start managing from day 1 out of school, I'm not a complete idiot as some would suggest. I know I'll have to work my way from the bottom and hopefully I will get there someday.
So back to the topic at hand, what do you think about system development methods? ;)
(btw thx to the people who actually provided valuable input)
My Code Has Low "Carbs"
Friday, February 13, 2004
I would regard what I'm about to write as valuable input...
Computer Science departments do not teach cutting edge technologies, but they teach tried and true methodologies. Things like advanced data structures, topics in Artificial intelligence, Operating Systems, Compilers, Networking stacks, etc. They teach you the foundations that all new and "cutting edge" technologies are built off of. Having a CS background gives one the ability to pick up whatever the latest methodolgy is at the drop of a hat. Java, C++, C, C#, VB, Perl, Scripting Languages, it's all the same. It's the foundation that allows you to move between all these languages with almost no effort. The only effort required is to become aware of the language's syntax, and some of the API.
On the other hand, learning how to configure Cisco routers, about the .Net framework, the Java Runtime Environment, etc. does make you more aware of the technologies that coorporate America and the world is using. Here's the downside with learning the trends vs. the foundation; your education will become outdated in 5 years. You said it yourself, only you got it backwards. The foundation will never be outdated; the modern trends will be.
There is a light at the end of the tunnel though. If you continually develop in the latest technologies, and if you make an active effort to keep ahead of the game, you can succeed. It does require more effort though. If you go strictly into management though, be warned. Soon you'll sound like some of my old outdated managers always talking about the latest technology, a PDP-11. Doesn't help when his managing decisons are based on technology that has been outddated for years. You don't want to be that guy.
I'm not trying to abuse you based on lack of experience, as I completely understand where you are coming from. I do question your decision that MIS teaching the latest technologies won't become ouddated in 5 years vs. CS teaching tried and true technologies that will probably not ever become outdated until there is a fundamental shift in computer design.
As far as UML goes, I personally feel it's a waste of time following the formal guidelines. Same goes for all formal methodologies. Having a methodology is good. Methodologies on Methodologies are bad. i.e. CMM terrible. Six Sigma, terrible. The list goes on and on. UML terrible for software developers. Using a UML like system though can be beneficial. Whatever you use, only use it to the extent that it benefits your developers and your software.
Best of luck to you.
Elephant
Friday, February 13, 2004
I knew it was "under the belt." But it was early in the morning, and I was thinking, "If under the belt points to... maybe it's more fitting to say on your belt -- as you do with your pagers and stuff."
One have to wonder...
T.J.
Friday, February 13, 2004
Since you already have the programming experience, what you need now is some design experience. That will serve you better than studying a formal methodology. To be honest, I've found domain experience to be a lot more valuable than any formal training.
Clay Dowling
Friday, February 13, 2004
Elephant's remarks are dead on. CS sometimes takes a rap as impractical, but it is to the programmer as biology and anatomy are to the doctor. It's our pre-med curriculum.
Six months of maintenance programming and some personal dabbling hardly qualifies as "having the programming experience". But as a dilettante, feel free to move right into software management. Superficial understanding hasn't stopped most managers from taking that route. (It's not as if going into management is moving UP the food chain. It's just the Dilbert Principle at work.)
(Oh, and Structured Design and DFDs are passe, ERDs are a very nice way to partially depict one small aspect an existing system, and UML has some well understood notations to show static class relationships and time/control patterns. If they help you work out your ideas, that's great. None are important unless you personally find them useful. But don't ever expect that somebody else MUST do them to build a good system.)
X
Wednesday, February 18, 2004
 Recent Topics
Fog Creek Home
| 
