Being a systems analysts "/" programmer

[dRAMmer]

What does it really mean to be an SA/programmer? The programmer part is easy to understand but does being an SA (w/programmer) means also that you will be doing FD and ERD or you will be doing something else by that I mean a more technical taks? Does designing the UI also part of an SA's role?

[Hack]

All of these things and more.

They design stuff I have to program, so another important role for a Systems Analyst is to be the programmers whipping boy for when things go wrong.

[dRAMmer]

Hi Hack! Thanks for replying. I was also hoping that someone who is truly (in the sense that it is his job title) an SA will tell me what he does everyday, what tools is he using, what techniques or tips he has in his suitcase and anything else he wants to say.

[Hack]

Hi Hack! Thanks for replying. I was also hoping that someone who is truly (in the sense that it is his job title) an SA will tell me what he does everyday, what tools is he using, what techniques or tips he has in his suitcase and anything else he wants to say.

I'll pop an email back to one of the Systems Analyst that work for my company along with this link, and I'll post up whatever her comments are.

[szlamany]

I have been a system analyst since the mid-1980's.

Back when I worked for a company, I led a team of about 6 or so programmers and we created enterprise applications. We had a documentarian and a librarian on our team - so that we could freely do the research & development needed to produce an application.

Since the late-1980's I've owned my own software house.

Being a system analyst requires spending much more time "not programming" then you might imagine. Many hours in meetings and discussions with the users attempting to define the business side of the application.

Then the research part comes in. When we started our migration from mainframe to VB/MS SQL 5 years ago we easily spent the first 12 months just developing prototypes. Complete throw-away applications and entry forms - just to get a feel for best practice and conventions.

Best practices and conventions - probably the most important aspect of a good programming shop.

Many hours are still spent every week reviewing trade magazines and web-sites to keep ahead of the curve - which moves very quickly. We already are using VS 2005 and MS SQL 2005 in-house here - getting familiar with issues and features.

At this point after meeting with clients to discuss enhancements or new system functions, I give those assignments to my programmers - and then carefully review the progress and completion. It's imperative that a consistent product be developed - so review after coding is probably the second most important part of what I do.

I have done contract coding for large insurance companies where the "structure" of the relationship of SA and coder are even more defined. Very rigid definitions of what is to be changed - what is to be touched to accomplish the change. And a very rigid peer review at completion and then a test-cycle with a different group of people altogether.

[dRAMmer]

I'll pop an email back to one of the Systems Analyst that work for my company along with this link, and I'll post up whatever her comments are.

That'll be cool, thanks!

[dRAMmer]

Hi szlamany and techgnome!

Your input is very much appreciated, now I'm getting the feel of what an SA really does, not just a technical description of what an SA is. I always thought that somehow all of us programmers are in a way alraedy an SA. Since we create proposal also on things needed to be imroved where in we include changes in DB structure, UI layouts, and probably also the procedure flow (Bus.rule). And now I'm "officially" an SA, learning much about UML, if I could really use it and knowing how to create specs in an SA-way. That is having a very good format in excel or word probably. Then I was thinking I might be more of an architect because I've been developing interfaces and abstract classes (not yet very good at it, so don't ask and test my knowledge) using class diagrams and sometimes not really doing the actual coding. Then I also do database re-structuring, sproc/functions/query improvements. With these I sometimes get confused of what I should be called, i just do whatever the company throws at me.

It wold be nice if there are still others who want to share their experiences and what they do. Also will be very much appreciated if you guys (who replied already) can still post back. Thanks!

[techgnome]

Hi Hack! Thanks for replying. I was also hoping that someone who is truly (in the sense that it is his job title) an SA will tell me what he does everyday, what tools is he using, what techniques or tips he has in his suitcase and anything else he wants to say.

Well, my day starts off with some coffee and on Fridays includes a bagel. Then I login and check my email, bs with some co-workers.... then I check out the forums... spend some time answering posts like this... causing hate & discontent....

Actualy, what I do is about 75% development and 25% actual analyzing. Mostly when the analyzing part kicks in is when we get a new requirement from a client for our system. We have a business analyst that gets all of the initial requirements from the client and puts it into a statement of work template. This then gets passed to me. I do a quick design in my head, figure out how long it would take me to do, then I recalculate how long I think it would take one of our jr developers to do it. I then stuff that range back into the document and send it on to the next department. If I have any comments or questions, I attach them to the document. So far my tools have included Word, Excel and my arse (many times the numbers are WAGs).

When it comes back approved from the client (or gets refactored with more requirements) I build a design for it. How that gets done varies from case to case, but essentialy I just start building a list of all the stuff that needs to be done (database tables, stored procedured, new controls, data objects, etc.). Sometimes it all gets documented, sometimes not. Once the design is all layed out, and I have an idea of what needs to be done, I start making the changes.

-tg

[techgnome]

You can't find them because each shop creates their own, and what works for one, doesn't work for another. When I was in the military, we had a formal document template that worked for us very well... but here, that kind of document wouldn't go very far. Experiment, trial and error, and do what seems to work best for you. I bet if you just work with your existing method and expand it as you need, it'll evolve into the document you need.

-tg