Главная Теоретический материал Лабораторные работы Задачи Тесты Контакты

Узбекское Агентство
Связи и Информатизации



Ташкентский Университет Информационных Технологий


Кафедра
«Программное обеспечение информационных технологий»

Направления:

5521900Информатика и
информационные технологии,
5523500Защита информации,
5523600Электронная коммерция,
5811200Сервис (информационный сервис),
5811300Сервис (электронные и
компьютерные технологии),
5320200Информатика и
библиотековедение,
5140900Профессиональное образование
(по направлению
информатика и
информационные технологии).


Преподаватель дисциплины



Доцент
Чернев Дмитрий Алексеевич

Глава 2. Системный анализ

Разработка программного обеспечения начинается с сис­темного анализа, после которого окончательно определяется стоимость и время исполнения проекта. Иначе этот процесс называют предварительным проектированием. Он может прод­литься от двух часов до нескольких недель, в зависимости от сложности поставленной задачи.

На этом этапе проводятся анализ существующих систем, исследования проекта на осуществимость и оценка достоинств будущего разрабатываемого продукта. Этот этап жизненного цикла представляет собой итеративный процесс, основной задачей которого является определение полного комплекса требований и целей к разрабатываемому программному продукту, опреде­ляющих критерии его удовлетворенности. Работа ведется в ос­новном в форме бесед с пользователями.

Анализ требований и пожеланий заказчика начинается с получения заказа на новую разработку (или на модификацию существующей) и заканчивается составлением документа, в деталях описывающего данную разработку.

На первом этапе проектирования программного обеспечения важно найти и понять, что же на самом деле хочет пользователь. Иной раз это не так просто сделать, поскольку пользователь не всегда представляет, что он действительно хочет получить. Ба­нальным примером могут служить пользователи, заказывающие, например, одновременно несколько больших задач типа «Учет заработной платы», «Ведение складского учета», «Составление табеля» и т.п., называя все это «Бухгалтерией».

Первые ошибки в программном изделии прокрадываются тогда, когда определяются требования и цели к нему. Причина большинства ошибок — неправильное понимание потребности пользователя. В дальнейшем возникают и другие ошибки, когда требования и цели транслируются во внешние спецификации (в документ).

Некачественное определение требований приводит к созданию программного продукта, который будет правильно решать неверно сформулированную задачу и, следовательно, он не будет соответствовать истинным потребностям заказчика. Поэтому при определении требований необходима максимально возможная аккуратность и точность, чтобы организация-разработчик прог­раммного изделия могла транслировать эти требования в проект с минимальным числом ошибок.

Требования программному изделию традиционно задаются на естественном языке и должны быть очень точно сформу­лированы. Они обычно являются сводом законов, на котором базируются все последующие решения по разработке прог­раммного изделия.

О методах проверки правильности требований можно сказать, что пользователь несет ответственность за проверку требований на полноту и точность, а разработчик - за проверку осущест­вимости и понятности.

Результатом системного анализа должно быть ясное пони­мание того, что требует пользователь, и что он хочет. Тонкое различие между этими двумя понятиями немаловажно. Обычно в процессе дискуссии пользователь свои требования «озвучивает» четко и ясно, однако много существенного «остается за кадром», и не, потому что пользователь намеренно молчит, а потому что он подсознательно считает некоторые требования естественными и потому не требующими специального выделения. Следует заме­тить что пользователи, предъявившие минимальные требования на стадии системного анализа и оставившие разработку проекта на рассмотрение производителя, впоследствии возмущаются, что конечный продукт не удовлетворяет их требованиям, работает некорректно и поэтому требуют его переделки.

Требования к средней или крупной системе должны разра­батываться небольшой группой.

Один участник группы должен быть основным представителем организации-пользователя, облеченным достаточными полномочиями, чтобы принимать решения. Он обязательно должен быть настоящим пользователем. Вторым членом группы должен быть человек, который действительно будет пользоваться программной системой. Например, при разработке требований к системе резервирования авиабилетов, им должен быть опытный кассир.

Организация-разработчик также должна быть представлена в этой группе.  Одним из ее представителей должен быть человек, который в конечном  счете будет играть главную роль в процессе внешнего проектирования, другой - в одном из процессов внутреннего проектирования.

Программные проекты можно разбить на три группы:

- управляемые пользователем;

- контролируемые пользователем;

-независимые от пользователя.

В случае управляемого пользователем проекта требования к ПИ программному изделию разрабатываются непосредственно организацией-пользователем. Разработчик программного обеспечения является ее субподрядчиком, а требования представляют собой контракт или его часть.

  В проекте, контролируемом пользователем, требования к ПИ формулируются либо его разработчиком, либо совместными усилиями разработчика и организацией-пользователя. В проектах такого типа организация-пользователь имеет право утверждать требования и, как правило, спецификации следующих уровней, в частности — внешние спецификации.

  В независимом от пользователя проекте вся ответственность за определение требований ложится на разработчика ПИ. Большинство проектов, связанных с разработкой общедоступных, поставляемых на рынок программ, относятся к этой группе. Однако и здесь по-прежнему крайне важно в какой-либо форме привлечь пользователя к работе над проектом.

И управляемые пользователем, и независимые от поль­зователя проекты должны планироваться таким образом, чтобы обеспечить участие обеих сторон.



Главная Теоретический материал Лабораторные работы Тесты Контакты