Программная инженерия. ЛР1 МЕТОДОЛОГИЯ И СТАНДАРТЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ЛР2 МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОЙ СИСТЕМЫ. Вариант 13. Автостоянка

Лабораторная работа
в среде программирования ISO



Если Вы считаете, что данная страница каким-либо образом нарушает Ваши авторские права, то Вам следует обратиться в администрацию нашего сайта по адресу info@kursovik.com либо через форму обратной связи

Среда программирования: ISO

Название работы: Программная инженерия. ЛР1 МЕТОДОЛОГИЯ И СТАНДАРТЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ЛР2 МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОЙ СИСТЕМЫ. Вариант 13. Автостоянка

Вид работы: Лабораторная работа

Описание: Программная инженерия.

Вариант 13. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.

ЛАБОРАТОРНАЯ РАБОТА № 1
МЕТОДОЛОГИЯ И СТАНДАРТЫ СОЗДАНИЯ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Цель работы: общее знакомство с ГОСТ ИСО/МЭК 12207-99
и ГОСТ Р ИСО/МЭК 9126-93 (Приложения 2, 3) и применение их
к разработке программного обеспечения по выбранной теме. Со-
ставить и проанализировать требования к информационной си-
стеме, оформить техническое задание на разработку программно-
го обеспечения.
Общие сведения о требованиях к информационным системам
Проблемы, которые приходится решать специалистам в
процессе создания программного обеспечения, очень сложны.
Природа этих проблем не всегда ясна, особенно если разрабаты-
ваемая программная система инновационная. В частности, труд-
но чётко описать те действия, которые должна выполнять систе-
ма. Описание функциональных возможностей и ограничений,
накладываемых на систему, называется требованиями к этой си-
стеме, а сам процесс формирования, анализа, документирования
и проверки этих функциональных возможностей и ограничений
— разработкой требований.
Требования подразделяются на пользовательские и систем-
ные. Пользовательские требования — это описание на естествен-
ном языке (плюс поясняющие диаграммы) функций, выполняе-
мых системой, и ограничений, накладываемых на неё. Системные
требования — это описание особенностей системы (архитектура
системы, требования к параметрам оборудования и т.д.), необхо-
димых для эффективной реализации требований пользователя.
Разработка требований — это процесс, включающий меро-
приятия, необходимые для создания и утверждения документа,
содержащего спецификацию системных требований. Различают
четыре основных этапа процесса разработки требований:
1) анализ технической осуществимости создания системы;
2) формирование и анализ требований;
3) специфицирование требований и создание соответствую-
щей документации;
4) аттестация этих требований.
На рис. 1 показаны взаимосвязи между этими этапами и ре-
зультаты, сопровождающие каждый этап процесса разработки
системных требований.
Рис. 1. Процесс разработки требований
Но поскольку в процессе разработки системы в силу разно-
образных причин требования могут меняться, управление требо-
ваниями, т.е. процесс управления изменениями системных требо-
ваний, является необходимой составной частью деятельности по
их разработке.
Следующим этапом процесса разработки требований явля-
ется формирование (определение) и анализ требований.
Обобщенная модель процесса формирования и анализа тре-
бований показана на рис. 2. Каждая организация использует соб-
ственный вариант этой модели, зависящий от «местных факто-
ров»: опыта работы коллектива разработчиков, типа разрабатыва-
емой системы, используемых стандартов и т.д.
Рис. 2. Процесс формирования и анализа требований
Процесс формирования и анализа требований проходит че-
рез ряд этапов.
1. Анализ предметной области. Аналитики должны изучить
предметную область, где будет эксплуатироваться система.
2. Сбор требований. Это процесс взаимодействия с лицами,
формирующими требования. Во время этого процесса продолжа-
ется анализ предметной области.
3. Классификация требований. На этом этапе бесформенный
набор требований преобразуется в логически связанные группы
требований.
4. Разрешение противоречий. Без сомнения, требования
многочисленных лиц, занятых в процессе формирования требо-
ваний, будут противоречивыми. На этом этапе определяются и
разрешаются противоречия различного рода.
5. Назначение приоритетов. В любом наборе требований
одни из них будут более важны, чем другие. На этом этапе сов-
местно с лицами, формирующими требования, определяются
наиболее важные требования.
6. Проверка требований. На этом этапе определяется их
полнота, последовательность и непротиворечивость.
Процесс формирования и анализа требований циклический,
с обратной связью от одного этапа к другому. Цикл начинается с
анализа предметной области и заканчивается проверкой требова-
ний. Понимание требований предметной области увеличивается в
каждом цикле процесса формирования требований.
Рассмотрим подход к формированию требований, основан-
ный на множестве опорных точек зрения.
Опорные точки зрения. Подход с использованием различ-
ных опорных точек зрения к разработке требований признает
различные (опорные) точки зрения на проблему и использует их
в качестве основы построения и организации как процесса фор-
мирования требований, так и непосредственно самих требований.
Различные методы предлагают разные трактовки выражения
«точка зрения». Точки зрения можно трактовать следующим об-
разом. Как источник информации о системных данных. В этом
случае на основе опорных точек зрения строится модель создания
и использования данных в системе. В процессе формирования
требований отбираются все такие точки зрения (и на их основе
определяются данные), которые будут созданы или использованы
при работе системы, а также способы обработки этих данных.
Как структура представлений. В этом случае точки зрения
рассматриваются как особая часть модели системы. Например, на
основе различных точек зрения могут разрабатываться модели
«сущность-связь», модели конечного автомата и т.д. Как получа-
тели системных сервисов. В этом случае точки зрения являются
внешними (относительно системы) получателями системных сер-
висов. Точки зрения помогают определить данные, необходимые
для выполнения системных сервисов или их управления.
Наиболее эффективным подходом к анализу таких систем
является использование внешних опорных точек зрения. На ос-
нове этого подхода разработан метод VORD (Viewpoint-Oriented
Requirements Definition — определение требований на основе то-
чек зрения) для формирования и анализа требований. Основные
этапы метода VORD показаны на рис. 3:
Рис. 3. Метод VORD

