Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка программного продукта профессиональные стандарты, жизненный цикл, командная работа. Учебное пособие
.pdf
Подготовка
сообщения
Рис. 4. Структура шага диалога пользователя
Выдача
сообщения
Действие Ответ
Подготовка
сообщения
Выдача
сообщения
Характеризуя действия и ответы в модели шага диалога, нужно
предпринять следующее.
Определить инициатора шага диалога (кто совершает дей-
ствие/отвечает – пользователь или программа).
Выбрать тип инициирования данного шага диалога, используе-
мого программой, если она совершает действие: программа запрашивает ввод задачи пользователем, относящийся к некоторой специальной теме, программа
может предлагать пользователю варианты для
выбора, перечисляя все альтернативы.
Задать следующие возможности выбора функций:
– нет выбора, т. е. выполняемая функция предопределена (напри-
мер, только функция ввода данных);
– ограниченный выбор (на шаге диалога доступно подмножество
функций программы);
– неограниченный выбор (на шаге диалога доступны все функции
программы).
На основе определенных
характеристик шага диалога можно раз-
работать различные типы диалога:
простой запрос (у пользователя нет выбора, функция предписана
программой);
предложение для выбора (меню и вопросы, требующие ответа
«да/нет»);
запрос с указанием синтаксиса ответа (пользователь может реа-
гировать на запрос синтаксически ограниченным входным сообщением);
запрос для
свободного ответа;
команда (пользователь специфицирует свои задачи и объекты в
соответствии с предписанным синтаксисом; программа прямо преобразовывает входное сообщение в последовательность работ).
41
Формальная структура входных и выходных сообщений определяется моделью, которая дает описание структурных свойств сообщений,
реализующих действие и ответ. Модель данного уровня определяет
словарь используемых для выражения сообщений элементов, грамматику и правила, которым соответствует входное сообщение, ограничения на длину, правила использования определенных символов в сообщении, расположение входного сообщения
на экране (внешний формат
входного сообщения), формальную избыточность входного сообщения, формальную структуру выходного сообщения (синтаксис и формат выходного сообщения).
Для уменьшения ошибок пользователя необходимо пояснять выполняемые им действия и выдаваемые программным продуктом результаты.
Для оценки соответствия программного продукта заявленным характеристикам можно использовать чек-лист, представленный
в при-
ложении 4.
Верификация программного кода для каждого модуля представляет собой строгое соответствие, с одной стороны, последовательности, количества и типов управляющих конструкций алгоритма и, с
другой стороны, операторов подпрограммы. Нарушения данного соответствия возникают по разным причинам, самой распространенной
является халатное отношение к процессу проверки правильности алгоритма на
этапе проектирования, в результате которого логические
ошибки обнаруживаются и исправляются на этапах кодирования, отладки и тестирования. Кроме того, в программной реализации должны сохраняться все переменные исходного алгоритма с возможным
добавлением некоторого количества логических переменных (флагов,
переключателей) и условных операторов, в которых чаще всего
распознаются способы выхода из циклов («
аварийный» или нор-
мальный).
В табл. 21 приведены примеры соответствия фрагментов алго-
ритма и программной реализации.
Пример несоответствия алгоритма и программной реализации
представлен в табл. 22.
42
Таблица 21
я
Фрагмент алгоритма
Фрагмент
программного модуля
S = 0;
while (1)
{
printf(“Enter X:”)
scanf(“%d”, &Х);
if (Х>0) S=S+Х;
else break;
}
X = 0;
i = 1;
while (X ≤ a)
{
i = i + 1;
X = X + 1./a;
}
K = 0;
do
{
K = K + 1;
}
while(n/pow(10,k)≥0
);
Комментарий
Общий случай управл
-
ющей конструкции ПОВТОРЕНИЕ реализован
бесконечным циклом
while.
В программной реализации добавлен оператор,
приглашающий ввести
значение переменной
Управляющая конструкция ПОВТОРЕНИЕ на
языке С реализована циклом с предусловием while
Управляющая конструкция ПОВТОРЕНИЕ на
языке С реализована циклом с постусловием do
while
M = 1;
for (j=2; i< j; j++)
if ((i % j) == 0)
M = M + j;
Управляющая конструкция ПОВТОРЕНИЕ на
языке С реализована циклом с параметром for
43
Таблица 22
зу
Алгоритм Программная реализация
void Kratn ()
{
int x;
printf(“Kratnost 3 & 5”);
printf(“Vvedi chislo:”);
scanf(“%d”, &x);
if (((x % 3) == 0)&&((x % 5) == 0)))
printf (“Kratno 3 & 5”);
else
printf (“Kratno 3”);
}
Комментарий: два условия объединены в
одно, в результате чего, например, число 10
окажется кратно 3
Отладка и тестирование
В табл. 23 показано соответствие целей обучающегося требованиям
определенных профессиональных стандартов (трудовые функции, трудовые действия, необходимые умения и знания).
Таблица 23
Подготовка тестовых данных и выполнение тестовых процедур
Разработка тестовых случаев, проведение тестирования и исследование ре-
льтатов
Выполнение процесса тестирования (А/03.4)
Регистрация дефектов в системе контроля (базах данных) (А/04.4)
Анализ результатов тестирования (В/04.5)
Предоставление результатов тестирования руководителю группы (отдела)
тестировщиков (В/06.5)
Выполнение тестовых процедур на тестовых данных.
Сравнение фактического и ожидаемого результатов.
При выявлении несовпадений регистрация найденных дефектов в системе контроля дефектов.
Выполнение тестовых сценариев, выявивших дефекты, для подтверждения успешности их выполнения
после исправления программного обеспечения.
Подготовка отчета о выполненных действиях
Уметь:
используя модули,
пошагово отлаживать
и тестировать про
граммы;
обнаруживать, ис-
правлять и документи-
-
44
Окончание табл. 23
р
Выполнять алгоритм без отклонений.
Описать дефект.
Составлять отчет
по выполнению
рабочего задания.
Работать в команде с другими специалистами по
тестированию и
разработчиками
Основы теории алгоритмов и автоматов, основы дискретной математики в объеме полученного
профессионального образования.
Основы программирования.
Жизненный цикл программного
обеспечения, жизненный цикл
дефекта.
Техники тестирования (техники,
базирующиеся на интуиции и
опыте инженера; техники, базирующиеся на спецификации; техники, ориентированные на код;
тестирование, ориентированное
на дефекты; техники, базирующиеся на условиях использования; тестирование, базирующееся
на надежности инженерного процесса; техники, базирующиеся на
природе приложения).
Нормативные, методические материалы по вопросам испытания
и тестирования программных
продуктов
овать программные
ошибки;
оценивать эффек-
тивность программы
(быстродействие и
объем памяти);
разрабатывать и от-
лаживать проекты в
различных средах разработки.
Знать:
технологию создания
приложений с использованием языков программирования высокого уровня
Критерии качества выполненной работы на этапе «Отладка и те-
стирование» представлены в табл. 24.
Каждый член команды использует различные до-
ступные способы отладки и тестирования своих модулей, для чего совершает следующие действия:
отлаживает и тестирует модули в соответствии с
принципом структурного программирования «сверху
вниз» на подготовленном наборе данных;
документирует результаты тестирования модулей для каждого
спроектированного набора тестовых данных:
– приводит фактические результаты работы модулей;
– описывает результаты сравнения ожидаемых и фактических ре-
зультатов и делает выводы о правильности работы модулей;
45
– в случае обнаружения ошибки описывает внесенные изменения в
модуль и приводит результаты повторного тестирования модуля.
Таблица 24
Оценка выполненной работы
Отлично Хорошо Удовлетворительно
Документирование результатов тестирования программного продукта для
каждого спроектированного набора тестовых данных (исходные данные и
ожидаемые результаты):
приведены фактические результаты (результаты работы программного про-
дукта);
показаны результаты сравнения ожидаемых и фактических результатов и
сделаны выводы о правильности работы программного продукта;
в случае обнаружения ошибки (дефекта) описаны внесенные изменения в
программный продукт и приведены результаты повторного тестирования
Для тестирования используются разработанные на соответствующем этапе наборы
тестовых данных на
оценку «отлично»
Для тестирования используются разработанные на соответствующем этапе наборы
тестовых данных на
оценку «хорошо»
Для тестирования используются разработанные на
соответствующем этапе
наборы тестовых данных
на оценку «удовлетворительно»
В команде совершают следующие действия:
создают программный продукт, включающий в себя
все разработанные и протестированные модули;
проводят интеграционное тестирование программ-
ного продукта;
документируют результаты интеграционного тестирования.
Основные положения тестирования заключаются в следующем.
Тестирование – это процесс, представляющий собой совокуп-
ность взаимосвязанных или взаимодействующих видов деятельности,
преобразующих входы
в выходы.
Необходимо планировать, контролировать тестирование и уп-
равлять им.
Процессы и подпроцессы тестирования применимы для любой
фазы или уровня тестирования (например, тестирование системы) и
для любого типа тестирования (например, тестирование производительности).
46
Тестирование предполагает исследование элемента тестирования.
Возможно тестирование продукта без выполнения его на компь-
ютере, называемое статическим тестированием. Действия статического
тестирования считаются крайне важными для полного тестирования
жизненного цикла. Выполнение такого тестирования критически важно для раннего обнаружения дефектов, снижения полной стоимости
проекта и обеспечения наиболее точного соответствия графику.
Динамическое тестирование представляет собой нечто большее,
чем просто выполнение исполнимых элементов тестирования, к нему
относят также действия подготовки и последующие действия.
Верификация – это подтверждение путем представления объективных доказательств выполнения данным рабочим элементом установленных требований.
Валидация демонстрирует, что рабочий элемент может исполь-
зоваться пользователями для решения определенных
Тестирование как статическое, так и динамическое, должно быть
направлено на получение обоих типов подтверждения, хотя и должно
допускать, что подтверждение не будет получено немедленно из-за
обнаружения дефектов.
В работах [2–4] рассматриваются понятия «верификация» и «валидация», описаны основные методы тестирования, представлены типы
тестовых примеров, а также методы статической
рификации программных продуктов.
ими задач.
и динамической ве-
Защита результатов работы
В табл. 25 показано соответствие целей обучающегося требованиям
определенных профессиональных стандартов (трудовые функции, трудовые действия, необходимые умения и знания).
На защиту необходимо представить отчет по результа-
там работы и разработанный программный продукт.
В ходе защиты необходимо следующее:
продемонстрировать работоспособность и универ-
сальность программного продукта на тестовых данных, выбранных преподавателем
показать возможности практического использования программ-
ного продукта (валидация);
(заказчиком);
47
продемонстрировать адаптируемость программного продукта
л
(возможность настройки на конкретную целевую группу);
определить возможности усовершенствования программного
продукта.
Таблица 25
Выполнение работ и управление работами по созданию (модификации) и сопровождению ИС, автоматизирующих задачи организационного управления и
бизнес-процессы
Организация приемо-сдаточных испытаний (валидации) ИС (С/35.6)
Организация проведения приемо-сдаточных
испытаний ИС.
Организация подписания документов по результатам приемо-сдаточных испытаний
Планировать работы.
Распределять работы и выделять
ресурсы
Инструменты и методы проведения приемо-сдаточных
испытаний (валидации) ИС.
Управление качеством: контрольные списки, верификация, валидация (приемосдаточные испытания)
Уметь:
демонстрировать основ-
ные свойства программного
продукта:
– работоспособность;
– универсальность;
– адаптируемость;
– полезность (валидация);
определять возможности
усовершенствования программного продукта
В табл. 26 представлен чек-лист как часть отчета о выполненной
работе и ее результатах в процессе создания программного продукта, в
котором для защиты необходимо отметить все выполненные действия.
Кроме того, необходимо заполнить чек-лист соответствия программного продукта заявленным характеристикам (см. приложение 4).
Таблица 26
Этап
Описание предметной области.
Постановка задачи
Действия (слева от действия поставить «галочку»,
если действие выпо
Приведены основные термины и их определения, необхо-
димые для описания предметной области задачи.
Определен набор исходных данных и результат решения
задачи.
Имеется краткое словесное описание алгоритма решения
основной задачи и подзадач.
Дано визуально-наглядное представление формализации
постановки задачи
48
нено)
Окончание табл. 26
у
Этап
Формирование
тестовых данных
Проектирование
структур данных и алгоритмов
Разработка интерфейса и программная реализация
Отладка и тестирование
Защита результатов работы
Действия (слева от действия поставить «галочку»,
если действие выполнено)
Определены тестовые данные для модульного и интегра-
ционного тестирования.
Прокомментированы исходные данные и ожидаемый ре-
зультат.
Набор тестовых данных проверен на полноту и избыточ-
ность.
Дана необходимая графическая интерпретация входных и
выходных данных
Представлена схема иерархии программных модулей.
Построены обобщенные блок-схемы алгоритмов.
Имеются таблицы описания структур данных и основных
функций.
Приведены результаты оценки сцепления, связности и
эффективности мод
Форма диалога с пользователем является лаконичной и
интуитивно-понятной.
Интерфейс пользователя имеет единый стилевой формат.
Проведены оценка эффективности и верификация про-
граммного кода.
Тексты программных модулей структурированы и про-
комментированы
Представлены фактические результаты модульного и ин-
теграционного тестирования.
Задокументированы обнаруженные ошибки и действия по
их устранению.
Приведены добавленные наборы тестовых данных и ре-
зультаты повторного тестирования (если таковые имеются).
Представлено несколько контрольных примеров
Перечислены возможности настройки программного про-
дукта под конкретного пользователя.
Приведены требования, дополнения, замечания заказчика
(преподавателя) и описаны способы их реализации (или
обоснован отказ от них) в данной работе.
Представлена самооценка работы команды (см. приложе-
ние 2).
Представлена самооценка качества разработанного ин-
терфейса с
помощью анкеты (см. приложение 3)
лей
49
ЗАКЛЮЧЕНИЕ
Разработка программных продуктов в современных условиях является сложным, регламентированным, прежде всего Государственными
стандартами и другими нормативными документами, процессом, в котором участвуют специалисты из различных предметных областей.
В свою очередь требования к специалистам, разрабатывающим программные продукты, определяются профессиональными стандартами.
Кроме того, имеются многочисленные продуктивные приемы, являющиеся результатом осмысления
работке программных продуктов. Соответственно в данном учебном
пособии рассмотрены особенности основных этапов разработки программных продуктов в рамках каскадной модели с опорой на современные профессиональные стандарты, существующие рекомендации
Государственных стандартов и продуктивные приемы, описываемые в
литературе. Особое внимание уделено организации условий разработки
программного продукта, а именно – организации командной работы, причем выделена индивидуальная работа каждого члена и совместная работа членов команды на каждом этапе жизненного цикла
программного продукта. Кроме того, определены критерии оценки качества разработки программного продукта на каждом этапе, что дает
возможность согласовать их между заказчиком и разработчиком
(в
данном случае – между преподавателем и обучающимися), а также
осуществлять обучающимся самооценку качества проделанной работы. При этом создаются реальные условия для реализации каскадной
модели разработки программного продукта, предполагающей возврат
только на один шаг назад в рамках жизненного цикла при обнаружении ошибок в разработке. Организация разработки любого программного продукта по
работки в соответствии с современными требованиями к качеству.
описанной модели обеспечивает условия для его раз-
и обобщения лучших практик по раз-
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]