Поняття «проблеми» в системному аналізі 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Поняття «проблеми» в системному аналізі



Системний аналіз з практичної точки зору являє собою універсальну методику вирішення складних проблем довільної природи. Ключовим поняттям в даному випадку є поняття «проблеми», яке можна визначити як «суб'єктивне негативне ставлення суб'єкта до реальності». Відповідно етап виявлення та діагностики проблеми в складних системах є найбільш важливими, тому що визначає цілі та завдання проведення системного аналізу, а також методи і алгоритми, які будуть застосовуватися в подальшому за підтримки прийняття рішень. В той же час цей етап є найбільш складним і найменш формалізованим.

Якщо спиратися на поняття «проблеми», то можна зробити висновок, що при раціональному підході проблема виникає тільки у системного аналітика, який має якусь формальну модель деякої системи, знаходить дану систему і виявляє невідповідність моделі і реальної системи, що і викликає його «негативне ставлення до реальності».

Очевидно, що існують системи, організація і поведінка яких суворо регламентована і визнана усіма суб'єктами - це, наприклад, юридичні закони. Невідповідність моделі (закону) і дійсності в даному випадку є проблемою (правопорушенням), яку потрібно вирішити. Однак для більшості штучних систем строгих регламентів не існує, а суб'єкти мають свої особисті цілі по відношенню до подібних систем, рідко збігаються з цілями інших суб'єктів. Більше того, конкретний суб'єкт має своє власне уявлення про те, частиною якої системи він є, з якими системами він взаємодіє.

 

UNIT 2

1.Read the text and find answers to the following questions:

a. Why is it so difficult for people to define what systems analysts are?

b. What are the main targets for a systems analyst?

c. How different are the functions of a system analyst and a programmer?

 

True Systems Analysis?

I recently came across some job postings under the title, "Systems Analyst," and it occurred to me people still do not know what it means. In the postings I saw things like:"seeking a Systems Analyst with 4 - 6 years experience in defining system requirements, systems design specifications and implementation of major applications systems. Candidate must have experience with JAVA and the ATG application framework.""Utilizes data modeling techniques to document business process and data flows.""Strong SQL skills are required."

Sadly, Systems Analysts are still perceived as nothing more than glorified programmers, a misconception that hasn't changed in many years. This means people still have trouble differentiating between systems and software, the two are certainly not synonymous, yet one is often used to implement the other. The fact we can implement systems without automated support (a manual system) should be indicative of the separation of the two, but since we commonly implement today's systems via computer, the distinction becomes indiscernible to a lot of people. Nonetheless, the misinterpretation of "Systems Analyst" is typical of the sloppy thinking permeating our society.

A true Systems Analyst studies the business, defines the information requirements needed to support the business, and designs and/or modifies a system to implement the requirements. The system design consists of separate work flows, complete with inputs and outputs, that are connected through a shared data base. This then becomes the specifications for programmers to design, develop and implement software. When the programming is complete, the Systems Analyst is responsible for testing and implementation of the system.

This means a Systems Analyst needs to know:

§ How the business works.

§ How to specify the information requirements of the business (to support the actions and/or decisions of the business).

§ How to design a system into sub-systems (work flows).

§ How to design inputs and outputs; e.g., screens and reports.

§ How to design the logical data base (not physical) or to write for people.

§ How to develop and execute a test plan.

§ How to prepare specifications for software.

 

If the Systems Analyst does his/her job properly, it eliminates the guesswork in programming thereby expediting the software development process. In other words, Systems Analysis is a precursor to programming. In the absence of a true Systems Analysis function, the programmer must try to deduce what is needed, a talent they are not necessarily suited.

Whereas a Systems Analyst is more of a generalist who is in tune with business and people, and tends to be somewhat extroverted in nature, the programmer is more in tune with technology and is very detail oriented as he/she must try to manage complexity. Because of this, the programmer tends to be more introverted. Whereas the Systems Analyst must look at the big picture, the programmer must focus on his/her piece of the puzzle. The two functions are totally different. To try to merge the two functions together does a disservice to both.

In my travels through the business world, I no longer see many companies trying to build major systems. Instead, I tend to see numerous programming assignments being developed with no overall system architecture. That is like trying to build a product without a set of blueprints. It's simply counterproductive.

When I hear people say, "We don't have time to do the upfront work (we don't have time to do it right)." I interpret this as, "We have plenty of time to hack away at the problem until we either wear out ourselves or the user (we have plenty of time to do things wrong)."

So how do we know when a company doesn't truly understand the Systems Analysis function? That's easy. When you see programming languages included in the job description.

2. Give appropriate translations to the following words from the text:

 

to occur to, design specification, implementation, applications system, applications framework, SQL, be indicative, indiscernible, permeate, requirement, blueprint, disservice, to merge, be in tune with, guesswork, precursor

 

3. Make a written translation of the text:



Поделиться:


Последнее изменение этой страницы: 2016-12-30; просмотров: 199; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.191.216.163 (0.005 с.)