Понятие проектирования ИС. Состав проекта ИС

Проблемы, связанные с особенностями проведения проектных работ.

Во-первых, создание АИС может осуществляться в трех вариантах.

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

2. Проектирование АИС осуществляют проектировщики-программисты, находящиеся в штате предприятия или организации.

3. Смешанный подход, когда разработкой АИС занимаются и штатные сотрудники, и приглашенные специалисты.

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

Во всех этих случаях в процессе разработки АИС проектировщики сталкиваются с целым рядом проблем.

· Проектировщику сложно получить исчерпывающую информацию для оценки формулируемых заказчиком требований к АИС.

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

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

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

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

Проектирование информационных систем охватывает три основные области:

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

· проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

Основу проекта любой ИС составляют следующие компоненты:

· методология проектирования;

· технологии проектирования;

· стандарты и методики проектирования;

· инструментальные средства проектирования (CASE-средства).

При этом взаимосвязь этих компонентов следующая: методология реализуется через конкретные технологии, каждая технология поддерживается соответствующими стандартами и методиками, а инструментальные средства обеспечивают выполнение процессов проектирования, описанных в методиках и стандартах.

Понятие методологии проектирования АЭИС.

В конце 60-х годов прошлого века в США было отмечено явление под названием "software crisis" (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, выглядели следующим образом:

· только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

· 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

· 31,1% проектов были аннулированы до завершения;

· для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

· нечеткая и неполная формулировка требований к ПО;

· недостаточное вовлечение пользователей в работу над проектом;

· отсутствие необходимых ресурсов;

· неудовлетворительное планирование и отсутствие грамотного управления проектом;

· частое изменение требований и спецификаций;

· новизна и несовершенство используемой технологии;

· недостаточная поддержка со стороны высшего руководства;

· недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.

Таким образом, назрела объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов. Это привело в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "программная инженерия" (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.

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

Это привело к пониманию того, что необходимо обратить внимание на методологические основы проектирования информационных систем.

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

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

Более всего методологии обеспечивают предсказуемость результатов, контроль и согласованность действий. Пользуясь тем или иным методом разработки приложений, члены коллектива разработчиков обеспечены общим пониманием направленности работы. Разработчики, объединенные проектом в одном городе или другой стране, могут непосредственно сообщить, в какой стадии находится их проект, ссылаясь на конкретные шаги, определенные в данной методологии. Поэтому методология включает:

1) тесно связанные, предписанные конкретные последовательности шагов;

2) перечень данных, подлежащих накоплению на каждой стадии;

3) критерии завершения работ в контрольных точках;

4) решения, принимаемые при выборе между альтернативными методами проектирования;

Дата добавления: 2014-01-07