Идентификация точек зрения, получающих системные сер-
висы, и идентификация сервисов, соответствующих каждой точке
зрения. Структурирование точек зрения — создание иерархии
сгруппированных точек зрения. Общесистемные сервисы предо-
ставляются более высоким уровням иерархии и наследуются точ-
ками зрения низшего уровня.
Документирование опорных точек зрения, которое заключа-
ется в точном описании идентифицированных точек зрения и
сервисов. Отображение системы точек зрения, которая показыва-
ет системные объекты, определенные на основе информации, за-
ключенной в опорных точках зрения.
Пример. Рассмотрим использование метода VORD на пер-
вых трех шагах анализа требований для системы поддержки зака-
за и учета товаров в бакалейной лавке. В бакалейной лавке для
каждого товара фиксируется место хранения (определенная пол-
ка), количество товара и его поставщик. Система поддержки за-
каза и учета товаров должна обеспечивать добавление информа-
ции о новом товаре, изменение или удаление информации об
имеющемся товаре, хранение (добавление, изменение и удале-
ние) информации о поставщиках, включающей в себя название
фирмы, ее адрес и телефон. При помощи системы составляются
заказы поставщикам. Каждый заказ может содержать несколько
позиций, в каждой позиции указываются наименование товара и
его количество в заказе. Система по требованию пользователя
формирует и выдает на печать следующую справочную инфор-
мацию:
1) список всех товаров;
2) список товаров, имеющихся в наличии;
3) список товаров, количество которых необходимо попол-
нить;
4) список товаров, поставляемых данным поставщиком.
Первым шагом в формировании требований является иден-
тификация опорных точек зрения. Во всех методах формирова-
ния требований, основанных на использовании точек зрения,
начальная идентификация является наиболее трудной задачей.
Один из подходов к идентификации точек зрения — метод «моз-
говой атаки», когда определяются потенциальные системные
сервисы и организации, взаимодействующие с системой. Органи-
зуется встреча лиц, участвующих в формировании требований,
которые предлагают свои точки зрения. Эти точки зрения пред-
ставляются в виде диаграммы, состоящей из ряда круговых обла-
стей, отображающих возможные точки зрения (рис. 4). Во время
«мозговой атаки» необходимо идентифицировать потенциальные
опорные точки зрения, системные сервисы, входные данные, не-
функциональные требования, управляющие события и исключи-
тельные ситуации.
Следующей стадией процесса формирования требований бу-
дет идентификация опорных точек зрения (на рис. 4 показаны в ви-
де темных круговых областей) и сервисов (показаны в виде зате-
ненных областей). Сервисы должны соответствовать опорным точ-
кам зрения. Но могут быть сервисы, которые не поставлены им в
соответствие. Это означает, что на начальном этапе «мозговой ата-
ки» некоторые опорные точки зрения не были идентифицированы.
Рис. 4. Диаграмма идентификации точек зрения
В таблице 1 показано распределение сервисов для некото-
рых идентифицированных на рис. 4 точек зрения. Один и тот же
сервис может быть соотнесен с несколькими точками зрения.
Информация, извлеченная из точек зрения, используется для
заполнения форм шаблонов точек зрения и организации точек
зрения в иерархию наследования. Это позволяет увидеть общие
точки зрения и повторно использовать информацию в иерархии
наследования. Сервисы, данные и управляющая информация
наследуются подмножеством точек зрения.
Таблица 1 — Сервисы, соотнесенные с точками зрения
На рис. 5 показана часть иерархии точек зрения для системы
поддержки заказа и учета товаров.
Рис. 5. Иерархия точек зрения

