Читать онлайн «Программное обеспечение и его разработка». Страница 68

Распечатки программ

Распечатки перекрестных ссылок

Карты загрузки

Регенерация программ

Выполнение программ

Анализ выполнения программ

Нефункциональное выполнение

Функциональное выполнение

Тесты программ

Тесты модулей

Тесты подпрограмм

Тесты производительности программ

Комплексный тест систем(ы)

Отчетность об ошибках в программном обеспечении

Категория отчетов об ошибках в программном обеспечении

Приоритет отчетов об ошибках в программном обеспечении

Рассылка отчетов об ошибках в программном обеспечении

Гарантия качества

Обеспечение гарантируемого качества

Уровни отчетности

Участие в обсуждениях

Пересмотр планов

Проектирование программ

Кодирование программ

Тесты

Представляемые элементы

Отчетность

Авторство

Приемлемость программ

Дополнительные требования к приемлемости программ

Требования к тестам качества программного обеспечения для проверки приемлемости программ

Окружение тестирования

Тестируемое программное обеспечение

Документация тестов качества программного обеспечения

Выполнение тестов качества программного обеспечения

Продолжительность тестирования качества программного обеспечения

Входные данные для тестов качества программного обеспечения

Тестирование качества тестирования качества программного обеспечения

Возможность сокращенного тестирования качества программного обеспечения

Тесты качества программного обеспечения и вспомогательные программы сопровождения

Ошибки во время тестирования

Ограничения на тесты качества программного обеспечения

Ограничения из-за ошибок

Временные ограничения

Руководство конфигурацией

Идентификация конфигурации

Основные варианты

Определение документации

Управление конфигурацией

Изменения в программном обеспечении

Изменения в документации

Панели управления конфигурацией программного обеспечения

Вычисление статуса конфигурации

Руководящий контроль

Организация руководства

Требования к ресурсам

Обзоры положения дел

Предметы обзоров положения дел

Пункты, по которым проводятся обзоры положения дел

Обзоры документации

Специальные обзоры

Инспекции и прослушивания

Этот список ни в коей мере нельзя считать полным. Любой список, составленный более года назад, можно считать устаревшим. Однако список этот оказывается полезным и для демонстрации широты приложения усилий на узком участке, и для проверки, не проглядели ли мы чего-нибудь.

Что же мы получаем в результате процесса разработки программного обеспечения? Основные результаты таковы:

1. Конечно же, программы, которые будут выполняться, ну а что же еще?

2. Руководства для пользователей. Инструкции и описания, которые сделают систему понятной для пользователя и помогут работать с ней.

3. Материалы для сопровождения программ. Материалы, необходимые для продолжающейся разработки, не отличаются от тех, что требуются для обеспечения первичной разработки программ. Планы тестирования, результаты тестов, спецификации и все остальное, что нами использовалось, а также хорошая документация.

Все, что изображено на рис. 6.14, является результатом процесса разработки программного обеспечения. Всех подробностей, однако, эта схема не содержит. Например, в качестве подмножества к проекту системы мы могли бы указать список интерпретирующих и моделирующих программ, которые пишутся для того, чтобы создаваемый нами проект программы оказался успешно завершенным. Эти программы, весьма ценные для групп сопровождения, также являются результатом усилий по разработке программного обеспечения.

Любой важный проект должен разрабатываться по плану. Сегодня такие планы стараются делать так, чтобы их можно было обрабатывать на вычислительных машинах и хранить в памяти инструментальной машины.

План разработки содержит огромное множество разных пунктов, расписанных в мельчайших подробностях. Нужно быть постоянно в курсе их выполнения, чтобы этим планом можно было руководить. План проекта или разработки содержит:

1) спецификации требований;

2) рабочую схему организационной структуры с указанием сроков реализации;

3) схему расстановки кадров;

4) бюджет;

5) документирование рабочих стандартов. Руководитель разработки поочередно обращается то к плану, то к результатам его воплощения, модифицирует план и опять начинает этот цикл сначала. Рис. 6.15 выглядит просто, но следовать предложенной на нем схеме очень трудно. Самое важное место на схеме отводится пересмотру графика, бюджета или функций (см. маленький прямоугольник слева). Когда дела идут скверно, чем-то приходится поступиться — и этим должно быть что-то из этой тройки. Руководство обычно медленно соглашается с изменениями плана

Заметьте, что входная стрелка к прямоугольнику, обозначающему план проекта, ведет от начального определения объема работ или предварительных оценок. Обратимся же теперь к изучению способов оценок и тому, что им предшествует — производительности труда.

Производительность труда — это скорость производства окончательных программ, вполне готовых к работе. Определяется она как отношение объема работ, выполненных при разработке, к продолжительности этих работ. Производительность труда обычно измеряется в строках программы, отнесенных к человеко-месяцу (или человеко-году). Ниже мы рассмотрим некоторые проблемы, связанные с введением такого способа измерения.

Оценка состоит из двух частей. Во-первых, нам нужно оценить размеры того, что нам предстоит построить, а во-вторых, мы должны оценить производительность труда, которой мы должны достигнуть во временном и денежном выражениях и в терминах занятости персонала. Для общей оценки второй части нам необходимо обладать некоторым понятием о максимальной и средней скоростях реализации того типа и в той области деятельности, которой нам предстоит заняться, т. е. некоторыми оценками производительности труда. Поэтому сначала мы обратимся к изучению производительности труда, а затем перейдем к изучению оценок.

Нам не известно, как надо измерять производительность труда при программировании или разработке программного обеспечения. Мы только начинаем разрабатывать терминологию и средства измерения. Многого мы еще не понимаем. Для описания трудности работы мы используем такие термины, как «тяжелая» или «очень тяжелая», «большая» или «огромная». От таких терминов особой помощи ждать не приходится.

Более полезным оказывается способ измерения, связанный с подсчетом числа команд или строк текста программы (СТП). Используя это понятие, мы, например, говорим, что данная работа или функция — скажем, составление платежной ведомости — требует 50 тыс. строк программы.

Это единственный способ измерения, который реально используется в настоящее время. Но и в нем есть изъяны. В этом случае поощряются плохие разработчики, которые для реализации функции пишут очень много команд.