CC BY
102
формационные потоки. Она состоит из двух основных контуров, при этом каждый контур управления характеризуется своим уровнем интенсивности циркулирующей в нем информации, масштабом времени и набором функций.
3. Контуры управления: технологический - самый интенсивный по объему информации и жесткий по времени реагирования; оперативно-производственный - опирается на отфильтрованную и обработанную информацию, поступающую как от технологического контура, так и от других служб производства (технических, планово-производственных, экономических и т.д.).
4. Данные для анализа содержат модули которые закрепляют форматы представления внутрисистемных регламентов, а также задают форматы описания объектов наблюдения (объемные и качественные показатели основных технологических циклов, формирования прямых производственных затрат на различных этапах производственного цикла, остатки товарно-материальных средств на складах и пр.).
5. Аналитическая подсистема представляет собой различные программы анализа, использующие БД исполнительной подсистемы. Работа аналитической подсистемы основана на принципах отслеживания граничных параметров допустимых характеристик ведения производственного процесса в каждом технологическом цикле в режиме реального времени.
В результате объединения подсистем получена замкнутая информационно-аналитическая система, которая реализует стандартный управленческий цикл: сбор информации, анализ, выработку решения, организацию, контроль, регулирование. Все подсистемы дают полное взаимосвязанное описание предприятия. Изменение любой из них неотвратимо вызывает соответствующие изменения в других подсистемах.
Система содержит в себе контур управления с участием ЛПР, что практически однозначно относит эту систему к классу RTE. При этом еще на концептуальном уровне разработки система не была привязана к конкретным программно-аппаратным плат-
формам, что позволит легко адаптировать и/или перепроектировать отдельные модули под специфику горнорудного предприятия.
Разработанная информационно-аналитическая система встраивается в любую ИС управления горнорудным предприятием. При этом происходит непосредственное взаимодействие с аналитической подсистемой, значительно расширяя ее возможности. К существующим функциям мониторинга аналитической подсистемы ИСУП добавляются рекомендательные функции, разрабатываемые на основе нового подхода к разработке оптимальной стратегии управления горнорудным предприятием в структуре компании.
Информация, необходимая для функционирования информационно-аналитической системы выбора оптимальной стратегии управления горнорудным предприятием в структуре компании подготавливается, собирается, хранится и обрабатывается в различных структурных подразделениях, реализующих определенный этап технологического цикла предприятия. Детальность представления информации локализуется на производственных участках предприятия и может быть дополнена руководителями различных уровней. Заполнение БД организованно с использованием конвектора, обеспечивающего передачу и адаптацию информации из БД предприятия.
Внедрение и апробация информационно-аналитической системы разработки оптимальной стратегии управления горнорудным предприятием на различных этапах технологического цикла проходили на горно-металлургическом комбинате, добывающем и перерабатывающем медно-никелевые руды и являющимся крупнейшим в России предприятием по добыче и обогащению никеля и производству высококачественного металлургического сырья. Использование разработанной информационно-аналитической системы позволит ЛПР повысить качество стратегических инвестиционных решений, принимаемых в условиях параметрической неопределенности - неполноты информации о параметрах внешней и внутренней среды предприятия как производственной системы.
МЕТОД СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ I.PORTAL ИББ И КОНТРОЛЬ КАЧЕСТВА ПРОГРАММНОГО ПРОДУКТА В НЕМ
К.С. Лебедев (Иркутск)
Современная практика разработки программного обеспечения (ПО) подразумевает регламентацию всего процесса создания ПО, что делает предсказуемым процесс и результаты разработки. Автором разработан метод создания Интернет-ресурсов под названием 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. Однако на рынке представлено множество как бесплатных, так и коммерческих продуктов, обеспечивающих данный функционал. В рамках предлагаемого автором метода не регламентируется использование определенного продукта, однако фиксируются требования к функционалу, который он предоставляет. Они включают в себя возможности:
- создания отчетов об ошибке членами команды по разработке и представителями заказчика, причем создание отчета об ошибке не должно требовать особых навыков по работе с ПО;
- назначения определенного члена команде по разработке приложения для устранения неисправности, тем самым создается персонифицированная ответственность за неисправности и улучшается контроль над их исправлением;
- привязки неисправностей к плану билдов и релизов с целью регламентировать процесс исправления ошибок во времени;
- привязки неисправностей к системе контроля версий исходного кода ПО.
Если неисправность была устранена, то при загрузке изменений в комментарии обязательно должен быть указан идентификатор неисправности в системе управления неисправностями.
Таким образом, предлагаемые шаги ориентированы на повышение качества готового решения, что позволит в полной мере удовлетворить ожидания заказчика программного продукта.
