Сегодня люди не испытывают трепета перед отделами ИС, и это значит, что службы эти могут стать жертвами таких неприятных процедур, как сокращение штатов и уменьшение объема заказов.
Поэтому многие компании стремятся внедрить у себя самые лучшие методы разработки программного обеспечения.
Институт проектирования программного обеспечения (Software Engineering Institute - SEI), входящий в состав университета Carnegie Mellon, создал полную модель разработки программного обеспечения (Maturity Model for Software), согласно которой все организации подразделяются на пять уровней. На первом уровне каждый проект рассматривается как абсолютно новая задача. На пятом уровне все действия заранее расписаны, и происходит непрерывный процесс усовершенствования.
По данным на сентябрь 1995 года, разработки 70% фирм из 400 находятся на первом уровне, и менее чем в 1% организаций достигли четвертого уровня (показателем этого является надежное управление качеством ПО и процессами разработки). И лишь одно-единственное предприятие добралось до вожделенного пятого уровня.
Также выведены показатели некой усредненной организации, занимающейся информационными системами. Они доказывают невысокий уровень разработок такой фирмы. Кэйперс Джоунс, глава фирмы Software Productivity Research, разрабатывающей ПО, собрал данные о самых выдающихся успехах и самых страшных провалах по шести различным категориям: системное ПО, контролирующее физические устройства, например компьютеры или телефоны; ПО, выпущенное для военных целей; информационные системы, предназначенные для внутреннего использования; ПО для независимого сопровождения; коммерческое ПО, разработанное для дальнейшей продажи на рынке; ПО для конечного пользователя, то есть для людей, не занимающихся программированием профессионально.
Джоунс установил, что среди перечисленных типов ПО информационные системы самые невезучие в плане соотношения количества успехов и количества провалов.
Одной из причин частых неудач информационных систем Джоунс называет несогласованность, возникающую из-за постоянных изменений требований со стороны заказчика. Эту точку зрения разделяет Джеррольд Грочоу, технический директор Центра современных технологий фирмы American Management Systems (AMS), чья компания не только консультирует организации, занимающиеся информационными системами, но и выполняет самостоятельные разработки.
В качестве противоядия AMS разработала "Руководство администратора", которое сам Грочоу называет "одной из лучших методик". Она подсказывает администратору, каким образом собрать в одном месте всю информацию относительно проекта, включая контракт и все вносимые изменения.
"Подгонка формального метода разработки и интеграция его с технологией управления могут значительно улучшить процесс создания программного обеспечения", - говорит Брендан Конвей из Gartner Group.
"Однако слепое следование методологии не решит всех проблем, - добавляет Грочоу. - В нашей книге есть очень важный совет: в отличие от книги "о вкусной и здоровой пище" здесь не обязательно точно следовать всему, что написано. Искусство администратора состоит в умении определять, когда следовать "рецепту", а когда нет".
Однако, с другой стороны, Дэвид Зуброу, возглавляющий в SEI группу анализа и проектирования ПО, опасается, что, как только разработчики определятся с методом, их перестанет интересовать дальнейшее его совершенствование.
Разграничение времени
Вовлечение пользователей в процесс разработки - это палка о двух концах. Такие методы, как совместная разработка (когда администраторы, пользователи и разработчики совместно вырабатывают набор средств и функций приложения) и пошаговая разработка (когда постоянно поддерживается связь между пользователем и разработчиком), помогают создавать системы, более полно отвечающие запросам клиента. Но при этом пользователи постоянно расширяют свои требования. Чтобы удерживать эти требования в определенных пределах, многие администраторы применяют так называемый метод "разграничения времени". Весь проект разбивается на несколько этапов, а когда время, отведенное на какой-либо этап истекает, подводится итог сделанному, и все переходят к следующему шагу. Метод "разграничения времени" не только позволяет концентрировать усилия группы разработчиков, но и уменьшает несогласованность.
Характер применения
Перед началом разработки необходимо точно представлять себе характер применения разрабатываемого ПО. Например, предназначена ли система для работы без предварительного обучения, или, наоборот, прежде чем начать непосредственное знакомство с ней, придется прочитать сто страниц документации. Определение характера применения, разработка пользовательского интерфейса и дальнейшее привлечение пользователей - существенная часть метода разработки.
Контроль качества
Множество исследований показали, что чем раньше обнаружена ошибка, тем дешевле обходится ее исправление. Очень часто разработчики дожидаются момента, когда приложение будет почти полностью готово, и только после этого представляют его пользователям. Тем самым они лишают себя возможности вовремя получить важную информацию. Зуброу настаивает на проведении промежуточных проверок, которые помогают обнаруживать ошибки до завершения написания программы, то есть во время тестирования. Неверно истолкованные требования заказчика могут повлечь за собой ошибки, которые впоследствии будут пропущены компилятором.
Повторно используемые компоненты
Идея возможности соединения и подгонки различных готовых компонент систем уже породила целую отрасль промышленности. При этом не обязательно покупать компоненты у других производителей. "Разработка приложений с использованием готовых компонент удобна, если мы будем работать с этой системой и в дальнейшем. В настоящее время регулярно происходит обмен такими компонентами между более чем 80 компаниями", - говорит Нина Бабирад, начальник отдела пользовательских систем страховой компании Zurich Canada в Торонто. Основной причиной такой стратегии в Zurich Canada стало желание сократить срок сдачи в эксплуатацию продукта или его частей. Появилась возможность в случае необходимости своевременно поставлять отдельные готовые компоненты приложений. Еще одно преимущество такого подхода, по словам Бабирад, - возможность гибкой перестройки составляющих без нарушения целостности архитектуры всей системы.
Составление метрик и оценок
Другой способ улучшить качество продукта - отслеживать соотношение количества дефектов, найденных и исправленных до сдачи заказчику, и количества ошибок, найденных заказчиком. Конвей советует накопить всю информацию о проводимых проектах, чтобы в дальнейшем учитывать ее при разработке других систем.
Неверная оценка эффективности работы служащих, денежных и временных затрат, может испортить даже самый лучший метод. Конвей советует в этом случае как можно чаще делать оценки на основе уже имеющихся данных. Например, одна оценка может быть основана на накопленном опыте, другая на предполагаемом объеме работ, третья - на основе формальных вычислений. "В конце проекта вам необходимо сравнить фактические результаты с расчетными величинами, чтобы в дальнейшем иметь возможность более точно производить будущие расчеты", - советует он.
Чтобы в полной мере ощутить преимущества этого метода, начальник информационного отдела должен постоянно интересоваться состоянием разрабатываемого проекта. Можно, например, просмотреть список невыполненных операций и поинтересоваться, почему он такой длинный, и что делается для его сокращения и ускорения процесса поставки продукта на рынок? К тому же ему следует более детально изучать вопросы, касающиеся покупок и отдельных разработок, чтобы быть уверенным, что на всех уровнях принимаются оптимальные решения.
Грочоу просит обратить более пристальное внимание на вопросы риска. Он желает, чтобы администраторы проектов выделяли для себя все факторы, которые могут повлечь задержку выполнения проекта, его провал или привести к материальным издержкам.
SEI учит компании пользоваться методом разработки ПО, заставляя их искать все слабые места производственной задачи и исправлять их. Первоначально метод был задуман как средство, помогающее государственным организациям, например вооруженным силам, рассчитать потенциальные возможности партнеров, но в последние годы SEI распространила свои услуги на производителей ПО, предназначенного для коммерческого и домашнего использования. "Задача SEI - брать хорошие теоретические разработки и превращать их в перспективные, с практической точки зрения, идеи", - объясняет Грочоу.
При этом большинство администраторов согласятся потратить несколько лишних долларов, зато пораньше выпустить продукт.
Все больше и больше компаний сотрудничают с SEI, тем самым обеспечивая компании высокий рейтинг, и все больше европейских фирм склоняются к мнению, что наличие сертификата качества ISO 9001 является основным требованием при заключении договора о деловом сотрудничестве. Организации, занятые проблемами качества, скажем, SEI или Цюрихская Международная Организация Стандартов (ISO), считают, что дешевле сделать все правильно с первой попытки, и показывают другим компаниям, как можно этого добиться.
Джоунс говорит, что достижение высокого качества ПО ни дешевым, ни тем более легким делом назвать нельзя, и предупреждает: "Если на вашем предприятии, в отличие от конкурентов, не очень хорошо налажен выпуск ПО, вас, определенно, ждут серьезные неприятности". Для всех, кто не желает вкладывать деньги и тратить время на достижение высокого уровня выпускаемого ПО, единственный выход - это заключение партнерского соглашения с фирмой, уже осваивающей такие методы разработки. Для тех же, кто не желает делать этого, остается только внедрять подобные модели разработки у себя и твердо придерживаться их в дальнейшем.