Аттестация требований. Аттестация должна продемонстри-
ровать, что требования действительно определяют ту систему,
которую хочет иметь заказчик. Проверка требований важна, так
как ошибки в спецификации требований могут привести к пере-
делке системы и большим затратам, если будут обнаружены во
время процесса разработки системы или после введения ее в экс-
плуатацию. Стоимость внесения в систему изменений, необходи-
мых для устранения ошибок в требованиях, намного выше, чем
исправление ошибок проектирования или кодирования. Причина
в том, что изменение требований обычно влечет за собой значи-
тельные изменения в системе, после внесения которых она долж-
на пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены раз-
личные типы проверок требований. Проверка правильности тре-
бований. Пользователь может считать, что система необходима
для выполнения некоторых определенных функций. Однако даль-
нейшие размышления и анализ могут привести к необходимости
введения дополнительных или новых функций. Системы предна-
значены для разных пользователей с различными потребностями,
и поэтому набор требований будет представлять собой некоторый
компромисс между требованиями пользователей системы.
1. Проверка на непротиворечивость. Спецификация требова-
ний не должна содержать противоречий. Это означает, что в тре-
бованиях не должно быть противоречащих друг другу ограниче-
ний или различных описаний одной и той же системной функции.
2. Проверка на полноту. Спецификация требований должна
содержать требования, которые определяют все системные функ-
ции и ограничения, налагаемые на систему.
3. Проверка на выполнимость. На основе знания существу-
ющих технологий требования должны быть проверены на воз-
можность их реального выполнения. Здесь также проверяются
возможности финансирования и график разработки системы.
Существует ряд методов аттестации требований, которые
можно использовать совместно или каждый в отдельности.
Обзор требований. Требования системно анализируются ре-
цензентами.
1. Прототипирование. На этом этапе прототип системы де-
монстрируется конечным пользователям и заказчику. Они могут
экспериментировать с этим прототипом, чтобы убедиться, что он
отвечает их потребностям.
2. Генерация тестовых сценариев. В идеале требования
должны быть такими, чтобы их реализацию можно было проте-
стировать. Если тесты для требований разрабатываются как часть
процесса аттестации, то часто это позволяет обнаружить пробле-
мы в спецификации. Если такие тесты сложно или невозможно
разработать, то обычно это означает, что требования трудно вы-
полнить и поэтому необходимо их пересмотреть.
3. Автоматизированный анализ непротиворечивости. Если
требования представлены в виде структурных или формальных
системных моделей, можно использовать инструментальные
CASE-средства для проверки непротиворечивости моделей. Для
автоматизированной проверки непротиворечивости необходимо
построить базу данных требований и затем проверить все требо-
вания в этой базе данных. Анализатор требований готовит отчет
обо всех обнаруженных противоречиях.
Пользовательские и системные требования. На основании по-
лученных моделей строятся пользовательские требования, т.е., как
было сказано вначале, описание на естественном языке функций,
выполняемых системой, и ограничений, накладываемых на неё.
Пользовательские требования должны описывать внешнее
поведение системы, основные функции и сервисы предоставляе-
мые системой, её нефункциональные свойства. Необходимо вы-
делить опорные точки зрения и сгруппировать требования в со-
ответствии с ними. Пользовательские требования можно офор-
мить как простым перечислением, так и используя нотацию вари-
антов использования.
Далее составляются системные требования. Они включат в
себя:
1. Требования к архитектуре системы. Например, число и
размещение хранилищ и серверов приложений.
2. Требования к параметрам оборудования. Например, часто-
та процессоров серверов и клиентов, объём хранилищ, размер опе-
ративной и видеопамяти, пропускная способность канала и т.д.
3. Требования к параметрам системы. Например, время от-
клика на действие пользователя, максимальный размер передава-
емого файла, максимальная скорость передачи данных, макси-
мальное число одновременно работающих пользователей и т.д.
4. Требования к программному интерфейсу.
5. Требования к структуре системы. Например, масштаби-
руемость, распределенность, модульность, открытость:
 масштабируемость — возможность распространения си-
