Программный код должен быть отформатирован в едином стиле. В общем случае утвержденные и используемыми всеми разработчиками стандарты кодирования содержат следующие составляющие:
18.3. Ответственность заказчика
Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, - контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.
Ответственность за разработку систем помимо назначенных сотрудников или консультантов несут соответствующие руководители подразделений или организации в целом.
Масштаб и степень следования стандартам разработки программного обеспечения могут зависеть от размера и характера проекта, а также от того, какие инструменты разработки используются. Для небольших, некритичных для бизнеса приложений необходимость строгого следования стандартам может быть не так важна. Однако для больших и чувствительных с точки зрения бизнеса проектов, где велика стоимость разработки и появляются большие риски, необходимы максимальный контроль за процессом разработки и следование стандартам программирования.
В любом случае затраты и усилия, потраченные на разработку, должны соответствовать уровню решаемых с помощью системы проблем. Стоимость проекта должна оцениваться с точки зрения его важности и выгоды от использования разработанной системы.
Целью разработки новых систем и модификации существующих является повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рассмотреть другие варианты мер, влияющих на эффективность организации (дополнительное обучение сотрудников, реорганизация подразделений, незначительное изменение или всеобъемлющий реинжиниринг бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта проблема, управления изменениями, очень важна, и заслуживает самостоятельного рассмотрения.
Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы.
Этап инициации проекта. С точки зрения разработчика, этап должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик - организация в целом, то руководителей организации.
Этап оценки проекта. Первоначальные требования к системе направляются, как правило, в ИТ-подразделение, которое оценивает факторы, критичные для успеха проекта и его качества. Необходимо выяснить, насколько проект согласуется с общей стратегией банка в области развития бизнеса и использования информационных технологий, приблизительно оценить общие затраты на проект, а также каким образом и кем должен осуществляться контроль над проектом. Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них.
В направлении дальнейшей детализации необходимо выбрать несколько вариантов реализации программного обеспечения и точно оценить стоимость каждого варианта, трудности, связанные с его осуществлением, время на осуществление, программные средства и инструменты, необходимые для проекта, исполнителей проекта, а также преимущества каждого варианта. Кроме того, требуется описать недостатки существующей системы и как они будут устранены при внедрении нового программного обеспечения. В итоговую оценку необходимо включить меры по изменению бизнес-процессов и структуры организации, которые сопровождают внедрение системы. Детальную оценку проекта осуществляет ИТ (проектная команда), заказчик выбирает окончательный вариант решения. Итоговый документ должен быть подписан заказчиком и проектным руководством, руководителем ИТ.
Этап анализа и проектирования. Этап анализа и проектирования включает в себя разработку проектной документации, в деталях описывающей работу будущей системы, ее структуру, технические и программные средства, необходимые для ее функционирования. Этот этап важен для облегчения дальнейшей работы над системой. Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать:
Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику. Написание подробных спецификаций (постановку задачи) можно заменить использованием методики создания прототипов. При этом прогрессивном методе используется итерационный подход. Описание будущее системы производится через согласование интерфейсов пользователя с системой. С будущими пользователями системы обсуждаются и утверждаются экранные формы, соответствующие различным функциям системы. Вместе с внешним видом этих форм описываются соответствующие им входные и выходные данные. Другими словами, время на подготовку документов практически не тратится, пользователь рассказывает, что ему нужно, разработчик создает модель и презентует ее пользователю, который высказывает свои замечания и т.д., пока решение (или по крайней мере его внешний вид) не согласовывается. Выгодой этого подхода являются меньшие сроки разработки системы, следовательно, меньшие затраты на разработку.
Решение об использовании методики создания прототипов принимается до начала этапа анализа и проектирования, на этапе выбора варианта реализации системы. При принятии решения должны быть оценены следующие риски:
Система должна согласовываться с формальными требованиями к ней. В случае внесения существенных изменений в систему, не описанных в проектной документации, эти изменения должны быть согласованы с заказчиком и внесены в спецификации.