Программные продукты и системы

Современная практика разработки программного обеспечения (ПО) подразумевает регламентацию всего процесса создания ПО, что делает предсказуемым процесс и результаты разработки. Автором разработан метод создания Интернет-ресурсов под названием i.Portal MSE (i.Portal model-based software engineering), регламентирующий управление процессом разработки веб-приложений для CMS i.Portal и ориентированный в первую очередь на небольшие группы разработчиков. В методе выделяются несколько уровней, рассмотрим один из них, отвечающий за качество готового решения.

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

Рассмотрим каждое из мероприятий более подробно.

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

·     Все члены команды разработчиков должны ежедневно предпочтительно письменно готовить отчет о деятельности за текущий день. При этом отчет должен содержать в соответствии с i.Portal MSE следующие разделы:

-    описание выполненных работ с указанием функционала, над которым выполняется в настоящий момент работа, степень готовности функционала (обязательно указание требования заказчика, над которым в настоящий момент ведется работа);

-    описание возникших в течение дня проблем, требующих решения (для обмена опытом с командой разработчиков);

-    описание задач, которые планируется решить на следующий рабочий день.

·     Должны проводиться планерки (не реже двух раз в неделю), подразумевающие личное общение участников команды разработки.

·     В обязательном порядке должен выполняться план билдов и релизов. Ответственность  за контроль выполнения плана возлагается на менеджера проекта.

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

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

·     X – расстояние от вершины треугольника «Срок разработки» до некоторой определенной нами точки в нем; с увеличением X время, требуемое на разработку программного продукта, увеличивается;

·     Y – расстояние от вершины треугольника «Стоимость разработки» до некоторой определенной нами точки в нем; с увеличением Y стоимость разработки программного продукта увеличивается;

·     Z – расстояние от вершины треугольника «Качество разработки» до некоторой определенной нами точки в нем; с увеличением Z качество разрабатываемого решения уменьшается.

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

Заказчика могут удовлетворить не все точки в пределах треугольника. Область, в пределах которой согласен работать заказчик, обозначена кругом. При этом в договоре на разработку по схеме фиксированной оплаты (fixed costs) из множества возможных вариантов заказчик, как правило, выбирает лишь одну точку.

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

Риски можно классифицировать, исходя из их источника.

·     Риски, связанные с требованиями к разрабатываемому программному продукту. Примером такого риска может служить требование: необходимо, чтобы решение обеспечивало готовность 99,999 %.

·     Риски, связанные с архитектурой программного решения.

·     Риски, связанные с программной реализацией. К данному классу рисков можно отнести ошибки в программном коде.

·     Риски, связанные с аппаратным обеспечением, могут проявляться в невозможности использования аппаратной платформы, которую планирует использовать заказчик, на этапе разработки.

·     Риски, связанные с использованием сторонних (готовых) программных продуктов. Для исключения подобных рисков необходимо привлечение экспертов.

В крупных проектах, срок реализации которых превышает 3 месяца, i.Portal MSE требует создания формального документа «Методика управления рисками». Он должен включать в себя три секции: перечень выявленных рисков, методики предотвращения рисков и методики устранения последствий рисков.

Верификация интерфейса системы заказчиком на соответствие требованиям. Ни для кого не является секретом, что от 70 до 90 % претензий заказчика  к программному продукту заключаются в неудовлетворенности интерфейсом пользователя. При этом около 60 % из них сводятся к мелким исправлениям текстов и рисунков, а остальные связаны с последовательностью выполнения определенных действий.

i.Portal MSE в уровень управления качеством включает мероприятие по согласованию с заказчиком экранных форм.

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

Внутреннее альфа-тестирование программного продукта подразумевает выделение отдельного сотрудника или группы для проведения функционального тестирования программного продукта.

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

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

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

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

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

Организация сервисного сопровождения системы. Все ошибки, найденные в разрабатываемом программном продукте, в соответствии с i.Portal MSE должны быть занесены в единую систему отслеживания ошибок.

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

-    создания отчетов об ошибке членами команды по разработке и представителями заказчика, причем создание отчета об ошибке не должно требовать особых навыков по работе с ПО;

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

-    привязки неисправностей к плану билдов и релизов с целью регламентировать процесс исправления ошибок во времени;

-    привязки неисправностей к системе контроля версий исходного кода ПО.

Если неисправность была устранена, то при загрузке изменений в комментарии обязательно должен быть указан идентификатор неисправности в системе управления неисправностями.

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