<<
>>

Возможность адаптации результатов к изменениям бизнеса потребителя

Процесс проектирования ИС — систематический способ продвижения от абстрактных пожеланий и концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей {User Profiles), которые описывают различные типы пользователей и их рабочие функции.

Значительная часть этой работы часто проводится во время фазы выработки концепции.

Затем формируется набор сценариев использования (Usage Scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя.

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

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

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

Снижение вероятности возникновения дефектов

Тема испытаний и тестирования во всех моделях СМК занимает особое место, и написано на эту тему уже очень много.

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

Самым понятным действием для обеспечения качества ИТ-проекта, конечно, является увеличение степени покрытия тестовыми сценариями функциональности внедряемой системы до 100 %.

Как этого достигнуть? Немного вспомним теорию [11]. Сообществом тестировщиков и практической работой выделены основные типы тестов (рис. 2.10).

Современные руководства, такие как MSF [5], выделяют следующие рекомендации к разработке тестов:

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

• совокупность ранее созданных тестов должна (при неизменных требованиях) выполняться на любой версии программы;

• если в требования вносятся изменения, то тесты должны меняться максимально оперативно.

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

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

И это очень важно как раз для качества проекта в целом из-за снижения трудозатрат на переделки.

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

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

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

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

Как свидетельствует печальная статистика [11], каждое исправление ошибки имеет 15 % вероятности породить новую ошибку. Поэтому надо взять за правило — чем раньше спроектирован тест, тем больше надежда на успех.

И лучше всего спроектировать тест еще на этапе логического построения системы. Но скажем честно: программисты ненавидят тестирование.

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

Поэтому на практике критерием успешности тестирования служит достижение точки конвергенции (Bug Convergence) — когда скорость устранения ошибок начинает превосходить скорость их обнаружения (рис.

2.11).

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

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

Точка достижения нуля (Zero-bug Bounce) — это момент, когда впервые все выявленные ошибки оказываются устраненными (см. рис. 2.11). Вслед за ней пики количества активных ошибок должны уже становиться все меньше и меньше вплоть до полного угасания в момент, когда бизнес-решение уже достаточно стабильно для выпуска.

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

И наконец, тестирование приемлемости для потребителей (User Acceptance Testing).

Производятся такие тесты, как правило, начиная с фазы раз-работки и продолжаются вплоть до фазы внедрения.

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

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

Уменьшение вероятности возникновения проблем и ошибок уже в результатах проекта

Решение этой задачи имеет два пути.

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

Второй — более тонкий процесс: внимательный анализ реальной необходимости или уровня сложности требований, который

заявляет «неопытный» потребитель на этапе анализа и подготовки технического задания <ТЗ).

Например, заказчик придумал, будто оператор на складе должен иметь возможность работать на нескольких экранах одновременно. Программисты сказали: «ОК», а система стала постоянно перегружаться и начала подвисать, и ни много ни мало — по нескольку раз в день. Как говорится, «удовлетворили» — без комментариев.

Создание стандартов и методологии выполнения проектов

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

Почему?

Как правило, круг непосредственного взаимодействия высшего руководства — это 5—10 человек, и именно ими «опосредуются» его управление, решения, видение. Именно от них во многом зависит, будут ли совпадать желаемый и реальный результаты управления.

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

тоже получается свой — не тот, который нужен вам и вашей компании.

Именно для предотвращения этих опасностей и возникают документы, определяющие, регламентирующие, распределяющие права и ответственность, — стандарты и регламенты компании по УП.

Только, согласитесь, что без договоренности, внутреннего принятия этих правил это остается просто бумагой. Потому что нет той самой трансляции, внутренней энергии и убежденности в том, что именно это дело является правильным и правильно его надо делать именно так. Вот здесь как раз вам PI помогут требования стандарта ISO 9000 по обеспечению вовлеченности персонала и лидерству руководства [4].

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

Во многих организациях функция УП изначально выросла из инженерных подразделений. Но если она будет базироваться в инженерном подразделении, то это неправильно, потому что функция УП охватывает не только инженерное подразделение, но и все другие функции в компании. Постепенно и пришли к тому, что стали использовать термин ЦУП (центр управления проектами) для обозначения подразделения, в функции которого и входит именно обеспечение качества проектов компании [6, 9].

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

• программисты и коммерсанты говорят и мыслят совершенно разными категориями, поэтому им трудно найти общий язык (см. выше, к вопросу об анализе необходимости требований);

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

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

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

<< | >>
Источник: Ильин, Владислав Владимирович.. Руководство качеством проектов. Практический опыт. 2006

Еще по теме Возможность адаптации результатов к изменениям бизнеса потребителя:

  1. 6. В каких случаях возможно изменение трудового договора?
  2. Бизнес и потребители
  3. ПОЗВОЛЬТЕ ДРУГОЙ СТОРОНЕ СДЕЛАТЬ СТАВКУ НА РЕЗУЛЬТАТ, ПРЕДОСТАВИВ ВЕРНУЮ ВОЗМОЖНОСТЬ УЧАСТВОВАТЬ В ПРОЦЕССЕ
  4. Тема 13. РЕАКЦИЯ ПОТРЕБИТЕЛЯ НА ИЗМЕНЕНИЕ ЕГО ДОХОДА И ЦЕНЫ ПРИОБРЕТЕНИЯ БЛАГ
  5. Возможность «удержания» растущего разнообразия мира и бизнеса, проникающего в наше сознание
  6. ПРАКТИЧЕСКИЙ ОПЫТ. МОЙ ПЕРВЫЙ БИЗНЕСКАК Я УВИДЕЛ ВОЗМОЖНОСТЬ ОРГАНИЗОВАТЬ СВОЙ БИЗНЕС
  7. Бизнес-ясли, Бизнес-школа Бизнес-жизнь...или как избежать Бизнес-смерти
  8. И в life-коучинге, и в бизнес-коучинге вы должны дать клиентам возможность личностного роста
  9. Глава II. Защита прав потребителей при продаже товаров потребителям
  10. 4. СОВЕТЫ ПОТРЕБИТЕЛЮ, ОБРАЗЦЫ ИСКОВЫХ ЗАЯВЛЕНИЙ ПРИ НАРУШЕНИИ ПРАВ ПОТРЕБИТЕЛЕЙ
  11. Глава 15ТРУДОВАЯ АДАПТАЦИЯ РАБОТНИКОВ
  12. АДАПТАЦИЯ
  13. 15.2. Объективные и субъективные факторы трудовой адаптации
  14. 15.1. Сущность и структура трудовой адаптации
  15. 4. АДАПТАЦИЯ ОТКРЫТОЙ ЭКОНОМИКИ К ЭКЗОГЕННЫМ ШОКА
  16. Лекция 20. Проблемы социально-психологической адаптации