ИГА. Понятие базы данных

• Название: Понятие базы данных
• Дата: 05.04.2022
• Размер: 0.77 Mb.
• Имя файла: ИГА.docx
• Тип: Документы; #445246
• страница: 28 из 37

Жизненный цикл программных средств.

4. Жизненный цикл (ЖЦ) ПИ. Процессы ЖЦ ПИ.

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту:

- основные процессы ЖЦ ПО : приобретение (заказ), поставка, разработка, эксплуатация, сопровождение.

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

- организационные процессы: управление, создание и сопровождение инфраструктуры, усовершенствование, обучение.

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5].
5. Модели ЖЦ ПО. Каскадная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Каскадная модель процесса

Анализ требований - сбор требований к продукту. Результатом анализа, как правило, является некоторый текст/документ(ТЗ).

Проектирование - описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов.

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

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

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

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

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

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

Тем не менее каскадный процесс является основой для большинства других разновидностей процесса. Процессы, в которых каскадная схема применяется многократно, называются итеративными. Сразу оговоримся, что в итеративных процессах не обязательно все шаги каскадной схемы должны выполняться на каждой итерации. Ниже мы рассмотрим две разновидности итеративных процессов - спиральные и инкрементальные процессы
6. Модели ЖЦ ПО. Спиральная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Спиральная модель процесса

В случае спирального процесса (автор Барри Боэм,1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

Версии продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

Т.о. углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, который доводится до реализации.

Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).

Т.о. уточняется план-график дальнейшей работы.

Минусы:

1. Требуется более искусное управление

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

3. Трудность в определении момента перехода на следующий этап.

4. Переход осуществляется в соответствии с планом даже если не все работы выполнены.

5. Слишком большое количество витков потребует увеличения затрат, больших затрат.

Типичный проект:

Скажем, типичный проект, трудоемкость которого оценивается в три человеко-месяца, а продолжительность - в четыре месяца, вероятнее всего, потребует две-три итерации. Затраты на проведение большего числа шагов могут просто перевесить выгоду от дополнительных итераций.
7. Модели ЖЦ ПО. Инкрементальная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Инкрементальная модель

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

Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации предоставляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимo иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т.д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

1 План управления программным проектом

2 Проектная документация программного обеспечения

3 Спецификация требований к программному обеспечению
8. Развитие инкрементального подхода. XP-процессы.

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

- модель быстрой разработки приложений RAD (Rapid Application Development). RAD-модель обеспечивает эстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет группе создать полностью функциональную систему за 60-90 дней.

Выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бзнесм-функциями.

- моделирование данных. Информационный поток отображается в набор объектов данных.

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

- генерация приложения. Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

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

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

Недостатки применения RAD:

1. Для больших проектов требуются значительные людские ресурсы для создания групп.

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

3. Не применима в условиях высоких технических рисков, т.е. при использовании новой технологии.

В современной программной инженерии выделяют два семейства процессов разработки:

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

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

Экстремальное программирование - это облегченный процесс (Кент Бек, 1999). Он ориентирован на группы малого и среднего размера, работающие в условиях неопределенных и быстро изменяющихся требований. В группу входит до 10 сотрудников, работающих в одном помещении.

На всем протяжении итерационного цикла требования постоянно меняются, причем цикл состоит из очень коротких итераций.

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

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

- непрерывная связь с заказчиком;

- простота (всегда выбирается минимальное решение)

- быстрая обратная связь (модульное и функциональное тестирование)

- смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

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

2. Частая смена версий новые версии каждые 2 недели.

3. Метафора -вся разработка проводится на основе простой общедоступной истории о том как работает система. Истории обеспечивают заказчики.

4. Простое проектирование

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование -весь код пишется двумя программистами, работающими на одном компьютере.. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция -интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя -нельзя работать сверхурочно.

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

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

К таким стандартам относятся следующие:

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Над данными стандартами работает ISO/IEС JTC1/SC7 - международный технический комитет стандартов под контролем ИСО (ISO - Международная организация по стандартизации) и МЭК (IEС - Международная электротехническая комиссия).

