Разработка программного обеспечения

Жизненный цикл разработки — это набор этапов от идеи до готового, поддерживаемого программного обеспечения. Он существует для того, чтобы планировать, управлять и контролировать проект — создать правильный продукт, вовремя и высокого качества.

*Блок-схема планирует логику программы на этапе проектирования цикла

Зачем нужен жизненный цикл

Список экзаменатора по теме «цели жизненного цикла разработки»: он разбивает крупный проект на этапы, которые можно планировать и управлять; обеспечивает выявление и согласование требований до начала проектирования и кодирования; включает тестирование и документацию, а не откладывает их на конец; позволяет команде отслеживать прогресс по ключевым точкам и управлять рисками; и дает заказчику определенные моменты для обзора работы. Без него команда сначала пишет код, а позже обнаруживает, что создало неправильный продукт.

Почему существуют разные модели

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

Распространенные модели

• Водопад — линейная последовательность (Анализ → Проектирование → Кодирование → Тестирование → Поддержка), каждый этап завершается до начала следующего. Прозрачен и хорошо документирован; подходит для стабильных требований, но плохо справляется со средними изменениями, и заказчик видит работающий продукт только в конце.
• Итеративная модель — многократные проходы, каждый из которых создает частичную версию, которая проверяется и дорабатывается. Позволяет выявить проблемы раньше; подходит, когда требования выявляются постепенно, но сложнее оценивать сроки.
• Быстрая разработка приложений (RAD) — активное использование прототипа и обратной связи от пользователей. Очень быстрая первая доставка; подходит для меняющихся требований, но зависит от доступности пользователей и лучше подходит для небольших систем.
• Agile — короткие итерации («спринты»), постоянное сотрудничество и тестирование. Гибкая и адаптивная, но требует вовлеченного заказчика и квалифицированной команды.

*Модель водопада: каждый этап завершен до начала следующего

*Итеративная модель: повторяющиеся проходы уточняют программу

*Быстрая разработка приложений: команды работают над частями параллельно

Принципы, преимущества и недостатки — согласно схеме оценки.

Разбор примера. Компания должна первой запустить веб-сайт для новой игровой консоли, и дизайн будет меняться по мере объявления функций консоли. Назовите наиболее подходящий жизненный цикл и обоснуйте выбор.

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

Стандартные этапы

Каждый этап имеет цель, выходной результат и типичные виды деятельности — вопрос «опишите … этап» требует двух или трех из них.

• analysis — определить, что должна выполнять программа. Этапы: интервью, анкетирование и наблюдение за текущей системой; изучение возможности реализации; согласование спецификации требований, по которой проверяется каждый последующий этап.
• design — решить, как это будет сделано. Результаты: структурная диаграмма (модули и параметры), блок-схемы или псевдокод для каждого модуля, таблицы идентификаторов и структуры данных, макеты экранов и файлов, а также план тестирования, написанный сейчас, на основе спецификации, до появления любого кода.
• coding (implementation) — написать программу на языке высокого уровня, модуль за модулем, следуя дизайну; каждый модуль тестируется по мере написания.
• testing — запустить программу согласно плану тестирования (нормальные, ненормальные, экстремальные и граничные данные) и исправить найденные ошибки; следует интеграционное, альфа-, бета- и приемочное тестирование.
• maintenance — после релиза исправлять ошибки, адаптировать программу к новому оборудованию, программному обеспечению или законодательству, а также улучшать её (см. ниже).

Разбор примера. Заполните схему водопада Анализ → ? → ? → ? → Поддержка и опишите, что происходит на этапе проектирования.

Пропущенные этапы — Проектирование, Написание кода, Тестирование. На этапе проектирования требования преобразуются в план программы: задача разбивается на модули (структурная диаграмма), алгоритм для каждого модуля записывается в виде псевдокода или блок-схемы, выбираются структуры данных и идентификаторы, размещаются экраны и файлы, а также пишется план тестирования на основе спецификации.

Структурная диаграмма

Структурная диаграмма показывает иерархическое разделение программы на модули (подпрограммы) и параметры, передаваемые между ними. Каждый модуль обозначен прямоугольником; линии соединяют вызывающий модуль (сверху) с вызываемым (снизу); маленькие стрелки показывают передачу данных вниз и возвращение результатов вверх. Затем дизайн можно превратить в эквивалентный псевдокод.

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

