ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.02.2024
Просмотров: 10
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Задание №1. Теоретический вопрос.
8. Модели жизненного цикла программного обеспечения. Основные модели жизненного цикла программного обеспечения.
Модель жизненного цикла – это структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни информационной системы (ИС), от определения требований до завершения ее использования. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых система создается и функционирует. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадная модель (1970 - 1985 гг.) и спиральная модель.(1986 - 1990 гг.).
В изначально существовавших однородных ИС программные приложения представляли собой единое целое. Для разработки такого типа приложений применялся каскадный способ.
Каскадная модель ЖЦ основывается на разбиении всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе (рис. 1.1).
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Преимущества применения каскадного способа заключаются в следующем:
• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
• выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная модель ЖЦ разработки ИС
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования для того, чтобы предоставить разработчикам свободу их рациональной технической реализации. В категорию каскадного подхода попадают сложные расчетные системы, системы реального времени и др.
В то же время этот подход обладает рядом недостатков, вызванных тем, что реальный процесс создания ИС никогда полностью не укладывался в такую жесткую схему, т.к. постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.
К основным недостаткам каскадного подхода можно отнести следующие недостатки:
-
существенное запаздывание с получением результатов работы; -
проведение промежуточного согласования с пользователями результатов разработки только в точках, планируемых после завершения каждого этапа работ; -
требования к ИС «заморожены» в виде технического задания и остаются неизменными на все время ее создания.
Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена, а в случае неточного изложения требований или их изменения в процессе создания программного обеспечения пользователи получают систему, не удовлетворяющую их потребностям. Кроме того, за время разработки ИС могут устареть модели автоматизируемого объекта (как функциональные, так и информационные).
Для преодоления перечисленных проблем была предложена спиральная модель.
Спиральная модель ЖЦ ИС предусматривает, что каждый виток спирали соответствует созданию фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали (рис. 1.3). В этой модели делается упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Таким образом, углубляются и последовательно конкретизируются детали проекта, и выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Рис. 1.3. Спиральная модель ЖЦ ИС
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Задание №2. Практическое задание №1. Изучить основные нормативные документы, характеризующие жизненный цикл программного обеспечения
Таблица 2 - Состав основных нормативных документов, характеризующий жизненный цикл программных средств и информационных систем
| Задания | ГОСТ 34.601-90 | ГОСТ 19.102-77 | ГОСТ Р ИСО/МЭК | ГОСТ Р ИСО/МЭК |
| Название ГОСТа | Автоматизированные Системы стадии создания | Гост 19.102-77 государственный стандарт союза сср | | |
| Стадия ЖЦ ПС и ИС | распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла, которая может быть доработана до поэтапной с ограниченным набором возвратов | структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного средства в течение всей жизни системы, от определения требований до завершения ее использования | | |
| Основные процессы | а) сбор данных об объекте автоматизации и осуществляемых видах деятельности; б) оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС. | Процесс приобретения.Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПС. Процесс поставки.Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПС. Процесс разработки.Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.Анализ требований к системе.Устанавливаются функции системы, условия внешней среды, качество и требования к характеристикам, требования к интерфейсам и к сопряжению аппаратных и программных средств.Проектирование системы.Требования к системе преобразуются в архитектуру системы, производится распределение функций и компонент между аппаратурой и программами, а также ручными операциями, что оформляется документом первичных требований к системе, компонентам и интерфейсам. Анализ требований к программному средству.Устанавливаются и документируются функции и предварительные спецификации требований к программным и информационным компонентам, их качество и физические характеристики, необходимые ресурсы компьютера, требования к базе данных и интерфейсам, к средствам обеспечения отладки и сопровождения. Проектирование архитектуры программного средства.Разрабатываются структура ПС и интерфейсы компонент, согласуются функции и технические требования к компонентам, методы и стандарты проектирования, а также отчетные документы по процессам и объектам разработки.Детальное проектирование программного средства.Проводится детальная разработка спецификаций каждой компоненты, интерфейса между ними и конфигурации ПС, разрабатываются требования к тестам и план интегрирования компонент. Программирование компонент.Разрабатываются текст программных модулей и описаний данных, процедуры и данные для их тестирования, документы результатов тестирования, документы процедур и данных для интеграции ПС. Процесс функционирования.Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПС) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности.Эксплуатация системы и программного средства.Заказчик или пользователь системы использует ее в соответствии с документацией, подготавливает отчеты о выявленных ошибках, а также о желательных модификациях и развитии системы и программного средства. Поддержка пользователей системы и программного средства.Осуществляются обучение и консультация пользователей, накапливаются и обрабатываются отчеты и рекомендации пользователей по совершенствованию системы; пользователи информируются об изменениях системы и ПС. Прекращение эксплуатации конфигурации системы и/или программного средства.Обоснование и извещение пользователей о прекращении поддержки версии системы, архивация версии и ее документации, предложение пользователям доступных вариантов для замены системы и/или программного средства. Процесс сопровождения.Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе.Анализ ошибок и предложений на модификацию программного средства.Исследуются спрос на модификацию, степень изменения программ и необходимые затраты, риск и возможные альтернативы, подготавливаются решения на изменения и тесты для проверки. Реализация модификации программного средства.Корректировка программ, данных и интерфейсов, разработка необходимых модулей и компонент, повторение тестирования и испытания версии программного средства и системы. Приемка, установка, настройка и опытная эксплуатация новой версии системы в реальной среде | | |
| Вспомогательные процессы | информационное; программное; техническое; организационное; метрологическое; правовое; лингвистическое. | решение проблем, документирование, управление конфигурацией, гарантирование качества (верификация, аттестация, совместная оценка, аудит),организационные процессы(управление, создание инфраструктуры, усовершенствование, обучение), адаптация (определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта). | | |
| Организационные процессы | Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т. п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях. Стандарт устанавливает стадии и этапы создания АС | Настоящий стандарт устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения | | |
| Итог работ на каждой стадии | | бщероссийский классификатор стандартов → Информационные технологии. Машины конторские → Программное обеспечение Классификатор государственных стандартов → Общетехнические и организационно-методические стандарты → Система документации → Система административно-управленческой документации, документооборота, организация архивного дела Тематические сборники → Единая система программной документации. | | |
| Год принятия стандарта | 01.01.1992 | 01.01.1980 | | |
| Принявший орган | ГОСТ | ГОСТ | | |
| На какую модель ЖЦ ориентирован | Жизненный цикл проекта имеет определенную начальную и конечную точки, привязанные к временной шкале. Проект в своем естественном развитии проходит ряд отдельных фаз. | | | |
| Разделы Стандарта |
| | | |
Задание №2. Изучение и проведение анализа стадий и этапов разработки АС (ГОСТ 34.601–90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»). Результаты работы оформить в виде таблицы (таблица 3). Таблица 3 - Стадии и этапы разработки АС
| Наименование этапа | Содержание этапа |
| 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. Послегарантийное обслуживание |
Задание №3. Изучение и проведение анализа стадий разработки программ и программной документации (ГОСТ 19.102–77 «Информационная технология. Стадии разработки программ и программной документации». Результаты работы оформить в виде таблицы (таблица 4, таблица 5). Таблица 4 - Стадии и этапы разработки ПС
| Стадии разработки | Этапы работ |
| 1 | 2 |
| Техническое задание | 1. |
| 2. | |
| 3. | |
| Эскизный проект | 1. |
| 2. | |
| Технический проект | 1. |
| 2. | |
| Рабочий проект | 1. |
| 2. | |
| 3. | |
| Внедрение | 1. |
Таблица 5 - Стадии и этапы разработки ПС
| Этапы работ | Содержание работ |
| 1 | 2 |
| Обоснование необходимости разработки программы | 1. |
| 2. | |
| 3. |
| | 4. |
| Научно-исследовательские работы | 1. |
| 2. | |
| 3. | |
| 4. | |
| 5. | |
| Разработка и утверждение технического задания | 1. |
| 2. | |
| 3. | |
| 4. | |
| Утверждение эскизного проекта | 1. |
| 2. | |
| Разработка технического проекта | 1. |
| 2. | |
| 3. | |
| 4. | |
| 5. | |
| 6. | |
| Утверждение технического проекта | 1. |
| 2. | |
| 3. | |
| Разработка программы | 1. |
| Разработка программной документации | 1. |
| Испытания программы | 1. |
| Подготовка и передача программы | 1. |