Software Engineering - beginner system analist

Author

beginner system analist

R.A.M.

2006-12-18, 7:06 pm

Hello,
Could you recommend me please some document/course for system analysts.
Thank you!
/RAM/

Phlip

2006-12-19, 8:07 am

R.A.M. wrote:

> Could you recommend me please some document/course for system analysts.

Very few software engineers call themselves that anymore. Consider these
roles instead:

- business analyst - researches a market and collects requirements
- software engineer - uses science to implement requirements
- computer scientist - research science to create new technology

So which one did you mean?

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

R.A.M.

2006-12-19, 8:07 am

software engineer

I am a programmer that would like to lern participate in analysis/design
phases of project I will be envolved in.
Could you help me please?
Thanx

U¿ytkownik "Phlip" <phlipcpp@yahoo.com> napisa³ w wiadomo¶ci
news:FnJhh.1094$x67.500@newssvr17.news.prodigy.net...
> R.A.M. wrote:
>
>
> Very few software engineers call themselves that anymore. Consider these
> roles instead:
>
> - business analyst - researches a market and collects requirements
> - software engineer - uses science to implement requirements
> - computer scientist - research science to create new technology
>
> So which one did you mean?
>
> --
> Phlip
> [url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!
>

Gabriel Gonzalez

2006-12-19, 8:07 am

It depends on your background, do you hold a BSc in Softwware
Engineering?

On Dec 19, 5:41 am, "R.A.M." <r_ahims...@poczta.onet.pl> wrote:
> software engineer
>
> I am a programmer that would like to lern participate in analysis/design
> phases of project I will be envolved in.
> Could you help me please?
> Thanx
>
> U=BFytkownik "Phlip" <phlip...@yahoo.com> napisa=B3 w wiadomo=B6cinews:Fn=
Jhh.1094$x67.500@newssvr17.news.prodigy.net...[color=darkred]
>
>
>
>
>
>

Phlip

2006-12-19, 7:09 pm

> "R.A.M." wrote:[color=darkred]

A project should not have a "design phase". This is a myth of software
development. You should not only design, for a long time, without doing
anything else, because you have very few ways to determine if your
design is wrong.

You are asking how to improve your design skills. The leading edge of
this research is called "refactoring". Look that up.
[color=darkred]

H. S. Lahman

2006-12-19, 7:09 pm

Responding to R.A.M....

> software engineer
>
> I am a programmer that would like to lern participate in analysis/design
> phases of project I will be envolved in.

That isn't systems analysis in the classic sense (from when Systems
Analyst was a common job title in the '70s). A Systems Analyst provided
a step stone between the customer space and the computing space.
Basically the Systems Analyst was supposed to understand the customer
space well enough to create a proper SRS and express it in terms that
software developers could readily understand.

The problem was that those "terms" were typically high level design
notations like HIPO Charts, Flow Charts, and Data Flow Diagrams. That
made it difficult for the Systems Analyst to avoid overspecifying the
requirements so that they defined a specific software design. By the
late '80s that problem was resolved in several ways.

Requirements specification became more sophisticated and other
representations (e.g., use cases) evolved. The OO paradigm also
provided a step stone in the form of an OOA solution for functional
requirements that was expressed in purely in customer domain terms
(which later became an MDA Platform Independent Model). In addition,
software design was formalized in distinct stages and levels of
abstraction. As a result the Systems Analyst evolved into three
distinct job descriptions:

Requirements Analyst. Elicits, analyzes, and specifies problem
requirements. Any modeling (e.g., Domain Modeling) is done using
notations that are completely independent of the computing space.

Systems Engineer. Provides high level strategic view of the system,
particularly for the deployment. This typically includes partitioning
the system into large scale modules, allocating requirements to the
modules, and defining interface strategies between them. This is
usually done with classic functional decomposition (e.g., SYSML) down to
the subsystem level.

Systems Architect. Defines the computing space strategies, basic
internal solution structure, and technologies to be used. Often the
Systems Architect provides an overall vision across software products
and time that is similar to a Marketing Product Line Architecture. IOW,
the Systems Architect is a kind of Big Picture software designer.

Note that none of these job titles do classic software design in the
tradition of Structured Programming or OOA/D (though some, like Systems
Engineers, use specialized versions). I suspect that what you are
really after is this sort of design. To learn how to do that I would
suggest selecting a software A&D methodology, learning it, and putting
it into practice.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Adie

2007-02-02, 8:04 am

On Tue, 19 Dec 2006 05:41:19 +0100, R.A.M. wrote:

> software engineer
>
> I am a programmer that would like to lern participate in analysis/design
> phases of project I will be envolved in.
> Could you help me please?

Several ways of looking at what you want to do and there are a whole suite
of tools, skills and attitudes to develop to succeed. Here's what i think
are important.

1) Learn something about managing people and projects/software delivery
2) Go and grab yourself a few books on defining requirements and how to
document them - depends where you are but could be mock-ups, UML, written
specs, a ticket raised, a phone call, etc..
3) Learn what a "business" case is for a requirement, and how to establish
them and measure their efffectivness
4) Learn something about software architecture and patterns
5) Think creatively when problem solving but ALWAYS aim for simplicity
6) Become a good comunicator

Others may evangelise a different set of skills or methods, but the above
knowledge will get you to a position where you can evangelate your own
ideas... Which is what design is all about really ;-)

Andy Dingley

2007-02-05, 8:03 am

On 19 Dec 2006, 16:10, "Phlip" <phlip2...@gmail.com> wrote:

> A project should not have a "design phase".

I'd strongly agree with you here, and so would much of the Java world.
However the waterfall model still fits well with the offshore-
outsourced model of software development. There's a business analysis
phase performed too briefly with the customer, then a vast back-office
bucket shop (probably in Mumbai) churning out lines and lines of bad
code on a "never mind the quality, feel the width" basis. Talking to
outsourcers is all too often like taking a time machine back to the
'80s.

Sponsored Links