иииииииииииииииииииииииииииииииииииииииииииииииии

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

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

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

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

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

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

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

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

Технология проектирования ИС – совокупность методологии и средств проектирования ИС, а также методов и средств организации проектирования.

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

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

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

ИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИ

 

Стадии разработки информационных систем

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

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

Системотехника – направление в кибернетике, изучающее вопросы планирования, проектирования, конструирования и поведения сложных информационных систем, основу которых составляют универсальные средства преобразования информации – электронные вычислительные машины (ЭВМ).

Проектирование можно представить как цикл, каждая итерация которого отличается большей детализацией и меньшей общностью (рис. 7.2.)

Основными свойствами процесса проектирования являются дивергенция, трансформация, конвергенция.

Дивергенция – расширение границ проектной ситуации с целью обеспечения более обширного пространства поиска решения.

Трансформация – стадия создания принципов и концепций (исследование структуры проблемы).

Конвергенция охватывает традиционное проектирование (программирование, отладка, проработка деталей).

Учитывая сложность проектирования ИС следует заострить внимание на трудностях этого процесса:

• предположение о конечном результате проектирования приходится делать еще до того, как исследованы средства его достижения;

• часто случается, что в ходе исследования событий в обратном порядке (от конечного результата) обнаруживаются непредвиденные трудности или открываются новые, более благоприятные возможности;

Рис. 7.2. Процесс проектирования

• самая интересная и самая сложная часть разработки – это как раз поиск решения путем изменения формулировки задачи.

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

• большое число действий, подлежащих реализации (многофункциональность);

• значительный объем и сложность ограничений на взаимосвязи проектируемой системы с окружением и трудности их формального описания;

• распределенный и асинхронный режим обработки данных;

• многообразие используемых информационных объектов и их

свойств;

• нечеткость требований, их субъективный характер;

• неполнота требований, их расширение в процессе проектирования, необходимость учета развития системы.

Перечисленные особенности исходных данных обосновывают необходимость развития такого направления в проектировании информационных систем как функциональные спецификации (ФС).

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

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

• заказчика;

• исполнителя;

• проекта.

Характеристики заказчика, влияющие на оценку риска проекта:

• стабильность организационной структуры;

• удовлетворенность заказчика организационной структурой;

• уровень формализации процессов обработки данных в существующей технологии;

• существующий уровень автоматизации процессов сбора и обработки данных;

• уровень подготовки кадров в области автоматизированной технологии обработки данных.

Характеристики исполнителя, влияющие на оценку риска проекта:

• опыт разработки прикладного программного обеспечения (ПО);

• опыт работы с системным ПО;

• опыт работы с техническими средствами;

• предполагаемая смена технической и программной среды;

• наличие в группе специалистов в данной предметной области.

Общие показатели проекта, влияющие на оценку его риска:

• уровень охвата автоматизацией процессов обработки данных;

• наличие территориально разнесенных подразделений;

• объем обрабатываемых данных;

• наличие прототипов;

• требования к времени ответа;

• требования к достоверности данных;

• требования к надежности;

• требования к обслуживающему персоналу;

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

Проектирование информационных систем будем рассматривать в следующих трех аспектах:

• стадии разработки;

• модели представления;

• уровни детализации.

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

Модели представления определяют совокупность понятий (видов элементов и отношений между ними), привлекаемых для описания проектных решений в рамках конкретной предметной области на определенной стадии разработки, выбранной методики проектирования.

Уровни детализации определяют иерархическую декомпозицию компонентов проектируемой системы. Они могут регламентироваться в рамках определенной методики проектирования.

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

Предлагается ввести пять основных моделей представления для проектирования информационных систем:

• функциональная модель;

• модель данных;

• модель пользовательского интерфейса;

• структура программных модулей;

• логика.

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

• действие;

• данное;

• систему;

• объект;

• атрибут.

Функциональная модель ориентирована на описание систем, способных выполнять действия над данными.

Модель данных ориентирована на описание структуры информационных объектов, их функциональных взаимосвязей, необходимых для поддержания заданных действий.

Указанные две модели взаимно дополняют друг друга, разрабатываются совместно и не требуют привлечения понятий языков программирования высокого уровня.

Модель пользовательского интерфейса ориентирована на описание взаимодействий пользователей с проектируемой системой, состава форм представления и команд управления заданиями.

Структура программных модулей ориентирована на описание статической структуры программой системы и опирается на понятия языков программирования высокого уровня.

Логика ориентирована на описание потока управления (последовательности выполнения) операторов программной системы и действий пользователей.

Для представления структуры ИС может быть использована информационно-логическая модель, основу описания которой представляет граф, отражающий типизированные связи между типизированными компонентами. Каждый компонент представляется парой: <имя типаХимя компонента>

Каждая связь представляется совокупностью элементов:

<имя типа>

<имя исходного компонента>

<имя вида отношения>

<имя типа>

<имя связанного компонента>

Метаобъекты – это базовые компоненты для конструирования модели предметной области.

Виды элементов – это экземпляры конкретного метаобъекта. Модель представления конкретной предметной области есть описание совокупности видов элементов и их взаимосвязей. Элемент – это экземпляр вида элемента.

Конкретные проектные данные представляются в виде совокупности элементов и их разнообразных взаимосвязей.

Используется три вида цепочек связей:

<метаобъект><имя метаобъекта> – описание структуры метаобъектов;

<имя метаобъекта><имя вида элемента> – описание структуры видов элементов;

<имя вида элемента><имя элемента> – описание связей элементов.

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

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

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

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

Структура (лат. structura) – прочная, относительно устойчивая связь (отношение) и взаимодействие элементов, сторон, частей предмета, явления, процесса как целого.

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

вид_элемента – определяет устойчивый для конкретной предметной области набор свойств, объединяющий конкретные проектируемые компоненты в группы;

вид_отношения – определяет устойчивые для конкретной предметной области группы связей между проектируемыми компонентами;

отношение – определяется видами элементов, вступающими во взаимосвязь и видом отношения, задающим семантику связей.

Ядро позволяет описывать требуемые виды отношений, виды элементов и отношения.

На рис. 7.3 показана схема ядра моделей представления функциональных спецификаций ИС.

Синтаксис языка функциональных спецификаций представлен в виде синтаксических

диаграмм на рис. 7.4.

Рис. 7.3. Схема ядра моделей представления функциональных спецификаций ИС

 

 

Рис. 7.4. Синтаксис языка функциональных спецификаций ПО