стемы на большое количество машин, не приводящая к потере
работоспособности и эффективности, при этом способность си-
стемы наращивать свою мощность должна определяться только
мощностью соответствующего аппаратного обеспечения;
• распределенность — система должна поддерживать рас-
пределённое хранение данных;
• модульность — система должна состоять из отдельных
модулей, интегрированных между собой;
• открытость — наличие открытых интерфейсов для воз-
можной доработки и интеграции с другими системами.
6. Требования по взаимодействию и интеграции с другими
системами. Например, использование общей базы данных, возмож-
ность получения данных из баз данных определённых систем и т.д.
Порядок выполнения работы
1. Изучить предлагаемый теоретический материал и стан-
дарты ГОСТ ИСО/МЭК 12207-99, ГОСТ Р ИСО/МЭК 9126-93.
2. Построить опорные точки зрения на основании метода
VORD для формирования и анализа требований для выбранной
темы разработки ПО. Результатом должны явиться две диаграм-
мы: диаграмма идентификации точек зрения и диаграмм иерар-
хии точек зрения.
3. Составить информационную модель будущей системы,
включающую в себя описание основных объектов системы и вза-
имодействия между ними. На основании полученной информа-
ционной модели и диаграмм идентификации точек зрения, диа-
грамма иерархии точек зрения сформировать требования пользо-
вателя и системные требования.
4. Провести аттестацию требований, указать, какие типы
проверок выбрали.
5. На основании описания информационной системы, поль-
зовательских и системных требований составить техническое за-
дание (ТЗ) на создание программного обеспечения. ТЗ должно
содержать основные разделы, описанные в ГОСТ 34.602-89 (см.
шаблон технического задания согласно ГОСТ 34, представлен-
ный в Приложении 4). Техническое задание должно учитывать
наличие пользовательских требований, четко описывающих бу-
дущий функционал системы; наличие системных требований,
включающих требования к структуре, программному интерфей-
су, технологиям разработки, общие требования к системе
(надежность, масштабируемость, распределенность, модуль-
ность, безопасность, открытость, удобство пользования и т.д.);
6. Оформить отчёт, включающий все полученные результаты.

Содержание отчета
Отчет по лабораторной работе № 1 должен содержать:
1. Цель работы.
2. Введение.
3. Программно-аппаратные средства, используемые при вы-
полнении работы.
4. Основную часть (описание самой работы).
5. Заключение (выводы).
6. Список используемой литературы.


