Сертификация. Практикум по проектированию программного обеспечения экономических информационных систем уч пособие А. М. Вендров. М. Финансы и статистика, 2002. 192 с
 Скачать 1.48 Mb.
|
|
Разработка и стандартизация программных средств и информационных технологий Пятовский Сергей Евгеньевич Кафедра 504 «Экономическая информатика» k504@mai.ru http://www.mai.ru/colleges/fac_5/kaf/k504
Разработка и стандартизация программных средств и информационных технологий Стандартизация разработки программных средств: уч. пособие // В.А.Благодатских, В.А.Волнин, К.Ф.Поскакалов; под ред. О.С.Разумова. – М.: Финансы и статистика, 2006. – 288 с. Метрология, качество и сертификация программного обеспечения // Е.В.Ковалевская. – М.: МЭСИ, 2004. – 95 с. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-CMM). – М.: Книга и бизнес, 2001. – 348 с. Практикум по проектированию программного обеспечения экономических информационных систем: уч. пособие // А.М.Вендров. – М.: Финансы и статистика, 2002. – 192 с. Моделирование и анализ систем. IDEF-технологии: практикум // С.В.Черемных, И.О.Семенов, В.С.Ручкин. – М.: Финансы и статистика, 2002. – 192 с. ISO 15504-1-9: 1998 : Оценка и аттестация зрелости процессов создания и сопровождения программных средств // А.С.Агапова. – Книга и бизнес, 2001. Стандарты ЕСПД ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению. ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование. Литература Цель курса Определить основные понятия в ИТ Ознакомиться с нормативно-правовыми актами (НПА) и видами стандартов для ПО Получить представление о международных и национальных организациях по разработке стандартов Разработка и стандартизация программных средств и информационных технологий Курсовые работы Цель КР – реализация процессов ЖЦ программного средства, для которого предполагается возможность тиражирования и применение как ППП для решения набора экономических задач конечного пользователя. В КР реализуются процессы разработки, документирования, обеспечения качества, приемки работ, приемки изделия, управления проектом, согласно ГОСТ Р ИСО/МЭК 12207-99. КР пишется с ориентацией на получение отчуждаемого ПП, который может эксплуатироваться пользователем без участия разработчика, и сопровождение которого возможно посредником с консультациями разработчика. Этапы разработки программного продукта Этап I. Анализ требований к ПП с формированием ТЗ на разрабатываемое ПО. В ТЗ определяются:
основание для разработки; требования заказчика к ПП; требования по передаче программной продукции заказчику, ее оценки и установке на месте эксплуатации; календарный план разработки с указанием сроков завершения этапов и работы в целом. В качестве заказчика в КР выступает юридическое лицо. Результат - определяется предварительная стоимость ПП или сумма договора на разработку в зависимости от вида создаваемого ПП. Приводится ее обоснование. Этапы разработки программного продукта Этап II. Проведение технологической подготовки разработки и ее планирование, выбор с кратким обоснованием:
инструментальных средств, повышающих степень автоматизации и производительности труда разработчика в процессе формирования ПО, его корректировки, отладки и документирования; средств управления процессом разработки; определение состава работ по реализации проекта, последовательность их выполнения, сроки, исполнители и требуемые для них ресурсы, обеспечивающие выполнение работ. Результаты технологической подготовки представляются как набор детального календарного плана работ с указанием всех упомянутых характеристик и индивидуальных планов-заданий по исполнителям. Этапы разработки программного продукта Этап III. Проектирование архитектуры ПП:
разработка форм выходной информации, печатной и экранной, по задачам, выдаваемой пользователю в результате работы ПП; разработка пользовательского интерфейса, который позволяет пользователю осуществить управление работой ПП при его эксплуатации; разработка проектных решений по принципам реализации других требований заказчика к ПП, оговариваемых в ТЗ. Результаты работ по проектированию архитектуры ПП согласовываются с заказчиком и документируются в соответствии с ТЗ и стандартами на разработку программных средств. Этапы разработки программного продукта Этап IV. Разработка проекта ПП.
Вместе со структурой программного комплекса определяется состав и структура БД. Определение порядка взаимосвязи программных компонент в комплексе. Структуру комплекса представляется в виде графа, в котором каждый элемент соответствует программному модулю, компоненту БД, входному или выходному документу, а связи между элементами означают функциональные и информационные взаимосвязи между этими объектами. Результаты выполнения работ документируются в соответствии с ТЗ и стандартами на разработку программных средств. Этапы разработки программного продукта Этап V. Программная реализация и тестирование ПП. Пользователю необходимо предоставить возможность применять только средства интерфейса разработанного ПП:
стандарты на разработку модулей обращения к БД; стандарты на разработку модулей реализации функциональных работ пользователя. Результат выполнения работ приводится согласно стандартам в виде набора документов «Текст программы» для отдельных программных модулей в расчете на доступность понимания синтаксиса, семантики и прагматики ПО технологически подготовленным пользователем документа, даже когда пользователь не связан с программной реализацией. Этапы разработки программного продукта Этап VI. Подготовка программной документации, в которой необходимы два раздела, ориентированных на специалистов двух категорий:
Конечный пользователь ППП. Результат – пакет документов «Описание применения» и «Руководство пользователя». Этапы разработки программного продукта Этап VII. Представление материалов по управлению процессом разработки, связанным с обеспечением фактического выполнения календарного плана, утвержденного в ТЗ. Результат – указание фактических затрат ресурсов и причины их отклонения от предполагаемых. Формулируются предложения по корректировке цены поставки и сопровождения ПП в зависимости от результатов разработки. Варианты тем курсовых работ
Основные определения Стандартизация разработка и установление требований, норм, правил, характеристик, обязательных или рекомендуемых для выполнения, обеспечивающая права потребителей на качественный продукт Базовый стандарт нормативный документ, регламентирующий типовые требования, нормы и правила применительно к объекту стандартизации Прикладное программное обеспечение (ППО) ПО, выполняющее задачи, поставленные конечными пользователями Пакет прикладных программ (ППП) (software package) готовый исходный код нескольких приложений Жизненный цикл (ЖЦ) программного средства комплекс работ по созданию программного средства от момента принятия решения о начале разработки до окончания функционирования программного средства на объекте автоматизации Качество ПС совокупность признаков и характеристик продукции, отражающая способность удовлетворять установленным или предполагаемым потребностям Классификация стандартов География стандартов: Международные Национальные Отраслевые Внутрифирменные (ГОСТ 19.201-78 Техническое задание и др.) В зависимости от возникновения: Де-факто (SQL, SADT) Де-юре (OSI – Open Systems Interconnection reference model, Ethernet, POSIX, SQL) Стандарты на организацию жизненного цикла ПС: Стандарты обеспечения качества Стандарты надежности Стандарты разработки ПО Стандарты тестирования Стандарты документирования Стандарты интерфейса Стандарты программирования Стандарты обмена данными Классификация стандартов По моделям разработки: RUP TickiT CMM ORACLE:
PJM AIM BPR DWM IEEE Software Engineering Standards IEEE / EIA 12207 CleanRoom Software Engineering Model Международные организации: 1946 г. – Международная организация по стандартизации: вопросы стандартизации во всех областях, кроме электротехники и электроники 1881 г. – Международная электротехническая комиссия: вопросы стандартизации в области электротехники и электроники, радиосвязи и приборостроения 1987 г. – Объединенный технический комитет: объединенная деятельность ИСО и МЭК Российские организации: Государственный комитет РФ по стандартизации: федеральный орган исполнительной власти, осуществляющий межотраслевую координацию, а также функциональное регулирование в области стандартизации, метрологии и сертификации Технические комитеты по стандартизации: рабочие органы Государственного комитета РФ по стандартизации; специализируются в зависимости от объекта стандартизации Разработка стандартов International Organization for Standartization (ISO), International Electrotechnical Commission (IEC): стандарты ISO/IEC http://www.iso.org/iso/home.htm Руководство ISO/IEC рекомендует нормативные документы: Стандарты: нормативные документы, разработанные на основе консенсуса, утвержденные признанным органом, направленные на достижение оптимальной степени упорядочения в определенной области Документы технических условий: устанавливают технические требования к продукции, услуге, процессу Своды правил: разрабатываются для процессов проектирования, монтажа, технического сопровождения объектов, конструкций, изделий Регламенты: документ, содержащий обязательные правовые нормы ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» Процесс заказа. Определяет работы организации, которая приобретает систему, программный продукт или программную услугу. Процесс поставки. Определяет работы организации, которая поставляет систему, программный продукт или программную услугу. Процесс разработки. Определяет работы разработчика, то есть организации, которая проектирует и разрабатывает программный продукт. Процесс эксплуатации. Определяет работы организации, которая обеспечивает эксплуатационное обслуживание вычислительной системы в заданных условиях в интересах пользователей. Процесс сопровождения. Определяет работы организации, которая предоставляет услуги по сопровождению программного продукта, состоящие в контролируемом изменении программного продукта с целью сохранения его исходного состояния и функциональных возможностей. Данный процесс охватывает перенос и снятие с эксплуатации программного продукта. Российские стандарты Федеральный закон №184-ФЗ «О техническом регулировании» устанавливает правовые нормы: Стандартизация. Осуществляется в целях: технической и информационной совместимости; сопоставимости результатов исследований (испытаний) и измерений, технических и экономико-статистических данных; взаимозаменяемости продукции. Технические регламенты. Технические регламенты с учетом степени риска причинения вреда устанавливают минимально необходимые требования, обеспечивающие безопасность работ. Подтверждение соответствия. Удостоверение соответствия продукции, процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, работ, услуг или иных объектов техническим регламентам, стандартам, условиям договоров. Аккредитация органов по сертификации и испытательных лабораторий (центров). Подтверждение компетентности органов по сертификации и испытательных лабораторий (центров), выполняющих работы по подтверждению соответствия. Государственный контроль (надзор) за соблюдением требований технических регламентов. Информация о нарушении требований технических регламентов и отзыв продукции. Информация о технических регламентах и документах по стандартизации. Финансирование в области технического регулирования. Классификация стандартов ЕСПД ГОСТ 19.001-77 «Единая система программной документации»
Классификация Пакетов Прикладных Программ
Жизненный цикл программного средства Каскадная модель (70-е гг.) Формирование требований к ПС Проектирование Реализация Тестирование Ввод в эксплуатацию Эксплуатация и сопровождение Плюсы модели На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности Логичная последовательность этапов работ позволяет планировать сроки завершения всех работ и затраты Минусы модели Реальный процесс не укладывается в жесткую схему Существенное отставание от графика из-за согласований с пользователем только в контрольных точках Фиксированное ТЗ на все время проекта Функциональная и информационная модели автоматизируемого объекта могут устареть одновременно со сдачей проекта Жизненный цикл программного средства Модифицированная каскадная модель (80-е гг.) Формирование требований к ПС Проектирование Реализация Тестирование Ввод в эксплуатацию Эксплуатация и сопровождение Функциональная и информационная модели автоматизируемого объекта могут устареть одновременно со сдачей проекта Жизненный цикл программного средства Спиральная модель (90-е гг.) Определение требований к ПС Проектирование системной архитектуры Реализация и тестирование Интеграция Основная проблема – определение момента перехода на следующий этап ВЕРСИЯ Сопровождение ПС Снятие с эксплуатации Этапы моделей жизненных циклов ПС
Качество программного средства ГОСТ Р ИСО/МЭК 9126-93
Качество ПС – характеристики ПС, характеризующие их способность удовлетворять потребности пользователя Модель процесса оценки качества ПС Качество ПС характеристики ПС, характеризующие их способность удовлетворять потребности пользователя Надежность ПС способность ПС сохранять качество функционала в течение периода эксплуатации ПС Метрика качества ПС количественный метод, который может быть применен для определения значения характеристики ПС Уровень ранжирования диапазон значений, позволяющий классифицировать ПС в соответствии с установленными потребностями. Ранжирование выполняется на уровнях пользователь- руководитель-разработчик Критерии оценки качества ПС комплекс задокументированных критериев, используемый как основание для принятия решений о приемлемости качества ПС Модель процесса оценки качества ПС Потребности пользователя Определение требований к качеству Разработка ПО Выбор метрик Определение уровня ранжирования Определение критерия оценки Спецификация требований качества Административные требования Измерения Ранжирование Оценка Результат Уровни ранжирования ПС Уровень пользователей Интерес – область применения ПС, функционал ПС, производительность ПС. Оценка ПС – без изучения внутренних аспектов, программного кода и т.п. Уровень разработчика Заинтересованы в качестве промежуточной продукции так же, как в качестве конечного продукта. Согласно ЖЦ ПС, для одних и тех же характеристик ПС, но на разных этапах, используются различные метрики качества ПС Уровень руководителя Интерес – в общем качестве ПС, а не в отдельной характеристике. Оценка ПС – по критериям управляемости (плановая задержка, перерасход стоимости проекта и т.п.) в границах имеющихся ресурсов Передача разработки в аутсорсинг, на основе субподрядных договоров Планирование работ по разработке ПС Поставщик ПС – организация, заключившая договор с заказчиком на поставку ПП на условиях, оговоренных в договоре Заказчик ПС – организация, приобретающая ПП от поставщика Анализ требований к заказу с целью формирования структуры управления проектом и обеспечения необходимого качества ПС Выбор модели ЖЦ ПС. В модели ЖЦ выбрать и структурировать процессы, работы и задачи Сформулировать требования к планам реализации проекта согласно задач заказчика и обеспеченности ресурсами Анализ вариантов Разработка с применением ресурсов поставщика Приобретение готовых программных решений План управления проектом Содержание документа «Управление проектом по разработке ПС» Организационная структура проекта. Полномочия и обязанности участников проекта Среда разработки, эксплуатации и сопровождения ПС. Тестовые испытания, архивы, стандарты, процедуры, инструментарий Распределение заданий по процессам и работам ЖЦ согласно смет, составов исполнителей и графиков выполнения работ Критерии оценки качества ПП. Планы по обеспечению качества Управление безопасностью, защитой и другими критическими требованиями к ПП. Паны по обеспечению безопасности и защиты Управление субподрядчиками Верификация и аттестация ПП График совместной работы с заказчиком над проектом Управление критическими точками проекта (потенциальные технические, финансовые и иные затруднения в реализации проекта) Вопросы прав собственности, использования и распространения ПП Обучение персонала Квалификационные испытания ПС ГОСТ Р ИСО/МЭК 12119-2000 Квалификационное испытание (qualification testing) – тестирование ПС, проводимое разработчиком для демонстрации того, что ПП удовлетворяет установленным требованиям и готов к использованию в среде эксплуатации. Результат квалификационных испытаний документально оформляется. Цели работ Установить, что реализация каждого требования к ИС соответствует установленным значениям, а система готова к поставке. Установить, что:
система готова к эксплуатации и сопровождению Выполнить аудиторскую проверку ИС, т.е. установить соответствие ИС целям, планам и условиям Договора на разработку ПС Определить, по необходимости, состав и сроки выполнения работ по доработке ПС Для тестирования ППП должны иметься в наличии все его поставляемые компоненты, а также нормативные документы, указанные в описании ПП. Если в описании продукта указана необходимость обучения работе с системой, тестировщик должен иметь доступ к учебным материалам и обучающим программам. Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста. Этапы тестовых испытаний ПС I. Описание продукта (структура документа) Описание ПП должно быть понятным, полным и простым Описанию продукта д.б. присвоено индивидуальное обозначение как документу («Описание функциональных возможностей», «Формуляр продукта» и т.п. Описание продукта должно определять продукт, - обозначение продукта должно включать наименование продукта, версию, дату выпуска и др. характеристики Описание продукта должно содержать наименование и адрес по крайней мере одного поставщика В описании продукта д.б. определены целевые рабочие задачи, которые могут выполнены продуктом В описании продукта д.б. ссылки на нормативные документы (ГОСТы), которым удовлетворяет продукт В описании д.б. определена система (технические и программные средства и их конфигурация), необходимая для ввода продукта в эксплуатацию (процессоры, сопроцессоры, объемы памяти, расширяющие платы, периферийное и сетевое оборудование, системные и др. ПС) В описании д.б. определены все используемые интерфейсы, как внутрисистемные, так и межкомпонентные В описании д.б. определен каждый физический компонент ПС (все печатные документы и носители данных) В описании д.б. указано, кем будет выполнена инсталляция продукта, а также будет ли продукт поставлен на сопровождение исполнителем В описании д.б. приведен обзор функционала продукта, в т.ч. по процедурам сохранения данных и криптозащите … и другие данные согласно ГОСТ Р ИСО/МЭК 12119-2000 Этапы тестовых испытаний ПС II. Документация пользователя (структура документа) В документации пользователя должен быть исчерпывающе описан функционал системы: Полнота: граничные значения ПС, заданные в описании ПС, д.б. продублированы в документации пользователя инструкция по инсталляции в случае, когда ПП допускает установку пользователем, включая размеры устанавливаемых файлов, дерево директорий с указанием назначения системных, служебных, пользовательских файлов, файлов БД и т.п. Правильность: документация не должна содержать неоднозначных толкований и ошибок Непротиворечивость: каждый термин должен иметь одно и то же определение во всем пакете документов Понятность: документация д.б. понятна в среде эксплуатации ПС Простота изучения: документация д.б. снабжена оглавлением, предметным указателем, в случае поставки на электронном носителе – понятной процедурой распечатки и т.д. Этапы тестовых испытаний ПС III. Программы и данные (структура документа) Функционал: инсталляция, контрольные примеры и самотестирование реализация функций, - функционал, определенный в ТЗ и документации пользователя, должен выполняться в утвержденном заказчиком виде, в рамках граничных значений, установленных в документации пользователя правильность, - функционал должен выполняться методами, утвержденными в рабочей задаче; программы и данные должны соответствовать требованиям нормативных документов (ГОСТов) непротиворечивость, - данные не должны противоречить сами себе, а также описанию продукта и документации пользователя Надежность. ПС не должно приходить в состояние, когда пользователь не может его контролировать, а данные не должны повреждаться либо теряться. В частности, ПС должно обнаруживать нарушения синтаксических правил для исходных данных и не должно обрабатывать ошибочные исходные данные как допустимые исходные данные Практичность: понятность, простота обозрения, простота использования Содержание документа «Отчет о тестировании ПС» Обозначение продукта Вычислительные системы, использованные при тестировании (технические средства, программные средства и их конфигурация) Использованные документы Результаты тестирования документации пользователя, программ и данных Перечень несоответствия требованиям Перечень несоответствия рекомендациям либо формулировка того, что ПП не был протестирован на соответствие рекомендациям Дата окончания тестовых испытаний Когда ПП тестируется повторно, все измененные части документов, функций и данных, а также части, на которые они могут влиять, тестируются как новый продукт. Все другие части ПС тестируются выборочно. Средства тестирования Тестирование – процесс исполнения программы с целью обнаружения ошибок Регрессивное тестирование – процесс повторного тестирования после внесения изменений в ПС QA (Quality Works) – интегрированная многоплатформенная среда (Windows, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris) для разработки автоматизированных тестов любого уровня, в т.ч. регрессивные тесты, для приложений с графическим интерфейсом пользователя. Тестирование возможно начать на любом этапе ЖЦ, планировать, управлять процессом тестирования, отображать изменения в приложении и повторно применять тесты. QA Partner – среда разработки, компиляции и выполнения тестов QA Planner – модуль разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner Agent – модуль, поддерживающий работу в сети QA: привязка к ЖЦ Создание плана тестирования Соотнесение плана с тестами Пометка и выполнение тестов Получение отчетов о тестировании и управление результатами Составление схемы тестовых требований и выделение уровней детализации: функциональная декомпозиция ПС – сколько и каких тестов необходимо для каждой функции и характеристики Создание управляющих предложений (скриптов) на языке 4Test и тесты, выполняющие требования плана Все результаты тестирования связаны с планом: просмотр информации о выполнении, объединение файлов результатов, разметка неудавшихся тестов, сравнение результатов с предыдущим тестированием и т.д. |