Стандарт проектирования устанавливает (ISO/IEC 2382-20: 1990, Information technology Vocabulary - Part 20 : Systems development. (Разработка систем).):

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации устанавливает (ИСО 6592:1985, Обработка информации. Руководящие указания по документированию автоматизированных прикладных систем.):

- комплектность, состав и структуру документации на каждой стадии проектирования;

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

- требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;

- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя устанавливает (ИСО 6385:1981, Эргономические принципы проектирования рабочих систем):

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

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

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя.

ГОСТ

В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ 102-77 Стадии разработки программ и программной документации и содержит следующие стадии и этапы:

1. Техническое задание (ТЗ).

2. Эскизный проект (ЭП).

3. Технический проект (ТП).

4. Рабочий проект (РП).

5. Внедрение.

В табл. 2.1 показаны стадии разработки и этапы, их составляющие.

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

  Таблица 2.1

Стадии разработки	Этапы работ
Техническое задание	1.      Обоснование необходимости разработки программ. 2.      Выполнение научно-исследовательских работ (НИР). 3.      Разработка и утверждение технического задания.
Эскизный проект	1.      Разработка эскизного проекта. 2.      Утверждение эскизного проекта.
Технический проект	1.      Разработка технического проекта. 2.      Утверждение технического проекта.
Рабочий проект	1.      Разработка программы. 2.      Разработка программной документации. 3.      Испытание программы.
Внедрение	1.      Подготовка и передача программы.

 

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

Техническое задание. На стадии Техническое задание выполняются следующие работы, входящие в состав соответствующих этапов.

1. Обоснование необходимости разработки программ:

— постановка задачи;

— сбор исходных материалов;

— выбор и обоснование критериев эффективности и качества;

— обоснование необходимости проведения НИР.

2.   Выполнение научно-исследовательских работ:

— определение структуры входных и выходных данных;

— предварительный выбор методов решения задач;

— обоснование целесообразности применения ранее разработанных программ;

— определение требований к техническим средствам;

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

3.   Разработка и утверждение технического задания:

— определение требований к программе;

— разработка технико-экономического обоснования разработки программы;

— определение стадий, этапов и сроков разработки программы и документации на нее;

— выбор языков программирования;

— определение необходимости проведения НИР на последующих стадиях;

— согласование и утверждение ТЗ.

Результатом выполнения данной стадии является техническое задание , оформленное в соответствии с ГОСТ 105-78 (изм. 1981.) Общие требования к программным документам и ГОСТ 106-78 Общие требования к программным документам, выполненным печатным способом на листах формата 11 и 12 (по ГОСТ 301-68).

Эскизный проект. Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице 2.2.

Таблица 2.2

Этапы работ	Содержание
Разработка ЭП	1.  Предварительная разработка структуры входных и выходных данных. 2.  Уточнение методов решения задач. 3.  Разработка общего описания алгоритма решения задачи. 4.  Разработка технико-экономического обоснования.
Утверждение ЭП	1.  Разработка пояснительной записки. 2.  Согласование и утверждение эскизного проекта.

 

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

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

Результаты эскизного проекта отображаются в документе Пояснительная записка к эскизному проекту, оформленному в соответствии с ГОСТ 105-78 и ГОСТ 404-79.

После утверждения пояснительной записки она становится программным документам, правила дублирования, учета, хранения которого определяется ГОСТ 601-78 Общие правила дублирования, обращения, учета и хранения и ГОСТ 602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом. Последующие стадии и этапы разработки ПО могут выявить необходимость внесения изменений в ЭП. Эти изменения должны быть отражены в пояснительной записке в соответствии с ГОСТ 603-78 Общие правила внесения изменений в программные документы и ГОСТ 602-78 Правила внесения изменений в программные документы, выполненные печатным способом.

В качестве примера, ниже приводится фрагмент расширенного описания работ стадии эскизного проекта.

1. Разработка эскизного проекта ПО.

— разработка плана совместных работ на разработку ПО;

— разработка и обоснование математической модели системы на ЭВМ и описание результатов моделирования;

— разработка и обоснование алгоритмов и временных графиков функционирования ПО по всем режимам работы;

— разработка и обоснование ресурсов памяти для реализации алгоритмов;

