Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ИПАТОВА Э_Мет_ и_ тех_ сис_ проект.doc
Скачиваний:
161
Добавлен:
25.12.2018
Размер:
2.22 Mб
Скачать

3.3.3. Разработка системного проекта ис

Последним этапом начальной стадии проектирования ИС является создание системного проекта, определяющего методы и средства дальнейшего детального проектирования и поддержки ЖЦ ИС. Работы по разработке системного проекта ИС регламентированы следующими нормативными документами: ГОСТ-34.602, РД 50-34.698-90 пункты 2.11, 2, 3.1; ГОСТ Р ИСО/МЭК 12207-99 пункты 5.1.3, 5.2.3, 5.2.4, 5.3.3, 5.3.4, 5.3.5, 5.3.6, 7.1, 7.4, приложения A и B, ISO 9000-3 пункты 4, 5. Перечень и порядок работ может быть следующим:

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

  2. Предварительное определение архитектуры ИС, ее БД, потребностей в вычислительных ресурсах. Определение первичный требований к интерфейсам: пользователей, аппаратных и программных средств, а также их основных функциональных компонент. Разработка, визуализация и анализ реальной модели функционирования, диаграмм взаимодействия компонент ИС, потоков данных ИС.

  3. Выбор или разработка модели ЖЦ ИС.

  4. Предварительный выбор комплекта стандартов и обобщенного набора профилей для обеспечения ЖЦ ИС.

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

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

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

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

  9. Разработка технического задания и комплекта спецификаций требований на создание детального и рабочего проектов базовой версии ИС.

  10. Разработка системного проекта базовой версии для новой или модернизированной ИС.

  11. Приемка комиссией заказчика системного проекта и утверждение акта о завершении работ.

  12. Подготовка и заключение контракта на разработку детального и рабочего проекта базовой версии ИС.

Результатом каждой из этих работ является набор документов следующего содержания:

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

  • Титульный лист с утверждающими и согласующими подписями.

  • Полное наименование системного проекта ИС.

  • Назначение и цель разработки или модернизации ИС.

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

  • Организация – заказчик проекта.

  • Головной исполнитель и соисполнители проекта.

  • Общие сроки выполнения всего системного проекта.

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

  • Обобщенные результаты и выводы предпроектного обледования.

  • Обобщенные предложения по концепции разработки новой ИС.

  • Обобщенные характеристики объекта информатизации.

  • Общие требования к ИС (к функциям и основным задачам, БД, инфрастуктуре).

  • Предварительные требования к эксплуатационным характеристикам.

  • Специальные требования к аппаратным средствам и инструментарию, включая ОС, СУБД, разработку приложений.

  • Требования к структуре, оформлению и содержанию эксплуатационной и технологической документации.

  • Требования к составу и содержанию работ по внедрению ИС в эксплуатацию.

  • Этапы и график выполнения основных работ.

  • Ожидаемые результаты системного проекта и форма их представления.

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

  • Предложения по применению и развитию системного проекта.

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

  • Описание архитектуры ИС с выделением компонент ИС и связей между ними, с обоснованием выделения компонент из системы.

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

  • Требования к интерфейсам.

  • Реальную модель функционирования ИС с учетом ограничений конкретного проекта:

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

  • информационную модель;

  • событийную модель;

  • диаграммы потоков данных;

  • диаграммы взаимодействия компонентов ИС;

  • описание интерфейсов объектов ИС с окружающей средой и между собой.

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

  • Постановка задачи и предварительная адаптированная модель полного жизненного цикла базовой версии ИС.

  • Предварительный состав и основные положения комплекса стандартов и нормативных документов для подготовки профилей стандартов.

  • Предварительное содержание технологии, методов и состава инструментальных средств для проектирования и поддержки ИС.

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

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

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

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

  • План управления характеристиками качества ИС.

  • План управления обеспечением безопасности, защитой и другими критическими требованиями при создании ИС.

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

  • План управления рисками.

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

  • План организации обучения персонала разработчиков и пользователей.

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

  • наименование и содержание работы;

  • дату начала и окончания работы;

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

  • фамилию и должность ответственного исполнителя;

  • состав и форму представления результатов работы.

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

