- •Оглавление
- •6 Тестирование 88
- •8.3 Организация разработки программного изделия 215
- •8.4 Организация обслуживания разработки программного изделия 230
- •8.5 Организация выпуска документации 239
- •8.6 Организация испытаний программных изделий 248
- •1 Введение. Проблемы современного программирования
- •2 Этапы разработки программного обеспечения
- •2.1 Анализ требований, предъявляемых к системе
- •2.2 Определение спецификаций
- •2.3 Проектирование
- •2.4 Кодирование
- •2.5 Тестирование
- •2.6 Эксплуатация и сопровождение
- •2) Определение спецификаций;
- •3) Проектирование;
- •4) Кодирование;
- •Контрольные вопросы
- •1. Этапы разработки программного обеспечения.
- •2. Анализ требований, предъявляемых к системе.
- •3 Методы разработки программного обеспечения как научная дисциплина
- •3.1 Методы управления разработкой
- •3.1.1 Выполнение проекта
- •3.1.2 Методика оценки затрат
- •3.1.2.1 Методика инженерно-технической оценки затрат
- •3.1.2.2 Оценка на основе распределения Рэлея
- •3.1.3 Контрольные точки
- •3.1.4 Средства разработки
- •3.1.5 Надежность
- •3.2 Методы проведения разработки программного обеспечения
- •3.3 Развитие методов разработки программного обеспечения
- •3.3.1 Язык определения задач и анализатор задач
- •3.3.2 Система структурного анализа и проектирования sadt
- •3.3.3 Система srem
- •3.3.4 Методика Джексона
- •3.4 Выводы
- •Контрольные вопросы
- •1. Методы разработки программного обеспечения как научная дисциплина.
- •4 Методы разработки программного обеспечения
- •4.1 Язык проектирования программ
- •4.2 Стратегия проектирования
- •4.2.1 Нисходящее проектирование и нисходящая разработка
- •4.2.2 Структурное проектирование
- •4.3 Данные
- •4.3.1 Обзор структур данных
- •4.3.1.1 Массивы
- •4.3.1.2 Структуры
- •4.3.1.3 Списки
- •4.3.1.4 Очереди
- •4.3.1.5 Стеки
- •4.3.1.6 Множества
- •4.3.1.7 Графы
- •4.3.1.8 Деревья
- •4.3.2 Абстрактные конструкции
- •4.3.2.1 Фиксированные типы данных абстрактного типа
- •4.3.2.2 Размещение указателей
- •4.3.2.3 Защита данных от несанкционированного доступа
- •Контрольные вопросы
- •2. Нисходящее проектирование и нисходящая разработка.
- •9. Абстрактные конструкции.
- •5 Правильность программ
- •5.1 Аксиомы
- •5.2 Правила преобразования данных
- •5.3 Доказательства правильности программ
- •Контрольные вопросы
- •1. Правильность программ.
- •6 Тестирование
- •6.1 Психология и экономика тестирования программ
- •6.2 Экономика тестирования
- •6.2.1 Тестирование программы как черного ящика
- •6.2.2 Тестирование программы как белого ящика
- •6.2.3 Принципы тестирования
- •6.3 Ручное тестирование
- •6.3.1 Инспекции и сквозные просмотры
- •6.3.2 Инспекции исходного текста
- •6.3.3 Список вопросов для выявления ошибок при инспекции
- •6.3.3.1 Ошибки обращения к данным
- •6.3.3.2 Ошибки описания данных
- •6.3.3.3 Ошибки вычислений
- •6.3.3.4 Ошибки при сравнениях
- •6.3.3.5 Ошибки в передачах управления
- •6.3.3.6 Ошибки интерфейса
- •6.3.3.7 Ошибки ввода-вывода
- •6.3.3.8 Другие виды контроля
- •6.3.4 Сквозные просмотры
- •6.3.5 Оценка посредством просмотра
- •6.4 Проектирование теста
- •6.4.1 Тестирование путем покрытия логики программы
- •6.4.1.1 Покрытие операторов
- •6.4.1.2 Покрытие решений
- •6.4.1.3 Покрытие условий
- •6.4.1.4 Покрытие решений/условий
- •6.4.1.5 Комбинаторное покрытие условий
- •6.4.2 Эквивалентное разбиение
- •6.4.2.1 Выделение классов эквивалентности
- •6.4.2.2 Построение тестов
- •6.4.3 Анализ граничных значений
- •6.4.4 Применение функциональных диаграмм
- •6.4.5 Предположение об ошибке
- •6.4.6 Стратегия
- •Контрольные вопросы
- •3. Принципы тестирования.
- •9. Анализ граничных значений.
- •11. Предположение об ошибке.
- •7 Технология разработки программ
- •7.1 Разбиение задачи на независимые подзадачи
- •7.2 Разбиение задачи на одинаковые по сложности части
- •7.3 Рекурсия и динамическое программирование
- •7.3.1 Рекурсия
- •7.3.2 Динамическое программирование
- •7.3.3 Моделирование
- •7.4 Поиск
- •7.4.1 Поиск в списках
- •7.4.2 Деревья поиска
- •7.4.3 Стратегия распределения памяти
- •7.5 Сортировка
- •7.6 Алгоритм выбора из конечного состояния
- •7.7 Сопрограммы
- •Контрольные вопросы
- •8 Методы управления проектированием программных изделий
- •8.1 Организация управления проектированием программного изделия
- •8.1.1 Понятие изделия как средства общения
- •8.1.2 Нисходящий анализ процесса управления проектированием программного изделия
- •8.1.3 Организация взаимодействия
- •8.1.4 Установление целей, средства их достижения
- •8.1.5 Подбор и обучение кадров
- •8.2 Организация планирования разработок программного изделия
- •8.2.1 Виды планов
- •8.2.2 Декомпозиция планов
- •8.2.3 Организационная структура группы планирования
- •8.2.4 Планы, связанные с созданием программных изделий
- •8.2.5 Опытный образец изделия
- •8.2.6 Организация планирования в фазе исследования
- •8.2.7 Организация планирования в стадии анализа осуществимости
- •8.2.8 Организация планирования в фазах конструирования и кодирования
- •8.2.9 Организация планирования в фазах оценки и использования
- •8.2.10 Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия
- •8.3 Организация разработки программного изделия
- •8.3.1 Организация разработки программного изделия в фазе исследований
- •8.3.2 Организация разработки программного изделия в фазе анализа осуществимости
- •8.3.3 Организация разработки программного изделия в фазе конструирования (проектирования)
- •8.3.4 Организация разработки программного изделия в фазе программирования
- •8.3.5 Организация разработки программного изделия в фазе оценки
- •8.3.6 Окончание проекта
- •8.3.7 Участие группы разработки в фазовых обзорах
- •8.4 Организация обслуживания разработки программного изделия
- •8.4.1 Организационная структура группы обслуживания
- •8.4.2 Организация обслуживания программного изделия в фазе исследования
- •8.4.3 Организация обслуживания в фазах анализа осуществимости и конструирования
- •8.4.4 Организация обслуживания в фазе программирования и оценки
- •8.4.5 Организация обслуживания в фазе использования
- •8.4.6 Участие группы обслуживания в фазовых обзорах
- •8.5 Организация выпуска документации
- •8.5.1 Организационная структура группы выпуска документации
- •8.5.2 Стандарты и практические руководства
- •8.5.3 Организация выпуска документации в фазах исследований и анализа осуществимости
- •8.5.4 Организация выпуска документации в фазах конструирования и программирования
- •8.5.5 Организация выпуска документации в фазах оценки и использования
- •8.5.6 Участие группы выпуска документации в фазовых обзорах
- •8.6 Организация испытаний программных изделий
- •8.6.1 Современное состояние методов обеспечения качества программного изделия
- •8.6.1.1 Виды испытаний программного изделия. Стадии испытаний
- •8.6.1.2 Режимы испытаний программ
- •8.6.1.3 Категории испытания программного изделия
- •8.6.2 Организационная структура группы испытаний
- •8.6.3 Организация испытаний в фазах исследований и анализа осуществимости
- •8.6.4 Организация испытаний в фазах конструирования и программирования
- •8.6.5 Организация испытаний в фазе оценки
- •8.6.6 Организация испытаний в фазе использования
- •8.6.7 Участие группы испытаний в фазовых обзорах
- •Контрольные вопросы
- •1. Понятие изделия как средства общения.
- •4. Подбор и обучение кадров.
- •6. Организационная структура группы планирования.
- •Список литературы
8.1.2 Нисходящий анализ процесса управления проектированием программного изделия
Управление проектированием программного изделия включает в себя следующие функции:
планирование;
разработку;
обслуживание;
выпуск документации;
испытания;
поддержку;
сопровождение;
Иерархическая декомпозиция управления разработкой программного изделия может быть представлена следующим образом (рис. 8.1).
Рис. 8.1 — Декомпозиция управления
Такая идеализированная организация требует полной обособленности процессов, связанных с проектированием, от других видов деятельности и изолированности всех функций друг от друга. Естественно, что на практике это не реализуемо.
Каждая организация должна иметь администратора (директора), именно он несет ответственность за успех и неудачу разработки. В структуре также должно существовать то или иное важное направление деятельности, включая функцию разработки. Лицо, которое руководит этим направлением, считается ответственным за все аспекты создания изделия, выпускаемого организацией. Чтобы координировать процесс разработки, это лицо имеет право назначать администраторов изделия и руководителей проектов и обеспечивать их взаимодействие.
8.1.3 Организация взаимодействия
Если все взаимодействия хорошо определены, то и управление ими организовано должным образом. Если же взаимодействия плохо организованы, то даже при жесткой линейной структуре подчинения трудно будет создать конечное изделие.
Важнейшим принципом любого вида управления является разделение целого на части, и многие методы и средства основываются именно на этом принципе.
Совокупность точек, в которых две функциональные группы взаимодействуют друг с другом, называется организационной границей. Иногда функция может иметь один канал взаимодействия со всеми остальными функциями, однако более вероятно, что она имеет несколько границ соприкосновения. Границы функции определяются множеством зафиксированных и незафиксированных планов, стратегий, процедур, которые определяют функциональные обязанности. Чем больше сведений фиксируется в письменном виде, тем лучше, т.к. это уменьшает двусмысленность. Основное свойство организационной границы состоит в разграничении ответственности (кто и что делает, каким образом, для чего и т.д.). Неполное определение, двусмысленность и сложность приводят к невозможности описания, а следовательно, и понимания природы взаимодействия.
Но ни сами документы, ни их коллективное обсуждение не могут обеспечить действенных взаимосвязей, если отсутствуют контакты функциональных групп.
Общие организационные обязанности могут устанавливаться с помощью должностных инструкций и целевых планов подразделений. Конкретные обязанности определяются планами выпуска изделия. Пропорциональное распределение ответственности обеспечивается соответствующими стратегиями управления. В них обязательно должны предусматриваться возможности невыполнения взятых обязательств и учитываться поправки на исключительные случаи, чтобы сделать планы и процедуры жизнеспособными.
8.1.4 Установление целей, средства их достижения
Первым шагом процесса установления и достижения целей является подбор необходимого персонала. Когда в организации происходят изменения, соответственно меняется и ее персонал. Некоторые изменения происходят периодически. Подобные изменения характеризуются экспоненциальным ростом числа устанавливаемых связей. Чтобы приспособиться к этим колебаниям, нужны руководители, способные к адаптации. Руководителей, продуктивных только в каком-либо одном виде деятельности, нужно заменять. Программирование — область деятельности, требующая высокой квалификации, оно привлекает к себе неординарных, эксцентричных людей. Такие люди редко понимают структуру организации, ориентированную на создание программного продукта, часто отказываются работать в условиях ограничения свободы творчества, т.к. они вынуждены тратить время на документирование или защиту своих разработок. Однако их участие в «черновой работе» необходимо, и чтобы склонить этих людей к работе, необходимо комплектовать штат, руководствуясь соображениями эффективности. Это означает отход от идеальных установленных общих правил, предоставление свободного режима прихода и ухода с работы, выделение таким людям помощников, способных компенсировать их неумение четко документировать свои результаты. Но при этом следует сравнивать прямые затраты, связанные со стимулированием «привилегированных» сотрудников, а также неявные издержки, связанные с ухудшением морального состояния их сослуживцев, с получаемой организацией выгодой.
Основным методическим принципом управления разработкой является целевое управление.
Целевое управление представляет собой концепцию планирования и управления, с помощью которой руководитель устанавливает соответствующие цели через своего непосредственного руководителя более высокого ранга и участвует в установлении целей последнего; при этом результаты его деятельности оцениваются на основании конкретного обсуждения и документального рецензирования.
Цели присутствуют в планах самого различного уровня: целевых планах, бюджете, планах выпуска изделий, документации и т.д. Основной план для программного изделия — соглашение о требованиях. Цели, сформулированные в этом плане, должны включаться в индивидуальные рабочие планы, служащие тем механизмом, посредством которого в системе целевого управления достигается договоренность между исполнителями и их руководителями.
Достижение цели гарантируется включением общих целей создания изделия в индивидуальные рабочие планы и организацией текущего контроля за их выполнением.
Соглашение о требованиях, план поддержки, распределение бюджета и другие средства устанавливают те границы, в пределах которых не требуется использование обратной связи.
Существует три вида основных критериев оценки эффективности той или иной деятельности:
конкретные свойства;
затрачиваемое время;
стоимость.
Каждый из этих критериев имеет определенные границы действия, по достижению которых обязательно предоставление отчета руководству о результатах.
Однако следует учитывать, что управление созданием программных изделий является примером управления в условиях неопределенности. Качество такого управления зависит от способностей руководителей предвидеть трудности, планировать разработку с учетом случайных факторов и уметь защищать такого рода планирование от критики начальства, которое требует непременно «исключить случайность».