ЛАБОРАТОРНАЯ РАБОТА № 2
МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОЙ СИСТЕМЫ
Цель работы: общее знакомство с моделями жизненного цикла программных систем, согласно стандартам ГОСТ ИСО/МЭК
12207-99 и ГОСТ Р ИСО/МЭК 9126-93 (Приложения 2, 3), и приложение их к разработке программного обеспечения по выбранной теме.
Основные теоретические положения
При возникновении потребностей в заказе, приобретении,
разработке, эксплуатации и сопровождении программ перед всеми сторонами, вовлеченными в жизненный цикл программного
средства (ПС), возникает целый ряд вопросов, связанных с определением и детальным структурированием жизненного цикла
(ЖЦ) ПС, с организационными и техническими правами и обязанностями сторон, с управлением ЖЦ и контролем за его реализацией. Одним из действенных инструментов для решения данных вопросов является использование унифицированных подходов, закрепленных в современных международных и российских
стандартах.
Слова «жизненный цикл системы» или «жизненный цикл
программного средства» часто появляются в статьях и звучат в
разговорах разработчиков, по крайней мере руководителей проектов и подразделений. Всем понятно, что относятся они к тому,
что и в какой последовательности должно делаться при создании
и эксплуатации систем. Но прежде чем две организации или два
специалиста договорятся о том, что конкретно входит или не
входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две «стороны») все-таки поразному понимают, какие работы будут входить в ЖЦ, а какие — нет, какие проверки будут планироваться, когда и т. д. Естественно, общие принципы организации работ описаны давно, но
что делать сторонам в конкретном проекте — это каждый раз
приходится решать заново.
В стандартах, регламентирующих жизненный цикл программных средств, обобщаются опыт и результаты исследований множества специалистов и рекомендуются наиболее эффективные современные методы и процессы создания и развития комплексов программ. В результате таких обобщений оттачиваются
технологические процессы и приемы разработки, а также методическая база для их автоматизации. ЖЦ ПС в стандартах представляет собой набор этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующих
ведение работ от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ПС или
информационной системы (ИС).
Стандарты включают правила описания исходной информации, способов и методов выполнения операций, устанавливают
правила контроля технологических процессов, требования к
оформлению их результатов, а также регламентируют содержание технологических и эксплуатационных документов на комплексы программ. Они определяют организационную структуру
коллектива, обеспечивают распределение и планирование заданий, а также контроль за ходом создания ПС.
Кроме вопросов выбора типа общего устройства ЖЦ есть
проблемы с решением частных вопросов о включении или не
включении в ЖЦ отдельных работ, очень важных для качества
ПС и системы: что документировать при создании системы и ПС,
какие работы должны будут гарантировать качество продукта, с
какой степенью организационной независимости должны выполняться проверочные процедуры разных типов, чем будет обеспечиваться соответствие разрабатываемого ПС требованиям ко всей
системе и соответствие ПС потребностям в системе. Для того
чтобы привнести порядок и понимание, общие для любых сторон, участвующих в ЖЦ систем и ПС, давно разрабатывались
стандарты различных уровней утверждения — национальные и
международные.
Существующее многообразие номенклатуры и функциональных возможностей эксплуатируемых, разрабатываемых и
перспективных ПС затрудняет использование для них традиционных методов стандартизации групп (видов) однородной продукции. В то же время обязательная реализация в ходе проекта
типовых процессов ЖЦ (заказ, поставка, разработка, эксплуатация, сопровождение и т.д.) дает возможность использовать прин-
ципы и методы функциональной стандартизации, основанные на
применении базовых стандартов и разработанных на их основе
профилей стандартов для конкретного типа объекта (в нашем
случае — проекта и системы).
Под профилем стандарта понимается принятый нормативный документ, регламентирующий требования, нормы и правила,
выбранные из базовых стандартов и при необходимости дополненные и/или уточненные (ограниченные) применительно к конкретной классификационной группе данного объекта стандартизации.
Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информации и
управления в реальном времени. К таким ПС предъявляются
наиболее высокие требования по качеству функционирования,
они создаются большими коллективами специалистов в течение
длительного времени.
Впервые формализованный и утвержденный стандарт жизненного цикла был утвержден в 1985 г. (уточнен в 1988 г.) для
проектирования ПС систем военного назначения по заказам Министерства обороны США — стандарт DODSTD-2167 А. Этим
документом регламентированы 8 фаз (этапов) при создании
сложных, критических ПС и около 250 типовых обязательных
требований к процессам и объектам проектирования на этих этапах. ПС рассматриваются как часть специализированных информационных систем военного назначения. Поэтому начальные
этапы проектирования и заключительные этапы испытаний и
сдачи заказчику объединены в совместный анализ программных
и аппаратных средств цельной системы вооружения, полностью
решающей поставленные функциональные задачи.
В стандарте DOD представлена часть ЖЦ ПС, отражающая
только непосредственно создание программ. Отсутствуют этапы
эксплуатации и сопровождения, а также не полностью раскрыты
процессы управления разработкой и интегральные процессы технологической поддержки ЖЦ ПС. В начале стандарта DOD-STD2167 А определены область его действия и общие условия применения. Приведены базовый перечень ссылочных документов и
определения понятий, терминов и аббревиатур. Основная совокупность требований изложена в двух крупных разделах: наиболее общие требования ко всему процессу создания ПС и детальные требования к каждому его этапу. Общие требования касаются планирования и управления разработкой ПС, правил взаимодействия с субподрядчиками и испытателями, а также документирования результатов. Изложены общие требования к технологии и средствам автоматизации создания программ, к структуре и организации комплекса программ и поддерживающей его БД.
Специальный раздел посвящен требованиям к квалификационным испытаниям, средствам и организации тестирования
программ на всех этапах. Изложены требования к организации,
выполнению и документированию оценок качества программной
продукции, а также требования к конфигурационному управлению ПС. Завершаются общие требования правилами перехода к
сопровождению ПС, к организации и документированию этого
процесса. Детальные требования распределены по восьми этапам
разработки. В этом стандарте после того, как сформулированы
концепция и общие требования к системе (этап 1), выделяются и
детализируются требования к ПС (этап 2). Далее начинается собственно процесс создания программ (этапы 3—6). Названия, последовательность и содержание этапов предварительного (этап 3)
и детального (этап 4) проектирования, а также разработки компонентов (этап 5) и их интеграции (комплексирования) и тестирования (этап 6) достаточно близки к соответствующим процессам
в стандартах ISO (см. ниже). По окончании этапов 3—6 проводятся тестирование ПС на реализующей (объектной) ЭВМ (этап
7), интегрирование и испытание ПС в составе системы (этап 8).
Для всех этапов детальные требования имеют одинаковую структуру разделов.
В них для каждого этапа конкретизируются разделы общих
требований и отражены требования к управлению проектом, технологии, официальным квалификационным испытаниям, оценке
качества программной продукции и к конфигурационному управлению. Весь процесс создания ПС поддерживается комплектом
из 30 частных документов и 7 сводных отчетов (обзоров) по этапам. Наиболее полно раскрыты этапы предварительного (эскизного) и детального (технического) проектирования, каждый из
которых состоит из 6—7 процессов. В результате представленную схему можно использовать как базу для планирования, организации и автоматизации процессов разработки ПС.
Для замены стандартов DOD-STD-2167 А, 7935 А, 1703 Министерством обороны США в декабре 1994 г. утвержден военный
стандарт MIL-STD-498 Разработка и документирование программного обеспечения. Он предназначен для применения всеми
организациями и предприятиями, получающими заказы Министерства обороны США. Этот стандарт базируется на процессах и
документах, представленных в стандарте ISO 12207 и предшествующих военных стандартах. Общая структура стандарта близка к структуре DOD-STD-2167 А, однако детальные требования
пятого раздела изложены значительно глубже и шире в 19 подразделах. Кроме того, число приложений увеличено до девяти. В
1996 г. утверждено очень подробное (407 страниц) руководство
«Применение и рекомендации к стандарту MIL-STD-498». Основную часть пятого раздела составляют 75 подразделов — рекомендаций по обеспечению и реализации процессов ЖЦ сложных критических ПС высокого качества и надежности, функционирующих в реальном времени.
В России первые основы построения и использования профилей стандартов ЖЦ ПС заложены принятием в качестве базового стандарта ГОСТ Р ИСО/МЭК12207. Данный документ введен в действие с 1 июля 2000 г., тесно взаимоувязан с рядом
стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения
стандартов ИСО. Актуальность стандарта ГОСТ Р ИСО/МЭК
12207 для современных условий настолько высока, что принятие
в ISO его исходного международного варианта вскоре вызвало
самую положительную оценку российских экспертов. Был дан
ряд рекомендаций по его использованию в реальных условиях. В
данном стандарте программное обеспечение ПО (или программный продукт) определяется как набор компьютерных программ,
процедур и, возможно, связанной с ними документации и данных. Процесс определяется как совокупность взаимосвязанных
действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами
и методами их решения, исходными данными, полученными от
других процессов, и результатами.
Следует отметить, что в России создание ПО первоначально, в 70-е годы 20 века, регламентировалось стандартами ГОСТ
ЕСПД (Единой системы программной документации — серия
ГОСТ 19.XXX), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, сроки их действия закончились и использование нецелесообразно. Процессы создания автоматизированных систем (АС), в состав которых входит и ПО, регламентированы стандартами ГОСТ 34.601-90 «Информационная
технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания», ГОСТ
34.602-89 «Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание
автоматизированной системы» и ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем
«. Однако процессы создания ПО для современных распределенных ЭИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдельные их положения явно
устарели. В результате для каждого серьезного проекта ЭИС
приходится создавать комплекты нормативных и методических
документов, регламентирующих процессы создания конкретного
прикладного ПО, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
В стандарте ГОСТ Р ИСО/МЭК 12207 впервые реализован
принцип структурной стандартизации ЖЦ ПС на основе регламентации требований к процессам, работам и задачам, входящим в
полную типовую структуру ЖЦ ПС. Процессы ЖЦ ПС выделены
по принципу ответственности субъекта (заказчика, поставщика,
разработчика и т. д.), реализующего конкретный процесс. В свою
очередь, каждый из процессов состоит из ряда работ и решаемых
при выполнении соответствующей работы задач. С точки зрения
соподчиненности и важности данных процессов они разбиты на
три группы: основные; вспомогательные; организационные.
Группа основных процессов включает в себя процессы:
приобретение; поставка; разработка; эксплуатация; сопровождение. Группа вспомогательных процессов включает в себя процессы, обеспечивающие выполнение основных процессов: документирование; управление конфигурацией; обеспечение качества;
верификация; аттестация; оценка; аудит; решение проблем.
Группа организационных процессов включает в себя процессы: управление проектами; создание инфраструктуры проекта;
определение, оценка и улучшение самого ЖЦ; обучение.
Очень важное отличие ISO: каждый процесс, действие или
задача инициируется и выполняется другим процессом по мере
необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т.п.).
Порядок выполнения работы
1. Продолжить изучение стандартов ГОСТ ИСО/МЭК
12207-99 и ГОСТ Р ИСО/МЭК 9126-93.
2. Дать понятие жизненного цикла (ЖЦ) программного продукта (ПП) и его структуры.
3. Дать понятие процесса и составить классификацию процессов ЖЦ ПП.
3. На основании стандарта провести анализ его применимости к разработке программного обеспечения по выбранной теме.
По результатам изучения стандарта оформить отчет о проделанной работе.

Содержание отчета
Отчет по лабораторной работе № 2 должен содержать:
1. Цель работы.
2. Введение. Краткое описание структуры стандартов в области ЖЦ ПП.
3. Описание ЖЦ разрабатываемой информационной системы (ПО).
4. Заключение (выводы).
5. Список используемой литературы.

Год: 2023

Данный заказ (лабораторная работа) выполнялся нашим сайтом в 2023-м году, в рамках этого заказа была разработана программа в среде программирования ISO. Если у Вас похожее задание на программу, которую нужно написать на ISO, либо на другом языке программирования, пожалуйста заполните форму, приведённую ниже, после чего Ваше задание в первую очередь рассмотрит наш программист, выполнявший в 2023-м году этот заказ, если он откажется, то Ваше задание оценят другие наши программисты в течение 48-и часов, если оценка нужна срочно, просим Вас оставить пометку об этом - напишите в тексте задания фразу "СРОЧНЫЙ ЗАКАЗ".

Купить эту работу

Тел.: +79374242235
Viber: +79374242235
Telegram: kursovikcom
ВКонтакте: kursovikcom
WhatsApp +79374242235
E-mail: info@kursovik.com
Skype: kursovik.com