Файл: Стандарты в области информационных систем. Международный стандарт isoiec 12207 19950801.rtf
Добавлен: 06.11.2023
Просмотров: 170
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Автономная некоммерческая образовательная организация высшего образования
«Сибирский институт бизнеса и информационных технологий»
Зачетная работа
№7 семестра
ПИСЬМЕННАЯ РАБОТА №1
Дисциплина: Проектирование информационных систем, часть 1
Тема: Стандарты в области информационных систем. Международный стандарт ISO/IEC 12207: 1995-08-01
Выполнил(а): Бобровский Дорин Игоревич
Группа ИН-418(2), 09.03.03 «Прикладная информатика»
Проверил(а): _____________________________
Омск 2023 г.
Содержание
| | Введение............................................................................................ | 4 |
| 1 | Стандарты проектирования информационных систем................ | 5 |
| 2 | Международный стандарт ISO/IEC 12207: 1995-08-01. и Стандарты комплекса ГОСТ 34 на создание и развитие АС....... | 6 |
| 3 | Основы методологии проектирования ИС и жизненный цикл по ИС................................................................................................. | 13 |
| 4 | Методологии и технологии проектирования ИС.......................... | 16 |
| | Заключение....................................................................................... | 20 |
| | Список использованной литературы.............................................. | 21 |
Введение
В настоящее время растут размеры и сложность информационных систем. Радикально изменяются не только требования к информационным системам и информационным технологиям, но и понятийный аппарат информационных систем. Разработка систем в новых условиях требует новых методов проектирования и новой организации проектных работ. Основные понятия информационных систем, проектирования информационных систем, зависят от стандартов, методологий и фирменных методик. При этом надо отметить, что информационная система (ИС) в огромном числе практически значимых случаев является системой автоматизации функций управления на предприятии, то есть АСУ. Системы должны работать надежно, должны быть совместимы с другими системами, должны нормально эксплуатироваться, поэтому нужно создать технические и технологические условия для решения этих вопросов. Стандарты удешевляют совокупную стоимость владения системами, облегчают возможность расширения, модификации и масштабирования систем, а следовательно увеличивают срок их жизни и окупаемость инвестиций.
Следование стандартам позволяет производителям техники наладить не мелкосерийное, а массовое производство продукции, повысить ее качество. Использование стандартов помогает снизить квалификационные требования к персоналу, сформировать четкие программы обучения, лучше подготовить персонал к решению практических задач.
В данной работе мы будем обширно рассматривать международные стандарты и методики используемые на различных этапах проектировании информационных систем. А также, зачем и кому нужны стандарты.
1. Стандарты проектирования информационных систем
Процесс разработки информационной системы должен быть стандартизован. Процесс графического представления модели с помощью некоторого стандартного набора графических элементов используется при визуальном моделировании (visual modeling). Наличие стандарта жизненно необходимо для реализации одного из преимуществ визуального моделирования – коммуникации разработчиков. Стандарты используются в специально разработанных технологиях документирования деятельности организации, для того чтобы облегчить взаимопонимание между участниками процесса моделирования. Общение между пользователями, разработчиками, аналитиками, тестировщиками, менеджерами и всеми остальными участниками проекта является основной целью визуального моделирования.
Стандарт как нормативно-технический документ устанавливает комплекс норм, правил, требований к объекту стандартизации и утверждается компетентным органом. Стандарты нужны:
•потребителям информационных систем (ИС) — для выбора техники, для упорядочения своей деятельности и взаимодействия с поставщиками;
•поставщикам продуктов и услуг - для снижения себестоимости продукции и следования требованиям рынка;
•разработчикам и эксплуатационникам ИС — для повышения качества решений и обеспечения совместимости с другими системами, а также для применения повторно используемых решений, для снижения трудоемкости и себестоимости работ, повышения их качества.
Стандарты должны соблюдаться на международном уровне, государственном уровне или на уровне отрасли. Стандарты могут быть разработаны в методических материалах фирм разного профиля и назначения.
В качестве примеров рассмотрим следующие стандарты:
1. Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО).
2. Стандарты комплекса ГОСТ 34 на создание и развитие АС.
3. Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.
2. Международный стандарт ISO/IEC 12207: 1995-08-01
В настоящее время существует несколько стандартов на проектирование и разработку информационных систем, которые можно сгруппировать следующим образом:
- по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
- по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT ), фирменные стандарты (Microsoft ODBC, IBM SNA);
- по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".
Принципиально важно и часто не очевидно, что в каждую из этих групп и подгрупп входят материалы, существенно разные по:
- степени обязательности для организаций разного типа;
- конкретности и детализации содержащихся требований;
- открытости и гибкости, адаптируемости к конкретным условиям.
Международный стандарт ISO/IEC 12207: 1995-08-01
По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО. Он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ. При этом процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.
Стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.
Общая структура стандарта представляет собой набор процессов ЖЦ. Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
В стандарте описаны 5 основных процессов ЖЦ ПО: процесс приобретения, процесс поставки, процесс разработки, процесс функционирования, процесс сопровождения. Описаны 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО. Вспомогательные процессы это процессы - решения проблем, документирования, управления конфигурацией, гарантирования качества, последний из которых использует результаты остальных процессов группы обеспечения качества, в которую входят: процесс верификации, процесс аттестации, процесс совместной оценки, процесс аудита. Описаны 4 организационных процесса: процесс управления, процесс создания инфраструктуры, процесс усовершенствования, процесс обучения. К ним примыкает особый процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.
Каких - либо этапов, фаз, стадий не предусмотрено, что дает хорошую степень адаптивности.
Особенности стандарта:
1. "Динамический" характер стандарта, заключающийся в такой последовательности выполнения процессов и задач, при которой один процесс при необходимости вызывает другой или его часть.
Примеры:
- выполнение Процесса приобретения в части анализа и фиксации требований к системе или ПО может вызывать исполнение соответствующих задач Процесса разработки;
- в Процессе поставки поставщик должен управлять субподрядчиками согласно Процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам;
- сопровождение может требовать развития системы и ПО, что выполняется по Процессу разработки.
Такой характер позволяет реализовывать любую модель ЖЦ.
2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.
3. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует ее в деталях. В нем не описано как реализовать или выполнить услуги и задачи, включенные в процессы. Он не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.
Конкретность пользы стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
- рассматривается область применения системы для определения требований системы;
- спецификация требований системы должна описывать: функции и возможности системы, бизнес, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования;
- квалификация требований системы должна быть документирована.
Далее, при выполнении анализа требований к ПО предусмотрено характеристика качеств, которые используются позже при гарантировании качества. При этом разработчик должен установить и документировать как требования к программному обеспечению:
- функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
- внешние связи (интерфейсы) с единицей программного обеспечения;
- требования квалификации;
- спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
- спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;
- человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;