Разработка программного продукта

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

Разработка программного продукта часто начинается с создания его рабо­тающего прототипа, содержащего минимальную функциональность и стро­гое оформление пользовательского интерфейса. Прототип демонстрируется заказчику. Заказчик одобряет его или вносит свои замечания, изменения и дополнения. Рабочий проект корректируется в соответствии с этими заме­чаниями и процесс разработки продолжается.

Каждый этап разработки завершается показом результатов заказчику. В ра­бочем проекте определяется набор приемо-сдаточных испытаний продукта на каждом этапе. Этот набор выполняется в присутствии заказчика. Про­смотрев результаты приемо-сдаточных испытаний, заказчик, как правило, вносит свои замечания в проект. Рабочий проект корректируется и разра­ботка продолжается.

Качество и своевременность разработки во многом определяются качеством ее планирования. Тщательно написанный рабочий проект дает возможность программистам сосредоточиться на выполнении проекта, равномерно рас­пределить свои усилия, не отвлекаться на переделки и доработки. Проект, полностью согласованный с заказчиком, почти не меняется. Это позволяет строго следовать этапам разработки, переходить от одного этапа к другому, не возвращаясь к уже законченному и полузабытому коду, написанному на предыдущих этапах.

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

Отладка

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

Процесс нахождения и ликвидации ошибок называется отладкой (debugging). Интересно происхождение английского термина, который бук­вально переводится как "устранение жуков". Он возник на заре развития компьютеров, когда никак не могли найти ошибку в одной программе. По­сле долгих поисков оказалось, что в аппаратуру заполз жучок и замкнул электрические проводники таким хитрым образом, что это вызывало ошиб­ку. С тех пор ошибки в программе на жаргоне называются "багами".

Отладка отнимает довольно много времени. По разным оценкам на нее ухо­дит от трети до половины всего времени реализации проекта, поэтому сле­дует серьезно отнестись к этому процессу.

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

Следует серьезно отнестись к выбору языка программирования. Низкоуров­невые языки, такие как язык ассемблера или языки вроде C/C++, дают программисту очень много возможностей, но неразумное использование этих возможностей приводит к очень большому количеству ошибок. Эти ошибки, к тому же, трудно обнаружить и устранить. Языки высокого уров­ня, такие как Java, С# и другие, напротив, ограничивают действия про­граммиста, но предотвращают появление ошибок.

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

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

Ввиду особой важности отладки программного продукта мы рассмотрим этот процесс подробнее в следующей главе.

Тестирование

Некоторые ошибки нелегко выявить, поэтому на каком-то этапе разработки необходимо остановиться и провести тщательное и всеобъемлющее тести­рование (testing) программного продукта. Тестирование заключается в том, что работа программы проверяется на ряде задач, решение которых извест­но заранее. Результаты работы программы сравниваются с эталонными ре­зультатами, и на основании их совпадения делается вывод о применимости программы к этому классу задач. Кроме того, в процессе тестирования час­то проверяется исходный текст программы, что позволяет найти ошибки в алгоритме решения задачи.

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

Тестирование не следует путать с отладкой. Задача тестирования — выявить наличие дефектов в программе, а задача отладки — отыскать их местополо­жение и устранить.

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

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

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

Более подробно о методах тестирования мы поговорим в следующей главе.

Сопровождение продукта

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

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

При обнаружении ошибок в программном продукте приходится исправлять программный код, отлаживать и тестировать соответствующие модули и за­ново устанавливать продукт у потребителя. Если продукт уже пошел в се­рию и установлен во многих местах, то приходится писать программу, уста­навливающую "заплатку" (patch), именуемую на жаргоне "патчем", на программном продукте и рассылать ее всем потребителям вместе с извине­ниями и инструкцией по установке.

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

Модификация продукта

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

Модификация программного продукта предполагает его переделку, зачастую довольно значительную. Поэтому всю работу по созданию продукта прихо­дится пройти заново. Модификация начинается с определения новых тре­бований к продукту. Затем проектируется новая версия продукта. При этом устанавливается, какие модули останутся без изменений, а какие подверг­нутся изменению, удалению или полной замене. Тут же оценивается объем изменений и время, необходимое для этого. Кроме того, определяется, ка­кие новые модули надо добавить к программному продукту.

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

Многие фирмы-разработчики различают новую версию продукта и его незна­чительную модификацию. Они отмечают каждый новый выпуск продукта дву­мя числами, записанными через точку, например, OurProduct v.1.1, CoolPro- duct 2.3. Первое число означает номер версии продукта, второе — число модификаций данной версии. Какие изменения приводят к выпуску новой версии, а какие считаются только модификацией, решает сама фирма. Некото­рые фирмы считают своим долгом выпускать новую версию каждый год, даже если в нее внесены только косметические изменения графического интерфейса с пользователем. Конкурирующие фирмы стараются увеличить номер версии своего продукта, чтобы создать впечатление его зрелости и солидности.

Иногда оба числа означают номер версии, говорят: "Версия 3.2 нашего про­дукта". В такой нумерации первым числом отмечается "выпуск" (release) программного продукта. Его увеличение означает сильное изменение про­дукта и происходит не так часто, как появление новой версии.

Некоторые программные продукты отмечаются тремя числами. К номеру версии и модификации добавляется число заплаток, наложенных на данную модификацию. Так, например, нумеруется ядро Linux. Запись "Linux 2.6.5" означает "ядро версии 2.6, на которое наложено 5 патчей".