Это инструмент этапа проектирования, и по нему можно прочитать сигнатуры процедур.

Обозначения, которые спрашивает экзаменатор. Прямоугольник — это модуль; линия соединяет вызывающий модуль (сверху) с модулями, которые он вызывает (снизу), читая слева направо в порядке вызова. Маленькая стрелка с открытым кружком у основания — это пара данных — параметр, передаваемый вниз в модуль, или значение, возвращаемое вверх; стрелка с закрашенным кружком — это пара управления, флаг (обычно BOOLEAN), сообщающий вызывающему модулю о результате. Ромб на ветвлении означает выбор: только один из модулей под ним вызывается в зависимости от условия. Кривая стрелка, охватывающая связи, означает итерацию: модули под ней вызываются повторно в цикле.

Разобранный пример. Четыре модуля определены как PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN и PROCEDURE Report(Total : INTEGER, Count : INTEGER). Главный модуль вызывает ReadData, затем для каждого прочитанного значения один раз вызывает IsValid, после чего вызывает Report. Опишите структуру диаграммы.

Main сверху; ReadData, IsValid и Report в ряд под ним, слева направо в порядке вызова. На связи ReadData — восходящая пара данных Count (BYREF-параметр возвращается). На связи IsValid — нисходящая пара данных Value и восходящая пара управления (результат BOOLEAN), с кривой стрелкой итерации над этой связью, так как она вызывается для каждого значения. На связи Report — две нисходящие пары данных, Total и Count. Чтение в обратном направлении: функция — это любой модуль, возвращающий значение — его заголовок требует RETURNS и возвращаемый тип.

Диаграмма переходов состояний

Диаграмма переходов состояний показывает состояния, в которых может находиться система, и события, перемещающие её между ними — подходит для вендинговых автоматов, светофоров, пользовательских интерфейсов. Диаграммы переходов состояний используются для документирования поведения алгоритма или системы. Каждое состояние — это круг; каждый переход — стрелка, помеченная событием.

   coin inserted               item selected
[Idle] --------------→ [Awaiting selection] ----------→ [Dispensing]

Это позволяет легко заметить пропущенные переходы («что, если вторая монета будет вставлена во время ожидания выбора?»).

Чтение и построение одной. Каждый переход помечается input | output (или condition | action): что произошло, затем то, что делает система при изменении состояния. Вопрос дает таблицу текущее состояние, вход, выход, следующее состояние и просит построить диаграмму, или наоборот — каждая строка таблицы соответствует ровно одной стрелке. Проверьте, что из каждого состояния есть стрелка, выходящая для каждого возможного входа, включая те, которые не меняют состояние (стрелка, ведущая обратно в то же состояние).

Разбор примера. Контроллер насоса имеет состояния pump off и pump on. В состоянии pump off вход low level detected дает выход activate pump и переводит систему в состояние pump on; в состоянии pump on вход normal level detected дает выход deactivate pump и переводит систему в состояние pump off. Любой другой вход оставляет состояние без изменений. Нарисуйте таблицу.

Две строки «без изменений» становятся стрелками петли на диаграмме; их исключение лишит балла за полноту.

• синтаксическая ошибка — нарушает грамматику языка (пропущена скобка, опечатка в ключевом слове). Обнаруживается при компиляции; программа не запустится до исправления.
• ошибка времени выполнения — происходит во время работы (деление на ноль, файл не найден, индекс массива вне диапазона). Программа завершается аварийно или выбрасывает исключение; исправляется добавлением проверок.
• логическая ошибка — программа работает, но дает неверные результаты (использование + вместо -, цикл с ошибкой смещения на единицу, условия в неправильном порядке). Труднее всего найти; единственный признак — неверный вывод, поэтому используйте тщательное тестирование и трассировку.

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

Разобранное решение. Укажите тип ошибки в каждом случае и то, как она проявляется. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) выполняется с y = "0". (b) Та же строка выполняется с x = "12a". (c) Цикл, записанный как FOR i <- 1 TO 9, обрабатывает десятиэлементный массив. (d) В OUTPUT "Total: " Total отсутствует запятая.

(a) Ошибка времени выполнения — деление на ноль; программа аварийно завершается при выполнении этой строки с указанными данными. (b) Ошибка времени выполнения — строка не может быть преобразована в число. (c) Логическая ошибка — программа работает, но десятый элемент никогда не обрабатывается, поэтому вывод неверен. (d) Синтаксическая ошибка — оператор нарушает правила языка и сообщается компилятором до запуска программы.

