Главная | Обратная связь | Поможем написать вашу работу!

Ответственность заказчика

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

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

Оценка эффективности разработки

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

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

Целью разработки новых систем и модификации существующих яв-
ляется повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рас-
смотреть другие варианты мер, влияющих на эффективность организа-
ции (дополнительное обучение сотрудников, реорганизация подразде-
лений, незначительное изменение или всеобъемлющий реинжиниринг
бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта
проблема очень важна, и поэтому она будет детально рассмотрена в
рамках главы «Управление изменениями».

Стадии разработки

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

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

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

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

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

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

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

• описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы):

— детальное описание существующих бизнес-процессов и каким
образом они будут затронуты при внедрении системы;

— детальное описание новых бизнес-процессов, которые будут со-
зданы или получены при изменении существующих;

— описание мер контроля, которые будут внедрены в новой системе;

• описание программно-аппаратного обеспечения, необходимого для функционирования системы:

— операционная система(ы), которая будет использоваться;

— сетевая среда, оборудование и протоколы;

— средства разработки новой системы;

— средства защиты информации;

— как новые платформы будут включены в существующую инфор-
мационную инфраструктуру;

• спецификация функциональности системы:

— общее описание функциональности системы как в повествователь-
ной форме, так и в виде диаграмм;

— разбиение системы на модули;

— соответствие модулей бизнес-требованиям к системе. Должно
быть описано, каким требованиям отвечает каждый модуль. Все биз-
нес-требования должны покрываться модулями системы;

— модель данных, используемая в системе (диаграмма «сущность—
связь» или аналогичные). Функциональность, вынесенная в серверную
часть системы;

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

— детальное описание интерфейсов с другими системами;

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

— список ошибок и предупреждений, генерируемых системой;

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

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

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

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

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

• прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования;

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

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

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

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

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

Разрабатываемое программное обеспечение тщательно тестирует-
ся (методика тестирования будет рассмотрена подробно в следующей
главе). Должен быть разработан план тестирования, который включает
этапы тестирования модулей системы, системы в целом, интерфейсов с
внешними программами, интерфейсов пользователя, тестирование си-
стем безопасности и надежности системы. Согласно этому плану необ-
ходимо разработать набор тестов, которые помимо покрытия функци-
ональных требований к системе (тестирования по методу «черного ящи-
ка») покрывали бы внутреннюю структуру исходного кода (покрытие
условных переходов, метод «белого ящиками).

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

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

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

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

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

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

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

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

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

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

Документ о завершении внедрения системы подписывают заказчик
и разработчик.

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

Глава 7. Тестирование систем

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

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

⇐ Предыдущая 35 36 37 38 394041 42 43 44 Следующая ⇒