Системный проект должен содержать:

  • Исходные требования к функциям и характеристикам ИС.

  • Описание и графическое представление архитектуры ИС, ее БД и взаимодействия компонент:

  • полную реальную модель функционирования ИС, с визуализацией взаимодействия компонент, потоков данных;

  • комплект предварительных спецификаций на компоненты ИС;

  • детальное описание интерфейсов пользователей и взаимодействия внешней средой.

  • Модель жизненного цикла ИС:

  • предложения по типу модели ЖЦ ИС;

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

  • предложения по выбору базового комплекта и профилей стандартов для обеспечения ЖЦ ИС;

  • предложения по системе защиты и обеспечения безопасности функционирования ИС;

  • предложения по организационной структуре коллектива специалистов для реализации ЖЦ ИС.

  • Предварительные планы последующих этапов и работ ЖЦ ИС.

  • Проект технического задания на детальное проектирование и весь ЖЦ ИС.

  • Проект контракта на детальный проект и весь ЖЦ ИС.

Акт завершения работ и утверждение системного проекта должен содержать разделы:

  • Наименование завершенной работы.

  • Состав представителей организации разработчика (поставщика) и заказчика (покупателя), составивших и утвердивших акт.

  • Дата завершения работ.

  • Перечень исходных документов, на основании которых проводились работы.

  • Перечень документов, в которых представлены результаты выполненных работ.

  • Обобщенные результаты системного проектирования.

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

  • Предложения о возможности и целесообразности дальнейшего проектирования и всего ЖЦ ИС.

  • Рекомендации по закрытию контракта (договора) и полному расчету за выполненные работы.

Основные компоненты контракта (договора) на детальное проектирование и весь ЖЦ ИС должны содержать:

  • Название и цель проекта.

  • Ссылку на содержание основных положений ТЗ на проектирование и ЖЦ ИС.

  • Полное наименование и реквизиты Заказчика (пользователя, покупателя).

  • Полное наименование и реквизиты головного Исполнителя (разработчика, поставщика).

  • Общие сроки проектирования.

  • Условия, объемы и этапы финансирования проекта.

  • Отчетные этапы выполнения работ и условия их оплаты.

  • Ожидаемые результаты проекта.

  • Требования к документированию результатов проекта.

  • Условия контроля реализации и приемки проекта.

  • Условия возможной корректировки ТЗ и контракта.

  • Требования к мониторингу контракта проекта.

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

Решения относительно выбора аппаратной платформы, как правило, необратимы, поскольку тесно связаны со сметой затрат и наличием обслуживающего персонала. Например, решения на платформе RS/6000 и Intel с точки зрения сметы затрат выглядят одинаково, но персонала, способного квалифицированно обслуживать RS/6000, нет, и руководство не согласно оплатить обучение сотрудников, хотя решение на основе RS/6000 обладает более высокой масштабируемостью. Это может послужить причиной выбора платформы Intel. Аналогичные причины могут влиять и на выбор операционной системы. Менять платформу, операционную систему или СУБД на этапе реализации сложно, а на этапе опытной эксплуатации практически невозможно (на это просто не хватит времени, если не произойдет чудо). Чем большее количество компонентов системы уже реализовано, тем сложнее произвести подобную замену.

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

Кроме определения платформы следует выяснить следующее:

Будет ли это архитектура "файл-сервер" или "клиент-сервер".

Будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО.

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

Будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта).

Будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

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

На этом этапе системного проектирования большую роль играют процессы планирования дальнейших работ по проектированию ИС. Тщательное планирование важно для любого проекта. Это входит в обязанности руководителя проекта и руководителя группы проектирования (консультации с аналитиками в этом случае будут обязательными). Это позволяет:

  • Разбить глобальную задачу на небольшие, независимые задачи. Такими задачами легче управлять, такие задачи легче реализовывать.

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

  • Определить зависимости между задачами, а также последовательность завершения задач.

  • Прогнозировать загрузку персонала, наем временных работников, привлечение других групп разработчиков, привлечение консультантов (если это необходимо).

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

Заказчики всегда хотят, чтобы план выполнения работ оставался неизменным. На практике этого редко удается достичь в полном объеме. Определенным компромиссом здесь может стать неизменность установленных сроков сдачи компонентов системы.