Разобранное решение. Исправьте ошибки в этом псевдокоде, который должен вывести среднее значение десяти оценок.

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

Деление должно выполняться на число 10, а не на 9 (логическая ошибка); в строке вывода нужна запятая или оператор конкатенации & между строкой и значением (синтаксическая ошибка); а переменная Average никогда не была объявлена как REAL (синтаксическая или ошибка времени выполнения, в зависимости от языка). Укажите номер строки и исправленную версию: строка Average <- Total / 10.

• прогон вручную — трассировка кода на бумаге с записью значений каждой переменной в таблицу.
• обзор (walkthrough) — командная проверка кода.
• белое тестирование — разрабатывается на основе внутренней структуры кода, покрывает каждое оператор, ветвление и цикл.
• черное тестирование — разрабатывается только на основе спецификации: подайте входные данные, проверьте выходные.
• интеграционное тестирование — объедините модули и протестируйте интерфейсы между ними.
• альфа-тестирование α — со стороны разработчиков/внутри компании перед релизом; бета-тестирование β — ограниченной группой реальных пользователей в их собственной среде.
• приемочное тестирование — со стороны заказчика для определения пригодности продукта по назначению.
• заглушка (stub) — заглушка для модуля, которого еще нет, чтобы можно было протестировать структуру сверху вниз.

Какой метод, когда. Прогон вручную и обзор не требуют компьютера — прогон вручную это вы, отслеживающий алгоритм с помощью трассировочной таблицы; обзор — это встреча, на которой автор объясняет код построчно, а коллеги ищут дефекты, поэтому он также распространяет знания о коде среди команды и проверяет его соответствие проекту. Белые тесты пишутся кем-то, кто видит код, и направлены на прохождение каждого пути; черные тесты пишутся на основе спецификации и проверяют только входные данные по отношению к ожидаемым результатам, поэтому их могут выполнять пользователь или отдельный тестировщик. Интеграционное тестирование следует после тестирования модулей: модули, прошедшие单独的 проверку, все равно могут не работать, если передаваемые между ними данные имеют неправильный тип или порядок. Альфа- тестирование проводится внутри компании; бета- тестирование предоставляет кандидата на релиз выборке реальных пользователей, которые сообщают о дефектах из реальной эксплуатации; приемочное тестирование — это проверка заказчиком готового продукта соответствия требованиям перед оплатой. Заглушка позволяет начать тестирование сверху вниз до создания всех модулей.

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

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

Разобранное решение. Приведите три преимущества тестирования программы методом обзора.

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

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

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

Выбор тестовых данных

Для каждого поля или условия необходимо включить три вида:

• нормальные данные — типичные значения в пределах допустимого диапазона (для оценок 0–100: 50, 75).
• ненормальные данные — значения, которые должны быть отклонены (-10, 200, "abc").
• краевые данные — наибольшее и наименьшее значения, которые всё ещё принимаются (0 и 100).
• граничные данные — значения на границах, где скрываются ошибки «off-by-one» (каждое принимаемое экстремальное значение и отклоняемое значение непосредственно за его пределами: 0/-1, 100/101).

Разобранный пример. Поле принимает оценку экзамена от 0 до 100. Приведите тестовые данные каждого вида с ожидаемым результатом. Нормальные: 50 — принимаются, типичное значение в диапазоне. Ненормальные: -10, 200, "abc" — все отклоняются, так как вне диапазона или неправильного типа данных. Экстремальные: 0 и 100 — наибольшее и наименьшее значения, которые все еще принимаются. Граничные: пары, охватывающие каждое ребро - -1 отклоняется вместе с 0 принимаемым, и 100 принимаемым вместе с 101 отклоняемым. Каждое значение должно иметь свой ожидаемый результат, иначе план тестирования ничего не доказывает. Экстремальные и граничные данные最容易混淆：экстремальное значение находится внутри и принимается, тогда как граничный тест всегда является парой по обе стороны от границы — именно там скрываются ошибки «off-by-one».

Разобранный пример. Компонент считается годным, если его вес, измеренный с точностью до грамма, находится в пределах 3 г от целевого значения 50 г, т. е. от 47 г до 53 г включительно. Составьте строки плана тестирования для этой проверки.