— разработка перечня документов на ПО;

— разработка и обоснование структуры БД, внешних входных и выходных данных;

— разработка и обоснование алгоритмов информационного обеспечения;

— определение взаимосвязей между видами программ;

— разработка и обоснование набора тестов для проверки ПО;

— разработка и обоснование организации наращивания и развития ПО;

— оформление пояснительной записки и ведомости эскизного проекта ПО (в соответствии с ГОСТ 105-78, ГОСТ 404-79 и ГОСТ 106-68 ЕСКД. Текстовые документы);

— согласование и утверждение ЭП.

Технический проект. Основные этапы и содержание работ на стадии Технический проект приведены в таблице 2.3.

Содержанием работ на этой стадии является проектирование структуры ПО. Результатом — реализующий заданный и утвержденный в техническом задании комплекс программ как иерархическая структура программных модулей, заданных своими функциональными спецификациями. Форма представления результата — Пояснительная записка к техническому проекту согласно ГОСТ 105-78, ГОСТ 404-79.

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

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

Таблица 2.3

Этапы работ	Содержание
Разработка ТП	1.  Уточнение структуры входных и выходных данных. 2.  Разработка алгоритмов решения задач. 3.  Определение формы представления входных и выходных данных. 4.  Определение синтаксиса и семантики языка. 5.  Разработка структуры программы. 6.  Окончательное определение конфигурации технических средств.
Утверждение ТП	1.  Разработка плана мероприятий по разработке и внедрению программ. 2.  Разработка пояснительной записки. 3.  Согласование и утверждение ТП.

 

Фрагмент описания работ стадии технического проекта приведен ниже.

1. Разработка технического проекта ПО.

— разработка плана совместных работ на разработку ПО;

— распараллеливание задач применительно к возможностям ЭВМ и систем обмена информации и разработка организационной структуры программ;

— формализация программно-аппаратных и внутризадачных интерфейсов;

— разработка алгоритмов управления вычислительным процессом и процессами обмена, его исследование и оптимизация;

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

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

— уточнение структуры и определение формы представления БД, внешних входных и выходных данных;

— разработка проекта описания программы для каждого вида программ ПО;

— уточнение алгоритмов ПО и алгоритмов информационного обеспечения в процессе решения задач;

— разработка проекта описания текстовых программ ПО;

— разработка плана реализации ПО;

— разработка проектов технических условий на ПО;

— разработка и обоснование решений по надежности функционирования ПО;

— разработка программы и правил испытаний ПО;

— уточнение временных графиков функционирования программ ПО в процессе решения задач;

— оформление пояснительной записки и ведомости технического проекта ПО (в соответствии с ГОСТ 105-78, ГОСТ 404-79 и ГОСТ 106-68 ЕСКД. Текстовые документы);

— согласование и утверждение ТП.

Рабочий проект. Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице 2.4.

Таблица 2.4

Этапы работ	Содержание
Разработка ПО	1.Программирование и отладка программ.
Разработка программной документации	1. Разработка программных документов в соответствии с требованиями ГОСТ 101-77.
Испытание ПО	1.Разработка, согласование и утверждение программ и методики испытаний 2.Проведение предварительных государственных, межведомственных приемо-сдаточных и других видов испытаний. 3. Корректировка ПО и программной документации по результатам испытаний.

 

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

На стадии Внедрения осуществляется подготовка и передача ПО и программной документации для сопровождения и/или изготовления, оформление и утверждение акта о передаче ПО на сопровождение или изготовление, передача ПО в фонд алгоритмов и программ.

Кроме рассмотренного выше жизненного цикла программ, установленного 19-ой системой стандартов, необходимо иметь в виду, что существует жизненный цикл автоматизированных систем, установленный ГОСТ 601-90. Имеет смысл рассмотреть стадии и этапы разработки АС, так как 19-я система стандартов в настоящее время морально устарела и более современным представляется жизненный цикл АС. Анализ жизненных циклов разработки ПО, установленных ГОСТ 102 и ГОСТ 601, а также международных стандартов, регламентирующих данный процесс, будет приведен ниже.

