- •Оглавление
- •Глава 1. Жизненный цикл программного обеспечения ……………………………………………43
- •Глава 2. Методические аспекты
- •Глава 3. Моделирование бизнес-процессов
- •Глава 4. Анализ и проектирование
- •Глава 5. Технологии создания программного
- •Глава 6. Оценка трудоемкости создания
- •Глава 7. Особенности современных проектов ........527
- •Предисловие
- •Введение
- •Глава 1 жизненный цикл программного обеспечения
- •Нормативно-методическое обеспечение создания по
- •Стандарт жизненного цикла по
- •Основные процессы жц по
- •Вспомогательные процессы жизненного цикла по
- •Организационные процессы жизненного цикла по
- •Взаимосвязь между процессами жц по
- •Модели жизненного цикла по
- •Каскадная модель жц
- •Итерационная модель жизненного цикла
- •Методика spmn
- •Пример процесса «управление требованиями»
- •Пример процесса «управление конфигурацией по»
- •Общие принципы проектирования систем
- •Визуальное моделирование
- •Структурные методы анализа и проектирования по
- •Метод функционального моделирования
- •Описание типов связей
- •Моделирования процессов idef3
- •Типы связей idef3
- •Типы соединений
- •Моделирование потоков данных
- •Количественный анализ диаграмм
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Моделирование данных
- •Объектно-ориентированные методы анализа и проектирования по
- •Основные принципы построения объектной модели
- •Основные элементы объектной модели
- •Значения мощности
- •Унифицированный язык моделирования uml
- •Диаграммы вариантов использования
- •Диаграммы взаимодействия
- •Диаграммы классов
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •Диаграммы размещения
- •Механизмы расширения uml
- •Количественный анализ диаграмм uml
- •Основные элементы языка uml
- •Основные типы связей языка uml
- •Диапазоны оценок для диаграмм uml
- •Образцы
- •Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
- •Структурный (процессный) подход к моделированию бизнес-процессов
- •Принципы процессного подхода
- •Применение диаграмм потоков данных
- •Система моделирования aris
- •Метод ericsson-penker21
- •Пример использвания процессного подхода
- •История болезни пациента
- •Спецификация структур данных
- •Построение диаграмм потоков данных нулевого и последующих уровней
- •Объектно-ориентированный подход к моделированию бизнес-процессов
- •Методика моделирования
- •Пример использования объектно-ориентированного подхода
- •Пример спецификации требований к программному обеспечению
- •Пример структурного проектирования по
- •Построение диаграмм системных процессов и диаграмм последовательностей экранных форм
- •Объектно-ориентированный анализ
- •Архитектурный анализ
- •Анализ вариантов использования
- •Объектно-ориентированное проектирование
- •Проектирование архитектуры системы
- •Проектирование элементов системы
- •Глава 5 технологии создания программного обеспечения
- •Определение технологии
- •Общие требования, предъявляемые
- •Внедрение тс по в организации
- •Общие сведения
- •Определение потребностей в тс по
- •Оценка и выбор тс по
- •Критерии оценки и выбора тс по
- •Выполнение пилотного проекта
- •Практическое внедрение тс по
- •Примеры тс по
- •Технология rup (rational unified process)
- •Технология oracle
- •Технология borland
- •Технология computer associates
- •Глава 6 оценка трудоемкости создания программного обеспечения
- •Методы оценки и их классификация
- •Методика оценки трудоемкости разработки по на основе функциональных точек
- •Определение функциональных типов
- •Определение количества и сложности функциональных типов по данным
- •Сложность ilf и eif
- •Определение количества и сложности транзакционных функциональных типов
- •Подсчет количества функциональных точек
- •Зависимость количества fp от сложности функционального типа
- •Коммуникации данных
- •Распределенная обработка данных
- •Сложность ei
- •Сложность ео
- •Производительность
- •Эксплуатационные ограничения
- •Частота транзакций
- •Ввод данных в режиме «онлайн»
- •Эффективность работы конечных пользователей1
- •Онлайновое обновление
- •Сложная обработка31
- •Повторное использование
- •Простота установки
- •Простота эксплуатации
- •Количество возможных установок на различных платформах
- •Гибкость32
- •Оценка трудоемкости разработки
- •Размер программного обеспечения в fp и loc
- •Распределение временных затрат по стадиям для маленьких и больших проектов
- •Статистические данные
- •Статистические (регрессионные) модели
- •Группа процессов
- •Определение весовых показателей вариантов использования
- •Определение технической сложности проекта
- •Определение уровня квалификации разработчиков
- •Оценка трудоемкости проекта
- •Методы, основанные на экспертных оценках
- •Метод дельфи
- •Метод декомпозиции работ
- •Средства оценки трудоемкости
- •Планирование итерационного процесса создания по
- •Глава 7 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Вспомогательные процессы жизненного цикла по
Процесс документирования (documentation process) предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких, как руководство, технические специалисты и пользователи системы.
Процесс документирования включает следующие действия:
1) подготовительную работу;
2) проектирование и разработку;
3) выпуск документации;
4) сопровождение.
Процесс управления конфигурацией (configuration management process) предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Процесс управления конфигурацией включает следующие действия;
1) подготовительную работу;
2) идентификацию конфигурации;
3) контроль за конфигурацией;
4) учет состояния конфигурации;
5) оценку конфигурации;
6) управление выпуском и поставку.
Подготовительная работа заключается в планировании управления конфигурацией.
Идентификация конфигурации устанавливает правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПО и их версии. Кроме того, каждому компоненту и его версиям соответствует однозначно обозначаемый комплект документации. В результате создается база для однозначного выбора и манипулирования версиями компонентов ПО, использующая ограниченную и упорядоченную систему символов, идентифицирующих различные версии ПО.
Контроль за конфигурацией предназначен для систематической оценки предполагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение. Он обеспечивает контроль за состоянием и развитием компонентов ПО и их версий, а также адекватность реально изменяющихся компонентов и их комплектной документации.
Учет состояния конфигурации представляет собой регистрацию состояния компонентов ПО, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПО. Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций.
Оценка конфигурации заключается в оценке функциональной полноты компонентов ПО, а также соответствия их физического состояния текущему техническому описанию.
Управление выпуском и поставка охватывают изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятым в организации.
Процесс обеспечения качества (quality assurance process) обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПО понимается совокупность свойств, которые характеризуют способность ПО удовлетворять заданным требованиям.
Для получения достоверных оценок создаваемого ПО процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПО. При этом могут использоваться результаты других вспомогательных процессов, таких, как верификация, аттестация, совместная оценка, аудит и разрешение проблем.
Процесс обеспечения качества включает следующие действия:
1) подготовительную работу;
2) обеспечение качества продукта;
3) обеспечение качества процесса;
4) обеспечение прочих показателей качества системы.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании самого процесса обеспечения качества с учетом используемых стандартов, методов, процедур и средств.
Обеспечение качества продукта подразумевает гарантирование полного соответствия программных продуктов и их документации требованиям заказчика, предусмотренным в договоре.
Обеспечение качества процесса предполагает гарантирование соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам.
Обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом качества ISO 9001.
Процесс верификации (verification process) состоит в определении того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями (верификация в узком смысле означает формальное доказательство правильности ПО). Для повышения эффективности верификация должна как можно раньше интегрироваться с использующими ее процессами (такими, как поставка, разработка, эксплуатация или сопровождение). Данный процесс может включать анализ, оценку и тестирование.
Верификация может проводиться с различными степенями независимости. Степень независимости может варьироваться от выполнения верификации самим исполнителем или другим специалистом данной организации до ее выполнения специалистом другой организации с различными вариациями. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой верификации.
Процесс верификации включает следующие действия:
1) подготовительную работу;
2) верификацию.
В процессе верификации проверяются следующие условия:
непротиворечивость требований к системе и степень учета потребностей пользователей;
возможности поставщика выполнить заданные требования;
соответствие выбранных процессов ЖЦ ПО условиям договора;
адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;
соответствие проектных спецификаций ПО заданным требованиям;
корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
соответствие кода проектным спецификациям и требованиям;
тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
корректность интеграции компонентов ПО в систему;
адекватность, полнота и непротиворечивость документации.
Процесс аттестации (validation process) предусматривает определение полноты соответствия заданных требований и созданной системы или программного продукта их конкретному функциональному назначению. Под аттестацией обычно понимается подтверждение и оценка достоверности проведенного тестирования ПО. Аттестация должна гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестацию рекомендуется выполнять путем тестирования во всех возможных ситуациях и использовать при этом независимых специалистов. Аттестация может проводиться на начальных стадиях ЖЦ ПО или как часть работы по приемке ПО.
Аттестация, так же как и верификация, может осуществляться с различными степенями независимости. Если процесс аттестации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой аттестации.
Процесс аттестации включает следующие действия:
1) подготовительную работу;
2) аттестацию.
Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и ПО, создаваемому при выполнении данных работ (действий). Он сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.
Оценка применяется как на уровне управления проектом, так и на уровне технической реализации проекта и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую.
Процесс совместной оценки включает следующие действия:
1) подготовительную работу;
2) оценку управления проектом;
3) техническую оценку.
Процесс аудита (audit process) представляет собой определение соответствия требованиям, планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую.
Аудит — это ревизия (проверка), проводимая компетентным органом (лицом) в целях обеспечения независимой оценки степени соответствия ПО или процессов установленным требованиям. Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы (ревизоры) не должны иметь прямой зависимости от разработчиков ПО. Они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования.
Процесс аудита включает следующие действия:
1) подготовительную работу;
2) аудит.
Процесс разрешения проблем (problem resolution process) предусматривает анализ и решение проблем (включая обнаруженные несоответствия), независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена.
Процесс разрешения проблем включает следующие действия:
1) подготовительную работу;
2) разрешение проблем.
1.2.3.