Каждая строка должна объяснять, почему выбрано значение и что должно произойти; простой список чисел не оценивается.

Большая часть стоимости жизненного цикла программы приходится на техническое обслуживание. Три вида:

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

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

Почему каждый вид необходим — причины, указанные в схеме оценивания. Исправление: пользователь сообщает об ошибке после выпуска, или замечается неверный вывод в определенных условиях, не покрытых тестированием. Адаптация: обновляется операционная система, оборудование или браузер; меняется закон или корпоративное правило (ставки налогов, требования защиты данных); программа должна работать с новой внешней системой или форматом файлов. Совершенствование: пользователи просят добавить функции или улучшить интерфейс; программу делают быстрее или уменьшают потребление памяти; код чистится для облегчения будущих изменений.

Разобранный пример. (a) Выпущенная программа выдает неверное значение в определенных обстоятельствах. (b) Аппаратное обеспечение, на котором работает программа, заменяется. (c) Клиенты просят программу лояльности кофейни отправлять сообщение в день рождения клиента. Назовите вид технического обслуживания в каждом случае.

(a) Исправление — устраняется неисправность в поставленной программе. (b) Адаптация — программа изменяется для работы в новой среде. (c) Совершенствование — добавляется функция в уже работающую программу.

При задаче добавить функцию или исправить ошибку:

1. прочитайте существующий код, пока не поймете алгоритм и поток данных.
2. найдите место для изменений — какую подпрограмму, какие строки.
3. минимизируйте изменения — не переписывайте работающий код.
4. обновите связанные части — каждого вызывателя измененного списка параметров, каждую рутину, использующую измененную структуру данных.
5. протестируйте новое поведение и старое (регрессионное тестирование — убедитесь, что ничего не сломалось).
6. задокументируйте изменение.

Четкие комментарии, осмысленные имена, декомпозированные подпрограммы и структурная диаграмма делают программу гораздо легче редактировать — именно поэтому инструменты проектирования важны даже после первого релиза.

Анализ программы, которую вы не писали. Начните с таблицы идентификаторов и заголовков модулей: они показывают, что получает и возвращает каждый модуль, еще до того как вы прочтете строку его тела. Затем проследите алгоритм с помощью таблицы трассировки для одного небольшого входного значения, отмечая, откуда берется каждое выходное значение. Только затем решите, куда вносить улучшение — обычно это новый модуль, вызываемый из существующего, чтобы минимизировать вмешательство в работающий код — и напишите псевдокод для изменения и тестовые данные, которые это подтвердят.

Вопросы на определение оцениваются по фиксированной формулировке. Выучите их точно и дайте только один ответ.

• Сравнивайте модели разработки (водопад, итеративная, RAD) по принципу, преимуществу, недостатку и знайте пять этапов жизненного цикла разработки программы и то, что производит каждый из них.
• Различайте синтаксические, логические и ошибки времени выполнения по моменту их проявления: при переводе, в выводе, во время выполнения.
• Выбирайте тестовые данные всех видов — нормальные, ненормальные, экстремальные и граничные — и указывайте для каждого значения его обоснование и ожидаемый результат.
• Различайте виды сопровождения (исправляющее, адаптивное, совершенствующее) по причине внесения изменений.
• На структурной диаграмме назовите каждый символ: прямоугольник, линия вызова, пара данных, пара управления, ромб выбора, стрелка итерации. Читая заголовки модулей с диаграммы, помните, что функция имеет RETURNS.

Распространенные ошибки

• Описывать этап жизненного цикла только по названию (например, «на этапе проектирования программа проектируется»). Нужно указать, что производится: структурная диаграмма, псевдокод, план тестирования.
• Называть неправильный вывод «ошибкой времени выполнения». Если программа выполняется до конца, это логическая ошибка.
• Давать граничные данные только как крайние значения. Балл требуется за значения с обеих сторон границы.
• Равнозначно рассматривать альфа- и бета-тестирование. Альфа-тестирование проводится внутри компании разработчиками; бета-тестирование — реальными пользователями вне команды.
• Путать адаптивное и совершенствующее сопровождение. Адаптивное реагирует на изменения вне программы; совершенствующее улучшает программу, которую никто не был вынужден менять.
• Рисовать структурную диаграмму с модулями в любом порядке. Они читаются слева направо в порядке вызова, и каждому параметру нужна своя стрелка.