Стандарт ГОСТ 601 распространяется на автоматизированные системы (АС), представляющие собой организационно-технические системы, обеспечивающую выработку решений на основе автоматизации информационных потоков в различных видах деятельности (исследование, проектирование, управление и т. п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях. Данный стандарт устанавливает стадии и этапы создания АС.

В процессе разработки АС создают, в общем случае, следующие виды обеспечения: техническое, программное, информационное математическое и др. Проектные решения по программному, техническому и информационному обеспечению реализуют изделия в виде взаимоувязанной совокупности компонент и комплексов, входящей в состав АС с необходимой документацией. Справочное приложение к ГОСТ 601 устанавливает, что программное обеспечение АС — совокупность программ на носителях информации с программной документацией по ГОСТ 101. Таким образом, при разработке программного обеспечения можно пользоваться как стандартом ГОСТ 102, так и ГОСТ 601.

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

В стандарте ГОСТ 102, работы по развитию АС осуществляются по стадиям и этапам, применяемым для создания АС. Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяют в соответствующей документации организаций, участвующих в создании конкретных видов АС.

Стадии и этапы создания АС в общем случае приведены в таблице 2.5.

Стандартом ГОСТ 601 допускается исключать стадию Эскизный проект и отдельные этапы работ на всех стадиях, объединять стадии Технический проект и Рабочая документация в одну стадию Технорабочий проект. В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнения этапов работ, включение новых этапов работ.

Рассмотрим этапы, касающиеся разработки программного обеспечения.

При обследовании объекта и обосновании необходимости создания, АС проводят: сбор данных об объекте автоматизации и осуществляемых видах деятельности, оценку качества функционирования объекта и осуществляемых видов деятельности, выявления проблем, решение которых возможно средствами автоматизации; оценку (технико-экономической, социальной и т. п.) целесообразности создания АС.

На этапе Формирование требований пользователя к АС проводят:

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

— формулировку и оформление требований пользователя к АС.

  Таблица 2.5

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС 1.2. Формирование требований пользователя к АС 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта 2.2. Проведение необходимых научно — исследовательских работ 2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя 2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее частям 4.2. Разработка документации на АС и ее части
5. Технический проект	5.1. Разработка проектных решений по системе и ее частям 5.2. Разработка документации на АС и ее части 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части 6.2. Разработка или адаптация программ
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие 7.2. Подготовка персонала 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 7.4. Строительно-монтажные работы 7.5. Пусконаладочные работы 7.6. Проведение предварительных испытаний 7.7. Проведение опытной эксплуатации 7.8. Проведение приемочных испытаний
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами 8.2. Послегарантийное обслуживание

 

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

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

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

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

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

Результатом выполнения этапа Разработка предварительных проектных решений по системе и ее частям является: функции АС; функции подсистем, их цели и эффекты; состав комплекса задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции СУБД; состав вычислительной системы; функции и параметры основных программных средств.

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

На этапах 4.2 и 5.2 Разработка документации на АС и ее части проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС.

На этапе Разработка и оформление документации на поставку изделий для комплектации АС и (или) технических требований (технических заданий) на их разработку проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготавливаемых серийно.

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

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

На этапе Разработка и адаптация программ проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретенных программных средств, разработку программной документации в соответствии с ГОСТ 101.

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

Этап Подготовка персонала направлен на обучение персонала и проверку его способности обеспечить функционирование АС.

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

На этапе Пусконаладочные работы проводят автономную наладку технических и программных средств, загрузку информации в БД и проверку системы ее ведения; комплексную наладку всех средств системы.

На этапе Проведение предварительных испытаний осуществляют: испытание АС на работоспособность и соответствие ТЗ в соответствии с программой и методикой предварительных испытаний; устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний; оформление акта о приемке АС в опытную эксплуатацию.

На этапе Проведение опытной эксплуатации проводят: опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.

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

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

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

Требования к содержанию документов, разрабатываемых на каждой стадии и этапе, устанавливает руководящий документ РД-50-698-90. Кроме того, необходимо использовать для их разработки соответствующие стандарты Единой системы программной документации, Единой системы конструкторской документации и ГОСТ 602. Виды и комплектность документов регламентированы в ГОСТ 201.