Определение стратегии тестирования
Как отмечалось ранее, на этапе анализа привлекаются группы тестирования, например для получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения. Кроме того, на данном этапе определяется план работ по обеспечению надежности информационной системы и ее тестирования. Для любых проектов целесообразным является привлечение тестеров на ранних этапах разработки, в частности на этапе анализа и проектирования. Если проектное решение оказалось неудачным и это обнаружено слишком поздно - на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию, - то исправление ошибки проектирования может обойтись очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.
Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.
Проектирование
На этапе проектирования формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:
- схема базы данных (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (они строятся на базе моделей функций).
Если проект небольшой, то в качестве аналитиков, проектировщиков и разработчиков могут выступать одни и те же люди. Возникает вопрос: насколько вообще актуальна передача результатов самому себе? Думаем, что актуальна. Представьте себе, что вы передаете данные кому-либо, кто мало знает о системе. Зачастую это помогает, например, найти не описанные вообще, нечетко описанные, противоречиво описанные компоненты системы.
Все спецификации должны быть точными. План тестирования системы дорабатывается также на этом этапе разработки. Во многих проектах результаты этапа проектирования оформляются единым документом, который называют технической спецификацией. В нем также описывают принятый подход к решению каких-либо сложных технических вопросов.
Журнал проектирования
При проектировании возникает необходимость регистрировать все обсуждаемые варианты и окончательные решения. Не секрет, что проектировщики порой меняют первоначальные решения. Это может происходить потому, что со временем участники проекта забывают аргументы в пользу принятого решения. Подобную информацию можно хранить в репозитарии используемого CASE-средства, в текстовых файлах, просто на бумаге. Журнал проектирования является полезным материалом для новых членов групп проектировщиков, а также для разработчиков и тестировщиков.
Такой журнал может вестись как на этапе анализа, так и на этапе разработки и тестирования.
Планирование этапа проектирования
Тщательное планирование важно для любого проекта. Это входит в обязанности руководителя проекта и руководителя группы проектирования (консультации с аналитиками в этом случае будут обязательными). Это позволяет:
- Разбить глобальную задачу на небольшие, независимые задачи. Такими задачами легче управлять, такие задачи легче реализовывать.
- Определить контрольные даты (этапы сдачи), которые позволят определить, насколько успешно продвигается проект, какие направления отстают, какие недогружены, какие работают успешно. Это позволяет обнаружить отставание от сроков сдачи и вовремя предотвратить авралы.
- Определить зависимости между задачами, а также последовательность завершения задач.
- Прогнозировать загрузку персонала, наем временных работников, привлечение других групп разработчиков, привлечение консультантов (если это необходимо).
- Получить четкое представление о том, когда можно начать этап реализации.
- Получить четкое представление о том, когда можно начать этап опытной эксплуатации.
Ранние стадии
Рассмотрение результатов анализа
Это собственно процесс передачи информации от аналитиков проектировщикам. На практике это итерактивный процесс. У проектировщиков неизбежно будут возникать вопросы к аналитикам, и наоборот. Информация о системе будет постоянно уточняться. При разработке схемы базы данных может измениться информационная модель, полученная на этапе анализа, например потому, что имеющееся проектное решение нестабильно либо медленно работает при реализации его посредством выбранной СУБД или в силу иных причин. Проверить, охватывает ли анализ все бизнес-процессы системы (то есть осуществить проверку на полноту), проектировщики не в состоянии, но проверку информационной модели на непротиворечивость и корректность проектировщики провести могут. Это позволяет отследить ошибки в информационной модели и не повторить их в модели данных. Если результаты хранятся в репозитарии CASE-средства, то такая проверка на корректность может быть произведена автоматически.
Критические участки
Критические участки системы изучаются при первом обследовании системы и уточняются на этапе анализа. Термин «критические» может означать жизненно важные как для нормального функционирования информационной системы с точки зрения бизнеса (например, время простоя автоматизированной линии изготовления материала X не должно превышать одной минуты), так и для успешной реализации и приемки проекта. Критические с точки зрения бизнеса участки информационной системы хорошо подходят для макетирования. На основе этих макетов (работы макетирования выполняют проектировщики и группы тестирования) тестеры дают оценку качества как информационной модели, так и модели данных. Также макетирование позволяет показать, какие требования и какими средствами могут быть выполнены, а какие требования - не могут.
Часто на этапе проектирования выявляются критические участки, которые не были очевидными на этапе анализа. Это влечет за собой необходимость уточнения информационной модели. Часто это связано с особенностями реализации тех или иных возможностей в выбранной СУБД. Некоторые функции, которые на этапе анализа выглядят простыми, могут стать очень сложными, когда дело дойдет до физической реализации. Например:
- В выбранной СУБД отсутствует эффективный механизм сканирования деревьев, а при анализе выявлено большое количество справочников и выбраны интерфейсы представления в виде деревьев, кроме того это понравилось заказчику, а СУБД при большом справочнике работает слишком медленно.
- Другая распространенная неприятность - неполно реализованная ссылочная целостность. В СУБД не реализованы каскадные модификации, в информационной модели нормализованные отношения предполагают наличие каскадных удалений и обновлений. Реализация же таких механизмов посредством триггеров оказалась слишком медленной, и уровень каскадирования триггеров ниже, чем уровень каскадных операций, определенных в информационной модели.
Такие моменты могут инициировать не только изменение информационной модели, но и смену СУБД.
Между критическими участками проекта и его рисками существует тесная связь. Критический участок разработки (например, срыв сроков первого этапа сдачи проекта заказчику) может стоить целого проекта. Причинами срыва могут быть как ошибки проектирования, так и нехватка персонала.
Оценка ограничений
Ограничениями, известными с момента обследования бизнес-процессов, являются смета затрат и сроки внедрения. Могут быть и другие ограничения, например допуск персонала к той или иной информации (группы аналитиков к информации о бизнес-процессах в фирме, ограничения доступа к секретной информации и т.п.).
Решения относительно выбора аппаратной платформы, как правило, необратимы, поскольку тесно связаны со сметой затрат и наличием обслуживающего персонала. Например, решения на платформе RS/6000 и Intel с точки зрения сметы затрат выглядят одинаково, но персонала, способного квалифицированно обслуживать RS/6000, нет, и руководство не согласно оплатить обучение сотрудников, хотя решение на основе RS/6000 обладает более высокой масштабируемостью. Это может послужить причиной выбора платформы Intel. Аналогичные причины могут влиять и на выбор операционной системы.
Если проект является расширением или модернизацией существующей информационной системы, то число унаследованных ограничений также может быть большим. На этапе проектирования осуществляется обязательная проверка требований к информационной системе в свете выявленных ограничений. Менять платформу, операционную систему или СУБД на этапе реализации сложно, а на этапе опытной эксплуатации практически невозможно (на это просто не хватит времени, если не произойдет чудо). Чем большее количество компонентов системы уже реализовано, тем сложнее произвести подобную замену. Большинство СУБД сейчас работают на нескольких аппаратных платформах и нескольких операционных системах, но если есть участки кода проекта, зависимые от операционной системы или аппаратной платформы, то их изменение может обойтись очень дорого. В данной статье мы не будем обсуждать вопросы переносимости кода, поскольку они выходят за рамки этого цикла.
Если какие-либо требования не могут быть удовлетворены в принципе, принимается решение о доведении этого факта до сведения спонсоров проекта (руководства фирмы). Обнаружение неработоспособности системы в процессе эксплуатации ничем хорошим обернуться не может, особенно если до руководства фирмы дойдет информация о том, что невыполнимость требований была известна заранее.
Определение целевой архитектуры
Под выбором архитектуры мы понимаем и выбор платформы (платформ), и выбор операционной системы (операционных систем). В системе могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Если к автоматизации того или иного бизнеса до вас уже приложили руки, причем неоднократно, вы можете обнаружить настоящий «зверинец» платформ и операционных систем. Перенос ПО на ту или иную платформу - процесс не безболезненный, да и управление разнородной сетью может также стать делом проблемным. Если же обстоятельства таковы, что ПО на рабочих местах конечных пользователей должно работать под управлением нескольких операционных систем (ОС), то следует обязательно выделить зависимые от ОС участки кода и жестко описать интерфейсы обмена компонентов информационной системы, сделав их независимыми от ОС. При написании кода модулей, работающих под управлением нескольких ОС, следует ориентироваться на ту из них, которая обладает наиболее жесткими требованиями.
Кроме определения платформы следует выяснить следующее:
- Будет ли это архитектура «файл-сервер» или «клиент-сервер».
- Будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО.
- Будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться.
- Будет ли база данных однородной, то есть будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных небудет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта).
- Будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
Эти решения часто принимаются до начала этапа проектирования (на этапе анализа). На этапе проектирования полезно еще раз рассмотреть все причины выбора той или иной архитектуры, провести тесты производительности и надежности критических участков информационной системы. Это позволит избежать тяжело устраняемых ошибок проектирования. Довольно часто на этапе проектирования возникают непредвиденные технические проблемы, например аналитики не учитывают группу пользователей, имеющих доступ к информационной системе посредством текстовых терминалов. Это ошибка анализа, но выявляется она только на этапе проектирования. Такие проблемы должны решаться вместе с аналитиками, которые инициируют изменение информационной модели.
Если в среде используется сеть, то на этапе проектирования необходимо определить требуемые уровни сервиса сети и спроектировать ее топологию. Необходимо также провести тесты сети, чтобы увидеть, обеспечивает ли существующая сеть должную пропускную способность и имеется ли резерв пропускной способности сети. Если результат отрицательный, то следует четко описать необходимые изменения аппаратного обеспечения и топологии сети.
Выделение потенциальных узких мест в информационной системе
Если заказчик заявит, что производительность системы не имеет никакого значения, примите это замечание с юмором. Это означает лишь то, что время ответа системы на запрос не является (или не кажется заказчику в данный момент) критическим. Попробуйте спросить, приемлемо ли время ответа системы, равное одному часу или одному дню. Вряд ли ответ на этот вопрос будет положительным.
Производительность важна для любой информационной системы. Узким местом называют момент падения производительности системы. Конкретный ответ на вопрос, где узкие места данной системы, может дать лишь специальное направленное тестирование. Но это не означает, что оценка потенциальных узких мест невозможна. Одним из хороших методов является график нагрузки на систему в течение дня, недели, месяца и т.п. Можно построить диаграмму, на которой будет отражено время работы тех или иных бизнес-процессов, а также требуемое для данного бизнес-процесса время ответа системы. Такие диаграммы помогают выявить момент, когда нагрузка будет наиболее интенсивной. Количество пользователей, одновременно работающих с тем или иным компонентом, отражается на диаграмме посредством весового коэффициента (рис. 1).
В приведенном примере явно видны 3 пика активности системы, максимальный из которых приходится на 11 часов. Использован тип диаграммы с накоплением.
А в диаграмме, представленной на рис. 2 , видна активность касс в течение рабочего дня и повышение активности загрузки данных в нерабочее время. В такие диаграммы следует также добавлять вес, отражающий сложность бизнес-процесса, например в данном примере самый высокий весовой коэффициент будут иметь отчеты. Оценка весов определяется особенностями каждого конкретного бизнеса - где-то она может быть высокой, где-то низкой.
Ответ на вопрос, насколько потенциальные узкие места являются реальными, может дать только тестирование. Здесь оправданно применение специальных средств моделирования сценариев приложений. Следует отметить, что оценка точности детектирования узкого места в системе очень зависит от объема обрабатываемых данных. Следует уделить внимание генерации тестовых данных и проверке узких мест уже на этих данных. Часто информационная система не сразу выходит на проектную мощность, как правило, она работает некоторое время в режиме первоначального накопления информации, которое может продолжаться и несколько дней, и несколько месяцев. Как правило, предполагаемый порог объема обрабатываемых данных известен на этапе анализа, но реальный объем физических данных можно точно оценить только на этапе проектирования. Если сгенерировать предполагаемый объем тестовых данных нельзя (не хватает мощности техники или есть иные причины), то тесты проводят на меньшем объеме данных и пытаются построить оценки поведения системы на реальном объеме данных.
Более точно узкие места системы оцениваются на этапе разработки. Здесь уже есть реализованные компоненты системы. Средства автоматизации тестирования (например, LoadRunner, WinRunner и др.) позволяют отследить операции, которые выполняет то или иное приложение (но данные средства могут отследить далеко не все возможные типы приложений и то, насколько они подходят для тестирования вашего проекта, - это решение такого же порядка, что и выбор средства разработки приложения), автоматически сгенерировать сценарий запуска имитаторов работы реальных приложений и построить оценки узких мест системы.
Продукты третьих фирм
На этапе проектирования оценивают возможность и эффективность использования продуктов третьих форм в разработке данной информационной системы. Например, существует задача выполнения некоторого набора работ (определенных пакетных заданий и т.п.) по заданному графику. Далеко не всегда целесообразно включать в проект создание утилиты контроля запуска приложений, поскольку есть масса утилит, выполняющих эти операции, в том числе и свободно распространяемых. Существует и другая причина, по которой с ПО третьих фирм следует хотя бы ознакомиться. Не факт, что в мировой практике решения задач, подобных вашей, не встречаются. Если реализации третьих фирм известны, то следует с ними ознакомиться хотя бы для того, чтобы не повторять неудачные решения и взять на заметку удачные. Вероятно, какой-либо из существующих продуктов может быть интегрирован в создаваемую вами информационную систему. Для этого, возможно, потребуется создать интерфейс обмена данными между ПО третьей фирмы и вашим. Следует оценить целесообразность как разработки собственного компонента, так и интеграции уже готового аналогичного компонента.
Использование CASE-средств
CASE-средства предоставляют много преимуществ. На одной чаше весов будет автоматизация работы, предоставляемая CASE, а на другой - ненавистная задача преобразования результатов анализа в формат этого CASE (если для формализации результатов анализа использовался другой CASE-инструмент или не использовался никакой). Некоторые CASE-средства позволяют непосредственно перейти к проектированию, а к анализу можно вернуться путем обратного проектирования. К сожалению, при использовании обратного проектирования в CASE-средстве создается весьма вредная иллюзия того, что данные анализа регистрируются, хотя на самом деле этого практически никогда не происходит, поскольку информация, содержащаяся в спроектированной структуре, отличается от результатов анализа. Некоторые полезные данные получить можно, но построить полную картину вряд ли удастся.
Инфраструктура
Для проектирования и реализации необходимы аппаратные ресурсы и специальное программное обеспечение. Кроме того, требуется механизм, позволяющий контролировать создаваемую документацию и код. Эти вопросы лучше решать на ранних стадиях проектирования, а не на стадии разработки. Мы поговорим об этом ниже, в разделе «Проектирование процессов и кода». При групповой разработке вам понадобятся средства контроля согласованности кода. Если разработка идет под разными платформами (аппаратная платформа и ОС), то хорошим решением может оказаться PVCS. Для платформ Windows 98, NT, 2000 может оказаться приемлемым решение, предлагаемое Microsoft - MS Source Save. Кроме того, многие средства разработки также предоставляют возможности контроля исходного кода.
Построение модели данных
Работа проектировщиков базы данных в значительной степени зависит от качества информационной модели. Информационная модель не должна содержать никаких непонятных конструкций, которые нельзя реализовать в рамках выбранной СУБД. Следует отметить, что информационная модель создается для того, чтобы на ее основе можно было построить модель данных, то есть должна учитывать особенности реализации выбранной СУБД. Если те или иные особенности СУБД не позволяют отразить в модели данных то, что описывает информационная модель, значит, надо менять информационную модель, так как производитель СУБД вряд ли будет оперативно менять собственно СУБД ради вашего конкретного проекта (хотя и такие, правда единичные, случаи имели место).
Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных. После этого для разработчиков информационной системы создается пробная база данных. С ней начинают работать разработчики кода. В идеале к моменту начала разработки модель данных должна быть устойчива. Проектирование базы данных не может быть оторвано от проектирования модулей и приложений, поскольку бизнес-правила могут создавать объекты в базе данных, например серверные ограничения (constraints), а также хранимые процедуры и триггеры, - в этом случае часто говорят, что часть бизнес-логики переносится в базу данных. Проектирование модели данных для каждой СУБД содержит свои особенности, проектные решения, которые дают хороший результат для одной СУБД, но могут оказаться совершенно неприемлемыми для другой. Ниже перечислим задачи, которые являются общими для проектирования моделей данных:
- выявление нереализуемых или необычных конструкций в ER-модели и в определениях сущностей;
- разрешение всех дуг, подтипов и супертипов;
- изучение возможных, первичных, внешних ключей, описание ссылочной целостности (в зависимости от реализации декларативно или с использованием триггеров);
- проектирование и реализация денормализации базы данных в целях повышения производительности;
- определение части бизнес-логики, которую следует реализовать в базе данных (пакеты, хранимые процедуры);
- реализация ограничений (ограничений и триггеров), отражающих все централизованно определенные бизнес-правила, генерация ограничений и триггеров;
- определение набора бизнес-правил, которые не могут быть заданы как ограничения в базе данных;
- определение необходимых индексов, кластеров (если таковые реализованы в СУБД), определение горизонтальной фрагментации таблиц (если это реализовано в СУБД);
- оценка размеров всех таблиц, индексов, кластеров;
- определение размеров табличных пространств и особенностей их размещения на носителях информации, определение спецификации носителей информации для промышленной системы (например, тип raid-массивов, их количество, какие табличные пространства на них размещаются), определение размеров необходимых системных табличных пространств (например, системного каталога, журнала транзакций, временного табличного пространства и т.п.);
- определение пользователей базы данных, их уровней доступа, разработка и внедрение правил безопасности доступа, аудита (если это необходимо), создание пакетированных привилегий (в зависимости от реализации СУБД это роли или группы), синонимов;
- разработка топологии базы данных в случае распределенной базы данных, определение механизмов доступа к удаленным данным.
Подробнее на каждом из перечисленных пунктов мы остановимся в части «Схема базы данных».
Проектирование процессов и кода
Параллельно с проектированием схемы базы данных требуется выполнить проектирование процессов, чтобы получить спецификации всех модулей. Если часть бизнес-логики хранится в базе данных (ограничения, триггеры, хранимые процедуры), то оба эти процесса проектирования тесно связаны. Главная цель проектирования заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. Определения модулей раскрываются в технической спецификации программ. Возможно, что некоторые атомарные функции, полученные на этапе анализа, вообще не будут отображены в какие-либо модули, а будут преобразованы в ручные процедуры или принципы работы.
Отображение функций на модули
На этапе анализа уже разработан перечень функций, которые будут реализованы. На этапе проектирования этот перечень еще раз анализируется и корректируется. Однозначное соответствие между функцией и модулем вряд ли возможно. Дело в том, что на этапе анализа функции организованы по бизнес-категориям, а на этапе проектирования их придется реорганизовывать для упрощения разработки. Проектировщики могут принять решение объединить несколько функций, обладающих общими свойствами, или выделить какое-то общее свойство (или их набор) в отдельный модуль, а также разбить сложную функцию на несколько модулей. Подробнее эти вопросы рассматриваются в разделе «Спецификации функций».
Интерфейсы программ
При проектировании модулей определяют разметку меню, вид окон, горячие клавиши и связанные с ними вызовы. Существуют два вида перемещения по программам:
- с контекстом, когда целевая экранная форма частично или полностью заполняется автоматически данными, связанными с теми, что находятся в исходной экранной форме;
- без контекста, когда целевая экранная форма не заполняется вовсе или частично заполняется автоматически данными, не связанными с теми, что находятся в исходной экранной форме.
Часто автоматически заполняемые данные экранной формы группируют (располагают рядом), а перемещение по заполняемым пользователем полям организуют так, как это делал бы сам пользователь, работая с реальным бумажным документом. Такие интерфейсы воспринимаются пользователем легче, и он намного быстрее осваивает новое ПО.
Интегрирование и наследование механизмов обмена данными
Информационная система редко разрабатывается с нуля. Чаще проектировщики сталкиваются с задачами наследования данных из старых систем, которые уже выполняют какие-либо задачи автоматизации бизнеса. Такие системы могут на начальном этапе быть интегрированы в новую систему и постепенно заменяться новыми, более современными модулями. Этот подход может навязываться руководством фирмы для того, чтобы ускорить ввод новой информационной системы. Следует рассмотреть все плюсы и минусы такой постепенной интеграции (минусов, как правило, оказывается больше). Одну операцию придется делать в любом случае: переносить ценные данные, хранящиеся в старой информационной системе, в новую, то есть проектировать механизмы конвертации данных. Возможно, что придется делать конвертацию данных не только из старой системы в новую, но и обратно (полную или частичную), поскольку возможен вариант развития событий, при котором старая и новая информационные системы будут работать параллельно - хотя бы в период опытной эксплуатации новой системы.
Кроме вопросов наследования собственно данных из старых информационных систем, возможно, вам придется также решать задачи взаимодействия вашего ПО с продуктами третьих фирм. В этом случае вам следует изучить интерфейсы обмена данными ПО других разработчиков и обеспечить должный уровень поддержки этих интерфейсов в разрабатываемой информационной системе.
Определение спецификаций модулей
Это основная часть функционального проектирования. Здесь решаются следующие задачи:
- преобразование функциональных определений анализа в реализуемые модули;
- спецификации, которые выражают функциональные возможности каждого модуля в физических категориях;
- определение средств разработки для каждого модуля (или выделенных групп модулей), если используются несколько средств разработки в одном проекте;
- определение последовательности реализации модулей и зависимостей модулей.
Спецификации модулей различают по степени детализации и содержанию даже в рамках одного проекта. Определяют, сколько времени требуется для того, чтобы сгенерировать тот или иной модуль, сколько необходимо на тестирование того или иного модуля, а также на тестирование совокупности сгенерированных модулей. Кроме того, следует разработать специальные метрики - шаблоны, которые позволяют оценить, сколько времени потребуется на создание исходного кода модуля. Для ускорения процесса разработки следует рассмотреть возможность использования генераторов исходного кода - это целесообразно, если вам предстоит разработать большое количество несложных модулей, а время разработки ограничено. Следует использовать шаблоны кода для устранения рутинных операций. Подробнее эти вопросы рассматриваются в разделе, посвященном спецификациям функций, - вы найдете его в одной из следующих статей данного цикла.
КомпьютерПресс 11"2001
Разработка качественной информационной системы для нужд конкретного предприятия - сложный творческий процесс. Одним из аспектов является то, что непосредственно программисты не являются специалистами по технологии, организации и экономике данного предприятия или технологического процесса. Поэтому крайне важна качественная связь между специалистами-предметниками
и специалистами-программистами. Обеспечение этой связи - одна из задач руководителя подразделения, для которого создается ИС. Поэтому он должен ясно представлять основные этапы разработки информационной системы.
Проектирование любой информационной системы осуществляется в несколько стадий. В общем случае следует выделить следующие:
- предпроектное обследование;
- технико-экономическое обоснование;
я техническое проектирование;
я рабочее проектирование.
Две последние стадии могут для небольших проектов быть объединены одну - технорабочее проектирование.
Прежде чем начинать проектирование, необходимо выполнить обследование объекта, для которого создается ИС. Это достаточно важный этап, так как позволяет выделить характерные особенности объекта, которые следует учесть в характеристиках разрабатываемой ИС и которые определяют дальнейшую работу по проектированию. Любой процесс проектирования (и проектирования ИС в частности) является итерационным процессом, когда неоднократно приходится возвращаться на предыдущие этапы проектирования коррекции имеющихся результатов. От качества предпроектного обследования во многом зависит, придется ли в дальнейшем пересматривать основные концепции создаваемой ИС и вносить в нее принципиальные изменения, что всегда является трудоемкой задачей. На этапе предпроектного обследования следует сразу же настраиваться на то, что любое предприятие имеет свою специфику в производственных и бизнес-процессах. Поэтому знания о других предприятиях и о стандартных правилах организации этих процессов могут служить в большей части подспорьем в изучении предприятия, но отнюдь не являться целью внедрения. Обследование сводится к анализу существующей системы и объекта, для которого создается система. В частности, при этом следует уделять
особое внимание общению на предприятии с экспертами и специалистами в интересующей предметной области, а также анализу документов и их движения. Обследование (сбор материалов) выполняется по двум основным направлениям: обоснованию эффективности создаваемой системы и выбору технических средств.
Материалы для обоснования эффективности создаваемой системы включают в себя:
- структуру существующей системы;
- объемы выполняемой работы и трудозатраты;
- качество выполняемой работы;
- методы выполнения работы;
Данные для выбора технических средств включают в себя:
- структуру объекта;
- технологию передачи информации, системы оперативной и диспетчерской связи;
- сбор исходных данных;
- наличие вычислительной техники;
- систематизацию и оформление документов.
- общая характеристика объекта, для которого создается ИС;
- функции, выполняемые в системе: периодичность выполнения, трудозатраты на их выполнение и т. д.;
- характеристика используемой информации;
- существующие принципы действия системы;
- быстродействие системы;
- структурные схемы существующей системы (организационная, функциональная, алгоритмическая и др.);
- необходимые информационные потоки: виды документов, маршруты их движения и т. д.
Технико-экономическое обоснование создания ИС содержит следующие моменты:
- исходные положения, характеристики и технико-экономические данные об объекте;
- обоснование цели создания ИС;
- обоснование комплекса задач, решаемых в ИС, и ДР.
- общую характеристику объекта, для которого создается ИС;
- организацию управления в условиях использования ИС;
- используемый комплекс технических средств;
- описание и постановку решения задач, входящих в ИС;
- описание стандартного программного обеспечения;
- описание организации информационной базы и т. д.
Рабочий проект включает в себя документацию, необходимую для внедрения и функционирования системы:
- документацию по используемым и разработанным программам (кстати, документация по разработанным программам может послужить прообразом справочной системы - см. 12);
- инструкции по обработке данных (сбор, регистрация, обработка и передача информации);
- должностные инструкции персонала и т. д.
Технический и рабочий проекты включают в себя следующие собственные этапы, которые, как правило, выполняются в указанной ниже последовательности:
- выбор технических средств и стандартного программного обеспечения с учетом следующих особенностей;
- используемых в организации программных и аппаратных средств, а также других информационных систем;
- перспектив развития информационных технологий в организации (например, переход к работе с помощью Internet-технологий);
- структуры организации и требований к безопасности информации;
- уровня знаний и возможностей разработчиков;
- создание ИС и БД;
- создание программного обеспечения:
- создание средств ввода, корректировки и удаления информации;
- создание средств поиска информации;
- создание средств отображения информации, включая формирование отчетов;
- обеспечение контроля вводимой информации (выполняется параллельно с другими этапами создания программного обеспечения);
- создание средств администрирования БД;
- обеспечение работы программного обеспечения в сети;
- создание справочной системы (желательно выполнять параллельно с другими этапами технорабочего проектирования);
- локализация программного обеспечения;
- формирование рабочего варианта программного обеспечения (удаление отладочной информации, создание ярлыка программы и т. д.);
- разработка системы сбора информации;
- создание инструкций по работе с системой. Безусловно, на количество и объем приведенных здесь этапов влияет, пожалуй, один из самых важных критериев - стоимость разработки.
- Основные классификации информационных систем
В общем можно выделить следующие направления ИС:
- операционные системы,
- ¦ АСУ - автоматизированные системы управления,
- САПР - системы автоматизированного проектирования,
- ГИС - геоинформационные системы,
- Связь и телекоммуникация, "
- Справочно-поисковые системы,
- Системы информационной безопасности,
- Системы подготовки и обработки мультимедийной информации (звука, изображения, видео),
- редакционно-издательские системы.
Несмотря на достаточно узкую классификацию по основным направлениям, внутри каждого может быть множество разновидностей.
Одно из разделений - по роду деятельности (машиностроение, торговля, строительство). Например, АСУ могут подразделяться на:
- Системы автоматизации бухучета,
- Автоматизация управлением делопроизводства,
- Автоматизация управления торгами,
- Автоматизация управления банками,
- Автоматизация управления торговлей,
- Автоматизация таможенной деятельности,
- Автоматизация управления технологическими процессами,
- Автоматизация управлениями объектами недвижимости и т.д.
- САПР в строительстве,
- САПР в машиностроении,
- САПР в электронной промышленности,
- САПР в авиастроительстве и т.д.
- системы подготовки чертежной документации,
- системы расчета на прочность, жесткость и устойчивость,
- системы подготовки проектно-сметной документации,
- системы подготовки документации на конкурс и т.п.
ности. Наоборот, САПР ArchiCAD, speedikon, ArCON являются специализированными для строительства, и здесь пользователь оперирует не общими, а специализированными примитивами-объектами, как то: стены, окна или проемы, лестницами и т.д. С помощью этих систем можно быстрее и качественнее подготовить проектную документацию по объекту строительства, чем с помощью систем общего назначения. Однако подготовить проектную документацию для строительства корабля или самолета практически невозможно. Аналогично обстоит дело с САПР расчета на прочность. Например, системы ANSYS и NASTRAN - системы общего назначения, с их помощью можно рассчитать хоть здание, хоть самолет. А вот система ProFET amp; Stark ES ориентированна на расчет здания, с ее помощью можно быстрее и более «профильно» рассчитать здание. А вот при расчете самолета эти САПР лучше не использовать.
Заметим, что вокруг оболочки программ САПР общего назначения создаются десятки различных расширений возможностей. Многие компьютерные фирмы разрабатывают подсистемы к программам общего назначения, предоставляющие пользователю больший круг возможностей для использования общей системы в конкретной отрасли промышленности.
Вместе с тем на рынке программных продуктов существует множество различных ИС сходного назначения. Так, для автоматизации бухгалтерского учета сегодня предлагаются системы «1C», «Инфо-бухгалтер», «Парус», «Инотек НТ», «Gendalf», «Овионт информ», «Камин», «Плюс-мик- ро», «СБиС++» и многие другие. Успех той или иной системы на рынке зависит порой не только от качества программного продукта, но и от грамотно организованной маркетинговой и рекламной политики фирмы, от организации разветвленной сети дилеров и технического сопровождения. Аналогичное многообразие программных продуктов наблюдается и в других сферах деятельности человека.
Проектирование имеет целью обеспечить эффективное функционирование автоматизированной информационной системы (АИС) и взаимодействие автоматизированной информационной технологии (АИТ) со специалистами, использующими в сфере деятельности конкретного экономического объекта ПЭВМ и развитые средства коммуникации для выполнения своих профессиональных задач и принятия управленческих решений. В процессе проектирования совершенствуются как организация основной деятельности экономического объекта (производственной, хозяйственной), так и организация управленческих процедур. Массовое проектирование информационных технологий потребовало разработки единых теоретических положений, методических подходов к их созданию и функционированию.
Первоначально сформулированные академиком В.М. Глушковым научно-методические положения и практические рекомендации по проектированию автоматизированных систем в настоящее время сложились как основополагающие принципы создания АИС: системности, развития, совместимости, стандартизации и унификации, эффективности.
Принцип системности является важнейшим при создании, функционировании и развитии АИС. Он позволяет подойти к исследуемому объекту как единому целому; выявить на этой основе многообразные типы связей между структурными элементами, обеспечивающими целостность системы; установить направления производственно-хозяйственной деятельности системы и реализуемые ею конкретные функции. Системный подход предполагает проведение двухаспектного анализа, получившего название макро- и микроподходов.
При макроанализе система или ее элемент рассматриваются как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливается их число, выделяются и анализируются те связи, которые обусловлены целью изучения системы, а затем выбираются наиболее предпочтительные, реализующие заданную целевую функцию. При микроанализе изучается структура объекта, анализируются ее составляющие элементы с точки зрения их функциональных характеристик, проявляющихся через связи с другими элементами и внешней средой. В процессе проектирования АИС системный подход позволяет использовать математическое описание функционирования, исследование различных свойств отдельных элементов и системы в целом, моделировать изучаемые процессы для анализа работы вновь создаваемых систем.
Для АИС управления характерна многоуровневая иерархия с вертикально соподчиненными элементами (подсистемами). Преимущества иерархических структур способствовали их широкому распространению в системах управления. Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной для анализа форме не только отразить все существенное, интересующее создателя системы, но и использовать ЭВМ для исследования поведения системы в конкретных, заданных экспериментатором условиях. Поэтому в основе создания АИС в настоящее время лежит метод моделирования на базе системного подхода, позволяющий находить оптимальный вариант структуры системы и тем самым обеспечивать наибольшую эффективность ее функционирования.
Принцип развития заключается в том, что АИС создается с учетом возможности постоянного пополнения и обновления функций системы и видов ее обеспечений. Предусматривается, что автоматизированная система должна наращивать свои вычислительные мощности, оснащаться новыми техническими и программными средствами, быть способной постоянно расширять и обновлять круг задач и информационный фонд, создаваемый в виде системы баз данных. Принцип совместимости заключается в обеспечении способности взаимодействия АИС различных видов, уровней в процессе их совместного функционирования. Реализация принципа совместимости позволяет обеспечить нормальное функционирование экономических объектов, повысить эффективность управления народным хозяйством и его звеньями.
Принцип стандартизации и унификации заключается в необходимости применения типовых, унифицированных и стандартизированных элементов функционирования АИС. Внедрение в практику создания и развития АИС этого принципа позволяет сократить временные, трудовые и стоимостные затраты на создание АИС при максимально возможном использовании накопленного опыта в формировании проектных решений и внедрении автоматизации проектировочных работ.
Принцип эффективности заключается в достижении рационального соотношения между затратами на создание АИТ и целевым эффектом, получаемым при ее функционировании.
Как правило, кроме основополагающих принципов для эффективного осуществления управления выделяют также ряд частных принципов, детализирующих общие. Соблюдение каждого из частных принципов позволяет получить определенный экономический эффект. Один из них - принцип декомпозиции - используется при изучении особенностей, свойств элементов и системы в целом. Он основан на разделении системы на части, выделении отдельных комплексов работ, создает условия для более эффективного ее анализа и проектирования.
Принцип первого руководителя предполагает закрепление ответственности при создании системы за заказчиком - руководителем предприятия, организации, отрасли, т.е. будущим пользователем, который отвечает за ввод в действие и функционирование АИТ.
Принцип новых задач - поиск постоянного расширения возможностей системы, совершенствование процесса управления, получение дополнительных результатных показателей с целью оптимизировать управленческие решения. Это может сопровождаться постановкой и реализацией при использовании ЭВМ и других технических средств новых задач управления.
Принцип автоматизации информационных потоков и документооборота предусматривает комплексное использование технических средств на всех стадиях прохождения информации от момента ее регистрации до получения результатных показателей и формирования управленческих решений.
Принцип независимости данных предполагает, что модели данных должны быть проанализированы и спроектированы независимо от процессов их обработки, а также от их физической структуры и распределения в технической среде.
Принцип структурирования данных предусматривает необходимость структурирования и иерархической организации элементов информационной базы системы.
Принцип доступа конечного пользователя заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования). Соблюдение приведенных принципов необходимо при выполнении работ на всех стадиях создания и функционирования АИС и АИТ, т.е. в течение всего их жизненного цикла.
Жизненный цикл (ЖЦ) - период создания и использования АИС (АИТ), охватывающий ее различные состояния, начиная с момента возникновения необходимости в данной автоматизированной системе и заканчивая моментом ее полного выхода из употребления у пользователей.
Жизненный цикл АИС и АИТ позволяет выделить четыре основные стадии: предпроектную, проектную, внедрение и функционирование. От качества проектировочных работ зависит эффективность функционирования системы. Поэтому каждая стадия проектирования разделяется на ряд этапов и предусматривает составление документации, отражающей результаты работы.
Основными работами, выполняемыми на стадиях и этапах проектирования, можно считать:
I стадия - предпроектное обследование:
1-й этап - сбор материалов для проектирования -формирование требований, изучение объекта проектирования, разработка и выбор варианта концепции системы;
2-й этап - анализ материалов и формирование документации -создание и утверждение технико-экономического обоснования и технического задания на проектирование системы на основе анализа материалов обследования, собранных на первом этапе.
II стадия - проектирование:
1-й этап - техническое проектирование, где ведется поиск наиболее рациональных проектных решений по всем аспектам разработки, создаются и описываются все компоненты системы, а результаты работы отражаются в техническом проекте,
2-й этап - рабочее проектирование, в процессе которого осуществляется разработка и доводка программ, корректировка структур баз данных, создание документации на поставку, установку технических средств и инструкций по их эксплуатации, подготовка для каждого пользователя системы обширного инструкционного материла, оформленного в виде должностных инструкций исполнителям-специалистам, реализующим свои профессиональные функции с использованием технических средств управления. Технический и рабочий проекты могут объединяться в единый документ - техно-рабочий проект.
III стадия - ввод системы в действие:
1-й этап - подготовка к внедрению - установка и ввод в эксплуатацию технических средств, загрузка баз данных и опытная эксплуатация программ, обучение персонала;
2-й этап - проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;
3-й этап (завершающая стадия создания АИС и АИТ) - сдача в промышленную эксплуатацию; оформляется актами приема-сдачи работ.
VI стадия - промышленная эксплуатация кроме повседневного функционирования включает сопровождение программных средств и всего проекта, оперативное обслуживание и администрирование баз данных.
Жизненный цикл (ЖЦ) образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер; реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ формируется определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Этап завершается проверкой предложенных решений и документов на их соответствие сформулированным требованиям и начальным условиям.
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
Каскадная модель (70-85 г.г.);
Спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рисунок 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Рисунок 1 - Каскадная схема разработки ПО.
Положительные стороны применения каскадного подхода заключаются в следующем:
На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид.
Рисунок 2 - Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.
Для преодоления перечисленных проблем была предложена спиральная модель, делающая упор на начальные этапы ЖЦ: анализ и проектирование. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рисунок 3 - Спиральная модель ЖЦ
При проектировании автоматизированная информационная технология рассматривается в пяти взаимосвязанных аспектах.
1. Техническом - как аппаратно-коммуникационный комплекс, имеющий конкретную конфигурацию и служащий для обработки и передачи информации.
2. Программно-математическом - как набор статистических, математических, инфологических, алгоритмических и прочих машинно-ориентированных моделей, а также реализующих их компьютерных программ.
3. Методическом - как совокупность средств реализации функций управления по отношению к экономическому объекту - предприятию, объединению, региональному хозяйству и т. д.
4. Организационном - как описание документооборота и регламента деятельности аппарата управления.
5. Пооперационном - как совокупность технологических, логических и арифметических операций, реализуемых в автоматическом режиме.
Исходя из реальных условий конкретной предметной области формулируются основные требования к АИТ. Перечислим наиболее общие из них, характерные для современных информационных технологий.
Принцип системности. Такой принцип предполагает подразделение информационных потоков на внешние и внутренние по отношению к объекту управления, учет структурно-динамических свойств протекающих в нем процессов, моделирование прямых и обратных связей с окружающей средой.
Работа в многозадачном режиме. Использование децентрализованных средств сбора и предварительной обработки данных согласно принятой декомпозиции задач и распределения управленческих функций, что достигается с помощью технологии «клиент - сервер», позволяющей системе функционировать в многозадачном режиме.
Способность к адаптации всей системы и гибкое приспособление АИТ к изменениям рыночной среды, возможность быстрого переключения на разные режимы использования аппаратных и телекоммуникационных средств.
Ориентация АИТ на реализацию единой информационно-логической модели объекта управления в сочетании с необходимыми процедурами обработки данных и вывода результатов.
Синхронизация процессов переработки и выдачи информации с процессами принятия решений на всех уровнях за счет использования диалогового и планового (в масштабе реального времени) режимов эксплуатации АИТ.
Использование безбумажного документооборота, естественно-профессионального " языка для общения специалиста с ПЭВМ, электронных подписей, машинных архивов и библиотек, удаленного доступа к массивам данных.
Возможность обработки больших объемов информации в регламентном и произвольном режимах, а также интеграции данных в соответствии с иерархией управления.
Наличие экспертной поддержки, учет неполноты информации, возможность получения прогнозных данных.
Названные свойства АИТ обеспечиваются применением современных высокоразвитых аппаратно-программных комплексов, средств связи и формулируются в процессе проектирования разработчиками системы. Такие пользователи-разработчики относятся к классу профессионалов. Для них существует множество инструментальных средств, облегчающих создание АИТ. Например, можно назвать системы Oraclе, Visual C++, Gupta SQL, Windows, CA-Visual Objects, а также CASE-технологии, позволяющие конструировать сложные компьютерные системы из отдельных стандартизированных программных модулей.
Другой класс пользователей - специалисты проблемной области, которые применяют в своей деятельности программные средства с широкими технологическими возможностями, такие как MS Word, CorelDraw, MS Excel, MS Project, MS Access.
Автоматизированные системы проектирования - быстроразвивающийся путь ведения проектировочных работ. В области автоматизации проектирования АИС и АИТ за последнее десятилетие сформировалось новое направление - CASE (Computer-Aided Software/System Engineering). Дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-систем или CASE-технологий.
В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. CASE-технология представляет собой совокупность методов анализа, проектирования, разработки и сопровождения АИС, поддержанной комплексом взаимосвязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки АС, прочно вошедший в практику создания и сопровождения АИС и АИТ. Основная цель CASE-технологии состоит в том, чтобы отделить проектирование АИС и АИТ от ее кодирования и последующих этапов разработки, а также максимально автоматизировать процессы разработки и функционирования систем.
При использовании CASE-технологий изменяется технология ведения работ на всех этапах жизненного цикла автоматизированных систем и технологий, при этом наибольшие изменения касаются этапов анализа и проектирования. В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой АИС используются графы, диаграммы, таблицы и схемы.
Конец работы -
Эта тема принадлежит разделу:
Информационные технологии в юридической
Образовательное учреждение.. высшего профессионального образования.. государственный морской университет..
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:
Что будем делать с полученным материалом:
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
Этапы проектирования автоматизированных информационных систем. К проектированию АИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.
Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС(например, Price Waterhouse, Jet Info, Consistent Software и др.).
Второе направление в большей мере относится к области разработкиматематического и программного обеспечения для реализации функций АИС - моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п. В каждом классе АИС (АСУ, САПР, ГИС и т. д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.
Как, собственно, АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов.
Верхний уровень проектирования АИС часто называют концептуальным проектированием. Концептуальное проектирование выполняется в процессе пред проектных исследований, формулировки технического предложения, разработки эскизного проекта.
Пред проектные исследования проводятся путем анализа (обследования) деятельности предприятия (компании, учреждения, офиса), на котором создается или модернизируется АИС. Перед обследованием формируются и в процессе его проведения уточняются цели обследования - определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота. Содержание обследования - выявление структуры предприятия, выполняемых функций, информационных потоков, опыта и имеющихся средств автоматизации. Обследование проводится системными аналитиками (системными интеграторами) совместно с представителями организации-заказчика.
На основе анализа результатов обследования разрабатывается исходная концепция АИС. Эта концепция включает предложения по изменению структуры предприятия и взаимодействия подразделений, по выбору базовых программно-аппаратных средств, причем предложения должны учитывать прогноз развития предприятия. В отношении аппаратных средств и особенно программного обеспечения (ПО) такой выбор чаще всего есть выбор фирмы - поставщика необходимых средств (или, по крайней мере, базового ПО), так как правильная совместная работа программ разных фирм достигается с большим трудом.
Результаты анализа - техническое предложение и бизнес-план создания АИС -представляются заказчику для окончательного согласования.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций. Формализация нужна для однозначного понимания исполнителями и заказчиками требований, ограничений и принимаемых решений..
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АИС модели, как правило, претерпевают существенные изменения и в окончательном виде они рассматриваются уже как модели проектируемой АИС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационная модель отражает структуры данных - их состав и взаимосвязи. Поведенческая модель описывает информационные процессы (динамику функционирования), в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурная модель характеризует морфологию системы (ее построение) - состав подсистем, их взаимосвязи.
Содержанием последующих этапов нисходящего проектирования является определение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначального наполнения, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования.
Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АИС имеет сетевую структуру.
Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.
Одной из главных тенденций современной индустрии информатики является создание открытых систем. Свойство открытости означает, во-первых, переносимость (мобильность) программного обеспечения на различные аппаратные платформы, во-вторых, приспособленность системы к ее модификациям (модифицируемость или собственно открытость) и комплексированию с другими системами в целях расширения ее функциональных возможностей и/или придания системе новых качеств (интегрируемость).
I этап - предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);
II этап - проектный (составление технического и рабочего проектов);
III этап - внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);
IV этап - анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).
Рис.1.
На предпроектной стадии проводится изучение и анализ объекта проектирования. В частности анализируется информационная база, все входные документы, их объем, периодичность, алгоритмы, выходные документы и все информационные связи задач. Эти данные обрабатываются, и строится информационная модель объектов в виде таблиц и графиков.
К методам изучения и анализа состояния экономического объекта и его системы управления относятся:
устный и письменный опрос;
письменное анкетирование;
наблюдение, измерение, оценка;
групповое обсуждение;
анализ задач;
анализ производственных, управленческих и информационных процессов.
В результате обследования вырабатываются рекомендации по изменению организационной структуры, рассматриваются новые должностные инструкции, целесообразность тех или иных документов, определяется состав баз данных, предложения по изменению технологии обработки, определяется конфигурация вычислительной сети, количество машин, состав экономических задач, очередность их компьютеризации, вырабатываются предложения по реализации экономических задач средствами пакетов прикладных программ.
На проектном этапе составляются технические и рабочие проекты для каждого уровня АРМ. В рабочем проекте отражаются общие положения, состав технических средств, архитектура, организационная структура в новых условиях, делается постановка задач, проектируется информационное обеспечение, информационный обмен с другими АРМами, рассчитывается экономическая эффективность, инструкции исполнителям.
Проектирование технических процессов включает проектирование паролей, программ, сценариев диалога пользователя с ПВМ, включая проектирование иерархических организованных меню и "окон”. Меню содержит перечень блоков, модулей и программы. Каждый модуль выполняет определенную функцию. Разрабатывается структура меню и сцена диалога человека с машиной. Если привлекаются готовые пакеты прикладных программ, то в них обязательно должно быть руководство пользователю к эксплуатации и комплект машинных программ на дискетах.
Постановка задачи дает исчерпывающее представление о ее сущности, логике преобразования исходной информации для получения результата.
В процессе постановки задачи раскрываются:
организационно-экономическая сущность ее (наименование, цель решения, периодичность и сроки решения, источники и способы поступления данных, потребители результатной информации и способы ее отправки, информационные связи с другими задачами);
описание исходной переменной и условно-постоянной информации (перечень, формы представления, объемные показатели, описание структурных единиц информации, способов контроля исходных данных);
описание результатной информации (перечень, формы представления, пользователи, структурные единицы информации, способы контроля);
описание алгоритма решения задачи (последовательности выполнения арифметических и логических операций).
В настоящее время почти все АИС децентрализованные, поэтому важно участие пользователя на пред проектной стадии, при постановке и внедрении задач, анализе функционирования АИТ.