ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9473
Скачиваний: 184
Таблица
1.1
Традиционная
разработка
Разработка
с
использованием
CASE -
средств
Основные
усилия
на
кодирование
и
тестирование
«
Бумажные
»
спецификации
Ручное
кодирование
Ручное
документирование
Тестирование
кодов
Сопровождение
кодов
Основные
усилия
на
анализ
и
проектирование
Быстрое
итерационное
прототипирование
Автоматическая
генерация
кодов
Автоматическая
генерация
документации
Автоматический
контроль
проекта
Сопровождение
спецификаций
проектирования
Таблица
1.2
Трудозатраты
этапа
разработки
, %
Способ
разработки
Анализ
Проектирование
Кодирование
Тестирование
Традиционная
разработка
Структурный
подход
CASE-
технологий
20
30
40
15
30
40
20
15
5
45
25
15
1.6.
Ускорение
разработки
программного
обеспечения
.
Разработка
спиральной
модели
жизненного
цикла
программного
обеспечения
и
CASE-
технологий
позволили
сформулировать
условия
,
выполнение
которых
сокращает
сроки
создания
программного
обеспечения
.
Современная
технологии
проектирования
,
разработки
и
сопровождения
программного
обеспечения
,
должна
отвечать
следующим
требованиям
:
•
поддержка
полного
жизненного
цикла
программного
обеспечения
;
•
гарантированное
достижение
целей
разработки
с
заданным
качеством
и
в
установленное
время
;
•
возможность
выполнения
крупных
проектов
в
виде
подсистем
,
разрабатываемых
группами
исполнителей
ограниченной
численности
(3-7
человек
)
с
последующей
интеграцией
составных
частей
,
и
координации
ведения
общего
проекта
;
•
минимальное
время
получения
работоспособной
системы
;
•
возможность
управления
конфигурацией
проекта
,
ведения
версий
проекта
и
автоматического
выпуска
проектной
документации
по
каждой
версии
;
•
независимость
выполняемых
проектных
решений
от
средств
реализации
(
СУБД
,
операционных
систем
,
языков
и
систем
программирования
);
•
поддержка
комплексом
согласованных
CASE-
средств
,
обеспечивающих
автоматизацию
процессов
,
выполняемых
на
всех
стадиях
жизненного
цикла
.
Этим
требованиям
отвечает
технология
RAD (Rapid Application Development -
Быстрая
разработка
приложений
).
Эта
технология
ориентирована
,
как
следует
из
названия
,
на
максимально
быстрое
получение
первых
версий
разрабатываемого
программного
обеспечения
.
Она
предусматривает
выполнение
следующих
условий
:
•
ведение
разработки
небольшими
группами
разработчиков
(3-7
человек
),
каждая
из
которых
проектирует
и
реализует
отдельные
подсистемы
проекта
-
позволяет
улучшить
управляемость
проекта
;
•
использование
итерационного
подхода
способствует
уменьшению
времени
получения
работоспособного
прототипа
;
•
наличие
четко
проработанного
графика
цикла
,
рассчитанного
не
более
чем
на
три
месяца
,
существенно
увеличивает
эффективность
работы
.
Процесс
разработки
при
этом
делится
на
следующие
этапы
:
анализ
и
планирование
требований
пользователей
,
проектирование
,
реализация
,
внедрение
.
На
этапе
анализа
и
планирования
требований
формулируют
наиболее
приоритетные
требования
,
что
ограничивает
масштаб
проекта
.
На
этапе
проектирования
,
используя
имеющиеся
CASE-
средства
,
детально
описывают
процессы
системы
,
устанавливают
требования
разграничения
доступа
к
данным
и
определяют
состав
необходимой
документации
.
При
этом
для
наиболее
сложных
процессов
создают
частичный
прототип
:
разрабатывают
экранную
форму
и
диалог
.
По
результатам
анализа
процессов
определяют
количество
так
называемых
функциональных
точек
и
принимают
решение
о
количестве
подсистем
и
,
соответственно
,
команд
,
участвующих
в
разработке
.
Под
функциональной
точкой
в
технологии
RAD
понимают
любой
из
следующих
функциональных
элементов
разрабатываемой
системы
:
•
входной
элемент
приложения
(
входной
документ
или
экранная
форма
);
•
выходной
элемент
приложения
(
отчет
,
документ
или
экранная
форма
);
•
запрос
(
пара
«
вопрос
/
ответ
»);
•
логический
файл
(
совокупность
записей
данных
,
используемых
внутри
приложения
);
•
интерфейс
приложения
(
совокупность
записей
данных
,
передаваемых
другому
приложению
или
получаемых
от
него
).
Нормы
,
рассчитанные
исходя
из
экспертных
оценок
,
для
систем
со
значительной
повторяемостью
кодов
определяются
следующим
образом
:
•
менее
1
тыс
.
функциональных
точек
- 1
человек
;
•
от
1
до
4
тыс
.
функциональных
точек
-
одна
команда
разработчиков
;
•
более
4
тыс
.
функциональных
точек
-
одна
команда
на
каждые
4
тыс
.
точек
.
В
соответствии
с
этими
нормами
разрабатываемую
систему
делят
на
подсистемы
,
слабо
связанные
по
данным
и
функциям
,
и
точно
определяют
интерфейсы
между
различными
частями
.
Использование
CASE-
средств
при
этом
позволяет
избежать
неконтролируемого
искажения
данных
при
передаче
информации
о
проекте
со
стадии
на
стадию
.
Далее
разработка
ведется
группами
разработчиков
,
которые
продолжают
прорабатывать
свои
части
системы
.
Действия
различных
групп
разработчиков
при
этом
должны
быть
хорошо
скоординированы
.
На
этапе
реализации
выполняют
итеративное
построение
реальной
системы
,
причем
при
этом
для
контроля
над
выполнением
требований
к
создаваемой
системе
привлекаются
будущие
пользователи
.
Части
постепенно
интегрируют
в
систему
,
причем
при
подключении
каждой
части
выполняют
тестирование
.
На
завершающих
этапах
разработки
определяют
необходимость
создания
соответствующих
баз
данных
,
которые
разрабатываются
и
подключаются
к
системе
.
Далее
формулируют
требования
к
аппаратным
средствам
,
устанавливают
способы
увеличения
произво
-
дительности
и
завершают
подготовку
документации
по
проекту
.
На
этапе
внедрения
проводят
обучение
пользователей
и
осуществляют
постепенный
переход
на
новую
систему
,
причем
эксплуатация
старой
версии
продолжается
до
полного
внедрения
новой
системы
.
Технология
RAD
хорошо
зарекомендовала
себя
для
относительно
небольших
проектов
,
разрабатываемых
для
конкретного
заказчика
.
Такие
системы
не
требуют
высокого
уровня
планирования
и
жесткой
дисциплины
проектирования
.
Однако
эта
технология
не
применима
для
построения
сложных
расчетных
программ
,
операционных
систем
или
программ
управления
слож
-
ными
объектами
в
реальном
масштабе
времени
,
т
.
е
.
программ
с
большим
процентом
уникального
кода
.
Не
годится
она
и
в
случае
создания
приложений
,
от
которых
зависит
безопасность
людей
,
например
,
систем
управления
самолетами
или
атомными
электростанциями
,
так
как
технология
RAD
предполагает
,
что
первые
несколько
версий
не
будут
полностью
работоспособны
,
что
в
данном
случае
полностью
исключается
.
1.7.
Оценка
качества
процессов
создания
программного
обеспечения
Как
уже
упоминалось
выше
,
текущий
период
на
рынке
программного
обеспечения
характеризуется
переходом
от
штучного
ремесленного
производства
программных
продуктов
к
их
промышленном
}-
созданию
.
Соответственно
возросли
требования
к
качеству
разрабатываемого
программного
обеспечения
,
что
требует
совершенствования
процессов
их
разработки
.
На
настоящий
момент
существует
несколько
стандартов
,
связанных
с
оценкой
качества
этих
процессов
,
которое
обеспечивает
организация
-
разработчик
.
К
наиболее
известным
относят
:
•
международные
стандарты
серии
ISO 9000 (ISO 9000 - ISO 9004);
•
СММ
- Capability Maturity Model -
модель
зрелости
(
совершенствования
)
процессов
создания
программного
обеспечения
,
предложенная
SEI (Software Engineering Institute -
институт
программирования
при
университете
Карнеги
-
Меллон
);
•
рабочая
версия
международного
стандарта
ISO/IEC 15504: Information Technology - Software
Process Assessment;
эта
версия
более
известна
под
названием
SPICE - (Software Process
Improvement and Capability dEtermination -
определение
возможностей
и
улучшение
процесса
создания
программного
обеспечения
).
Серия
стандартов
ISO 9000.
В
серии
ISO 9000
сформулированы
необходимые
условия
для
достижения
некоторого
минимального
уровня
организации
процесса
,
но
не
дается
никаких
рекомендаций
по
дальнейшему
совершенствованию
процессов
.
СММ
.
СММ
представляет
собой
совокупность
критериев
оценки
зрелости
организации
-
разработчика
и
рецептов
улучшения
существующих
процессов
.
Примечание
.
Изначально
СММ
разрабатывалась
и
развивалась
как
методика
,
позволяющая
крупным
правительственным
организациям
США
выбирать
наилучших
поставщиков
программного
обеспечения
.
Для
этого
предполагалось
создать
исчерпывающее
описание
способов
оценки
процессов
разработки
программного
обеспечения
и
методики
их
дальнейшего
усовершенствования
.
В
итоге
авторы
смогли
добиться
такой
степени
подробности
и
детализации
,
что
стандарт
оказался
пригодным
и
для
обычных
компаний
-
разработчиков
,
желающих
качественно
улучшить
существующие
процессы
разработки
,
привести
их
к
определенным
стандартам
.
СММ
определяет
пять
уровней
зрелости
организаций
-
разработчиков
,
причем
каждый
следующий
уровень
включает
в
себя
все
ключевые
характеристики
предыдущих
.
1.
Начальный
уровень
(initial level)-
описан
в
стандарте
в
качестве
основы
для
сравнения
со
следующими
уровнями
.
На
предприятии
такого
уровня
организации
не
существует
стабильных
условий
для
создания
качественного
программного
обеспечения
.
Результат
любого
проекта
целиком
и
полностью
зависит
от
личных
качеств
менеджера
и
опыта
программистов
,
причем
успех
в
одном
проекте
может
быть
повторен
только
в
случае
назначения
тех
же
менеджеров
и
программистов
на
следующий
проект
.
Более
того
,
если
эти
менеджеры
или
программисты
уходят
с
предприятия
,
то
резко
снижается
качество
производимых
программных
продуктов
.
В
стрессовых
ситуациях
процесс
разработки
сводится
к
написанию
кода
и
его
минимальному
тестированию
.
2.
Повторяемый
уровень
(repeatable level) -
на
предприятии
внедрены
технологии
управления
проектами
.
При
этом
планирование
и
управление
проектами
основывается
на
накопленном
опыте
,
существуют
стандарты
на
разрабатываемое
программное
обеспечение
(
причем
обеспечивается
следование
этим
стандартам
)
и
специальная
группа
обеспечения
качества
.
В
случае
необходимости
организация
может
взаимодействовать
с
субподрядчиками
.
В
критических
условиях
процесс
имеет
тенденцию
скатываться
на
начальный
уровень
.
3.
Определенный
уровень
(defined level) -
характеризуется
тем
,
что
стандартный
процесс
создания
и
сопровождения
программного
обеспечения
полностью
документирован
(
включая
и
разработку
ПО
,
и
управление
проектами
).
Подразумевается
,
что
в
процессе
стандартизации
происходит
переход
на
наиболее
эффективные
практики
и
технологии
.
Для
создания
и
поддержания
подобного
стандарта
в
организации
должна
быть
создана
специальная
группа
.
Наконец
,
обязательным
условием
для
достижения
данного
уровня
является
наличие
на
предприятии
программы
постоянного
повышения
квалификации
и
обучения
сотрудников
.
Начиная
с
этого
уровня
,
организация
перестает
зависеть
от
качеств
конкретных
разработчиков
,
и
процесс
не
имеет
тенденции
скатываться
на
уровень
ниже
в
стрессовых
ситуациях
.
4.
Управляемый
уровень
(managed level) -
в
организации
устанавливаются
количественные
показатели
качества
,
как
на
программные
продукты
,
так
и
на
процесс
в
целом
.
Таким
образом
,
более
совершенное
управление
проектами
достигается
за
счет
уменьшения
отклонений
различных
показателей
проекта
.
При
этом
осмысленные
вариации
в
производительности
процесса
можно
отличить
от
случайных
вариаций
(
шума
),
особенно
в
хорошо
освоенных
областях
.
5.
Оптимизирующий
уровень
(optimizing level) -
характеризуется
тем
,
что
мероприятия
по
улучшению
применяются
не
только
к
существующим
процессам
,
но
и
для
оценки
эффективности
ввода
новых
технологий
.
Основной
задачей
всей
организации
на
этом
уровне
является
постоянное
улучшение
существующих
процессов
.
При
этом
улучшение
процессов
в
идеале
должно
помогать
предупреждать
возможные
ошибки
или
дефекты
.
Кроме
того
,
должны
вестись
работы
по
уменьшению
стоимости
разработки
программного
обеспечения
,
например
с
помощью
создания
и
повторного
использования
компонентов
.
Сертификационная
оценка
соответствия
всех
ключевых
областей
проводится
по
10-
балльной
шкале
.
Для
успешной
квалификации
данной
ключевой
области
необходимо
набрать
не
менее
6
баллов
.
Оценка
ключевой
области
осуществляется
по
следующим
показателям
:
•
заинтересованность
руководства
в
данной
области
,
например
,
планируется
ли
практическое
внедрение
данной
ключевой
области
,
существует
ли
понимание
у
руководства
необходимости
данной
области
и
т
.
д
.;
•
насколько
широко
данная
область
применяется
в
организации
,
например
,
оценке
в
4
балла
соответствует
фрагментарное
применение
;
•
успешность
использования
данной
области
на
практике
,
например
,
оценке
в
0
баллов
соответствует
полное
отсутствие
какого
-
либо
эффекта
,
а
оценка
в
8
баллов
выставляется
при
наличии
систематического
и
измеримого
положительного
результата
практически
во
всей
организации
.
В
принципе
,
можно
сертифицировать
только
один
процесс
или
подразделение
организации
,
например
,
подразделение
разработки
программного
обеспечения
компании
IBM
сертифицировано
на
пятый
уровень
.
Кстати
,
в
мире
существует
совсем
немного
компаний
,
которые
могут
похвастаться
наличием
у
них
пятого
уровня
СММ
хотя
бы
в
одном
из
подразделений
-
таких
всего
около
50-
ти
.
С
другой
стороны
,
насчитывается
несколько
тысяч
компаний
,
сертифицированных
по
третьему
или
четвертому
уровням
,
т
.
е
.
существует
колоссальный
разрыв
между
оптимизированным
уровнем
зрелости
и
предыдущими
уровнями
.
Однако
еще
больший
разрыв
наблюдается
между
количеством
организаций
начального
уровня
и
числом
их
более
продвинутых
собратьев
-
по
некоторым
оценкам
,
свыше
70 %
всех
компаний
-
разработчиков
находится
на
первом
уровне
СММ
[3].
SPICE.
Стандарт
SPICE
унаследовал
многие
черты
более
ранних
стандартов
,
в
том
числе
и
уже
упоминавшихся
ISO 9001
и
СММ
.
Больше
всего
SPICE
напоминает
СММ
.
Точно
так
же
,
как
и
в
СММ
,
основной
задачей
организации
является
постоянное
улучшение
процесса
разработки
программного
обеспечения
.
Кроме
того
,
в
SPICE
тоже
используется
схема
с
различными
уровнями
возможностей
(
в
SPICE
определено
6
различных
уровней
),
но
эти
уровни
применяются
не
только
к
организации
в
целом
,
но
и
к
отдельно
взятым
процессам
.
В
основе
стандарта
лежит
оценка
процессов
.
Эта
оценка
выполняется
путем
сравнения
процесса
разработки
программного
обеспечения
,
существующего
в
данной
организации
,
с
описанной
в
стандарте
моделью
.
Анализ
результатов
,
полученных
на
этом
этапе
,
помогает
определить
сильные
и
слабые
стороны
процесса
,
а
также
внутренние
риски
,
присущие
данному
процессу
.
Это
помогает
оценить
эффективность
процессов
,
определить
причины
ухудшения
качества
и
связанные
с
этим
издержки
во
времени
или
стоимости
.
Затем
выполняется
определение
возможностей
процесса
,
т
.
е
.
возможностей
его
улучшения
.
В
результате
в
организации
может
появиться
понимание
необходимости
улучшения
того
или
иного
процесса
.
К
этому
моменту
цели
совершенствования
процесса
уже
четко
сформулированы
и
остается
только
техническая
реализация
поставленных
задач
.
После
этого
весь
цикл
работ
начинается
сначала
.
Безусловно
,
совершенствование
процессов
жизненного
цикла
программного
обеспечения
абсолютно
необходимо
.
Однако
следует
иметь
в
виду
,
что
построение
«
более
зрелого
»
процесса
разработки
не
обязательно
обеспечивает
создание
более
качественного
программного
обеспечения
.
Это
хотя
и
связанные
,
но
совершенно
различные
процессы
.
Использование
формальных
моделей
и
методов
позволяет
создавать
понятные
,
непротиворечивые
спецификации
на
разрабатываемое
программное
обеспечение
.
Конечно
,
внедрение
таких
методов
имеет
смысл
,
хотя
оно
весьма
дорого
и
трудоемко
,
а
возможности
их
применения
весьма
ограничены
.
Основная
же
проблема
-
проблема
сложности
разрабатываемого
программного
обеспечения
с
совершенствованием
процессов
разработки
пока
не
разрешена
.
Создание
программного
обеспечения
по
-
прежнему
предъявляет
повышенные
требования
к
квалификации
тех
,
кто
этим
занимается
:
проектировщикам
программного
обеспечения
и
непосредственно
программистам
.
Контрольные
вопросы
1.
Что
понимают
под
термином
«
технология
программирования
»?
2.
Что
называют
подходом
и
чем
подход
отличается
от
метода
?
3.
Назовите
основные
периоды
истории
развития
технологии
программирования
.
Чем
характеризуются
эти
периоды
?
Как
изменялись
основные
подходы
и
используемые
средства
?
4.
Дайте
определение
понятию
«
сложная
иерархическая
система
».
Какой
подход
используют
при
разработке
таких
систем
?
На
каких
характеристиках
этих
систем
он
основан
?
В
чем
особенность
данного
подхода
при
разработке
программного
обеспечения
?
5.
Что
понимают
под
термином
«
жизненный
цикл
программного
обеспечения
»?
Какие
основные
процессы
включают
в
это
понятие
?
6.
Назовите
основные
этапы
разработки
программного
обеспечения
.
Какие
основные
задачи
решаются
на
этих
этапах
?
7.
Назовите
основные
модели
жизненного
цикла
программного
обеспечения
.
С
чем
связано
появление
новых
моделей
?
8.
Какие
технологии
называют
CASE-
технологиями
?
Почему
?
9.
Назовите
основные
составляющие
любой
CASE-
технологии
.
10.
Перечислите
основные
положения
технологии
RAD?
Какие
программные
системы
нельзя
разрабатывать
с
использованием
этой
технологии
?
11.
Что
понимают
под
моделями
качества
процессов
разработки
программного
обеспечения
?
Для
чего
они
разработаны
?
Что
гарантирует
сертификация
качества
процессов
?
Почему
?
12.
Почему
мы
говорим
,
что
современный
этап
развития
технологии
программирования
характеризуется
переходом
от
ремесленного
к
промышленному
производству
программного
обеспечения
?