Journal influence
Bookmark
Next issue
Abstract:
Аннотация:
Author: () - | |
Ключевое слово: |
|
Page views: 10478 |
Print version Full issue in PDF (2.31Mb) |
Современная практика разработки программного обеспечения (ПО) подразумевает регламентацию всего процесса создания ПО, что делает предсказуемым процесс и результаты разработки. Автором разработан метод создания Интернет-ресурсов под названием i.Portal MSE (i.Portal model-based software engineering), регламентирующий управление процессом разработки веб-приложений для CMS i.Portal и ориентированный в первую очередь на небольшие группы разработчиков. В методе выделяются несколько уровней, рассмотрим один из них, отвечающий за качество готового решения. Уровень управления качеством разрабатываемого программного решения включает в себя следующие обязательные мероприятия: управление процессом разработки; разработка пакета автоматизированных модульных и функциональных тестов; верификация интерфейса системы заказчиком на соответствие требованиям; внутреннее альфа-тестирование программного продукта; организация сервисного сопровождения системы; а также факультативные: управление рисками; внешнее бета-тестирование программного продукта заказчиком. Рассмотрим каждое из мероприятий более подробно. Управление процессом разработки подразумевает комплекс мероприятий по контролю над процессом подготовки программного кода. Основная задача этого мероприятия – сделать процесс разработки управляемым и предсказуемым, для чего на этапе доработки каркаса приложения применяются agile-методики разработки. При этом i.Portal MSE предполагает выполнение следующих требований. · Все члены команды разработчиков должны ежедневно предпочтительно письменно готовить отчет о деятельности за текущий день. При этом отчет должен содержать в соответствии с i.Portal MSE следующие разделы: - описание выполненных работ с указанием функционала, над которым выполняется в настоящий момент работа, степень готовности функционала (обязательно указание требования заказчика, над которым в настоящий момент ведется работа); - описание возникших в течение дня проблем, требующих решения (для обмена опытом с командой разработчиков); - описание задач, которые планируется решить на следующий рабочий день. · Должны проводиться планерки (не реже двух раз в неделю), подразумевающие личное общение участников команды разработки. · В обязательном порядке должен выполняться план билдов и релизов. Ответственность за контроль выполнения плана возлагается на менеджера проекта. Управление рисками. При разработке ПО существует множество причин, вследствие которых проект может быть не выполнен в сроки, может быть превышен бюджет либо качество готового решения может оказаться очень низким. Рассмотрим модель, включающую эти три составляющие более подробно. Графическое обобщение данной модели приведено на рисунке. В модели треугольником обозначается теоретическое множество значений, которые могут принимать рассматриваемые параметры. При этом любая из точек в пределах треугольника определяет некоторое соотношение между сроком разработки, качеством готового продукта и его стоимостью. Данные параметры определяются следующим образом: · · Y – расстояние от вершины треугольника «Стоимость разработки» до некоторой определенной нами точки в нем; с увеличением Y стоимость разработки программного продукта увеличивается; · Z – расстояние от вершины треугольника «Качество разработки» до некоторой определенной нами точки в нем; с увеличением Z качество разрабатываемого решения уменьшается. Следует понимать, что на модели приведены абстрактные расстояния и области, не представляющие реальный проект. Кроме того, масштаб каждой из величин и форма областей могут варьироваться от проекта к проекту. Заказчика могут удовлетворить не все точки в пределах треугольника. Область, в пределах которой согласен работать заказчик, обозначена кругом. При этом в договоре на разработку по схеме фиксированной оплаты (fixed costs) из множества возможных вариантов заказчик, как правило, выбирает лишь одну точку. Управление же рисками в пределах проекта по разработке заключается в предотвращении выхода точки, соответствующей текущему состоянию разработки, за пределы окружности, которая удовлетворяет заказчика. Для этого осуществляется поиск причин появления рисков и вырабатываются методики их преодоления, что приводит к повышению качества как процесса разработки, так и готового продукта. Риски можно классифицировать, исходя из их источника. · Риски, связанные с требованиями к разрабатываемому программному продукту. Примером такого риска может служить требование: необходимо, чтобы решение обеспечивало готовность 99,999 %. · Риски, связанные с архитектурой программного решения. · Риски, связанные с программной реализацией. К данному классу рисков можно отнести ошибки в программном коде. · Риски, связанные с аппаратным обеспечением, могут проявляться в невозможности использования аппаратной платформы, которую планирует использовать заказчик, на этапе разработки. · Риски, связанные с использованием сторонних (готовых) программных продуктов. Для исключения подобных рисков необходимо привлечение экспертов. В крупных проектах, срок реализации которых превышает 3 месяца, i.Portal MSE требует создания формального документа «Методика управления рисками». Он должен включать в себя три секции: перечень выявленных рисков, методики предотвращения рисков и методики устранения последствий рисков. Верификация интерфейса системы заказчиком на соответствие требованиям. Ни для кого не является секретом, что от 70 до 90 % претензий заказчика к программному продукту заключаются в неудовлетворенности интерфейсом пользователя. При этом около 60 % из них сводятся к мелким исправлениям текстов и рисунков, а остальные связаны с последовательностью выполнения определенных действий. i.Portal MSE в уровень управления качеством включает мероприятие по согласованию с заказчиком экранных форм. Подготовка экранных форм для согласования осуществляется в графическом редакторе на основе выявленных функциональных требований. Все экранные формы проверяются менеджером проекта на соответствие требованиям заказчика, после чего передаются последнему. Внутреннее альфа-тестирование программного продукта подразумевает выделение отдельного сотрудника или группы для проведения функционального тестирования программного продукта. Важно, что данное мероприятие не может выполняться программистами, разрабатывающими программный продукт, так как они не в состоянии в полной мере воспроизвести все сценарии использования программного продукта, которые могут быть реализованы пользователем. Тем самым не исключена возможность пропуска значимой ошибки, которую может выявить независимый тестировщик. Задача тестировщика заключается в проверке безошибочной реализации всех прецедентов, которые были выявлены на уровне управления требованиями. При этом желательно, чтобы проводимые в ручном режиме тесты были превращены в автоматические функциональные тесты на базе Selenium. Внешнее бета-тестирование программного продукта заказчиком называется также опытной эксплуатацией программного продукта. В рамках этого мероприятия проводится обучение ключевых пользователей заказчика и проверка ими реализованного функционала. Основная задача данного этапа заключается в выявлении всех сценариев использования решения исполнителями заказчика. Оно может привести как к выявлению противоречий и ошибок в интерфейсе, так и к нахождению серьезных ошибок в программном коде, так как члены команды разработчиков не предполагали сценарий использования, который применили у заказчика. Важно, чтобы ошибки подобного рода были выявлены до внедрения ПО в промышленную эксплуатацию, так как часто это может приводить к непредсказуемым последствиям. Организация сервисного сопровождения системы. Все ошибки, найденные в разрабатываемом программном продукте, в соответствии с i.Portal MSE должны быть занесены в единую систему отслеживания ошибок. В настоящий момент автор с коллегами использует для этого Интернет-приложение для управления жизненным циклом ПО под названием TRAC. Однако на рынке представлено множество как бесплатных, так и коммерческих продуктов, обеспечивающих данный функционал. В рамках предлагаемого автором метода не регламентируется использование определенного продукта, однако фиксируются требования к функционалу, который он предоставляет. Они включают в себя возможности: - создания отчетов об ошибке членами команды по разработке и представителями заказчика, причем создание отчета об ошибке не должно требовать особых навыков по работе с ПО; - назначения определенного члена команде по разработке приложения для устранения неисправности, тем самым создается персонифицированная ответственность за неисправности и улучшается контроль над их исправлением; - привязки неисправностей к плану билдов и релизов с целью регламентировать процесс исправления ошибок во времени; - привязки неисправностей к системе контроля версий исходного кода ПО. Если неисправность была устранена, то при загрузке изменений в комментарии обязательно должен быть указан идентификатор неисправности в системе управления неисправностями. Таким образом, предлагаемые шаги ориентированы на повышение качества готового решения, что позволит в полной мере удовлетворить ожидания заказчика программного продукта. |
Permanent link: http://swsys.ru/index.php?id=336&lang=en&page=article |
Print version Full issue in PDF (2.31Mb) |
The article was published in issue no. № 3, 2007 |
Perhaps, you might be interested in the following articles of similar topics:
- Разработка загрузчика программного обеспечения встроенной системы управления
- Учебный банк: технологии изучения банковских систем и телекоммуникаций
- Гибридная экспертная система проектирования ресурсосберегающих установок первичной нефтепереработки
- Интерактивная процедура построения модели тренда для экономических показателей
- Метод интегрированного описания топологических отношений в геоинформационных системах
Back to the list of articles