Шрифт:
Мнения на этот счет расходятся. Предположим, перед вами стоит задача конструирования системы управления воздушным движением. На первый взгляд, программная инженерия прекрасно подходит для ее решения. Но… стоит подумать еще раз. К провалу проекта комплексной системы автоматизации (Advanced Automation System, AAS) Федерального управления гражданской авиации США (Federal Aviation Administration, FAA), с помощью которого в 1980-х годах предполагалось модернизировать систему управления воздушным движением, методика программной инженерии имеет непосредственное отношение. Несмотря на миллионные затраты, проект так и не оправдал ожиданий [114] .
114
См. Glass, Software Runaways, op. cit., p. 56.
Кое-кто до сих пор убеждает общественность в том, что программная инженерия – это именно то, что нужно, их оппоненты не соглашаются – по их мнению, эта методология оторвана от реальности и с наступлением эпохи Интернета неприменима к рутинным проектам. Я предлагаю вам самостоятельно изучить соответствующую литературу, опробовать на практике декларируемые в ней идеи и лишь после этого делать выводы. В рамках школы программной инженерии исследователям удалось выработать ряд весьма удачных идей, и если они вам подходят – действуйте! С моей точки зрения, программная инженерия – это скорее идеальная конструкция, чем реальная методология; по этой причине методы для внедрения в повседневную деятельность своей команды я предпочитаю искать в других концепциях.
MSF
Хотите – возмущайтесь, но в одном вы меня не переубедите: компании Microsoft удалось разработать крайне продуманный метод и успешно его разрекламировать. Несколько компаний [115] даже решили в приказном порядке отправить своих сотрудников на недельные курсы обучения предлагаемому Microsoft методу. Не сомневаюсь, что компании уровня Microsoft, специализирующейся на разработке коммерческих программных продуктов, есть что сказать на заданную тему.
115
В том числе и моя, естественно.
Концептуальная основа метода MSF (Microsoft Solutions Framework – каркас решений Microsoft) предполагает координацию групп, тем или иным способом ответственных за процесс разработки. Вместо того чтобы воспроизводить яркие рекламные лозунги, я сосредоточу ваше внимание на отдельных деталях метода – по-моему, они лучше любых сообщений информационных служб и даже лучше научного изложения концепции отражают позицию Microsoft. Согласно выпущенному компанией руководству [116] , предлагаемая методика основывается на «трех китах».
116
Solutions Development Discipline Workbook (Redmond, WA: Microsoft Corporation, 1996), pp. 1-17.
1. Прикладная модель строится на основе предоставляемых услуг, побуждая разработчиков рассматривать любое приложение как сеть услуг, в которой характеристики и функциональность можно пакетировать вне зависимости от функциональных границ и в расчете на многократное использование.
2. Итерационная модель процесса жизненного цикла разработки ориентирована на поставки, отталкивается от рисков и включает четыре основных этапа.
3. Используется модель масштабируемой группы разработчиков, состоящей из шести равнозначных ролей.
Не сомневаюсь, что вы с нетерпением ожидаете изложения упомянутых «четырех этапов» и «шести ролей». Сходите на курсы Microsoft – я не хочу рекламировать специалистов Microsoft больше, чем они того заслуживают. Они высказали ряд замечательных идей, которые мне удалось приспособить к своей методологии разработки. Ну ладно – полагаю, у вас не так много времени, чтобы проводить собственные исследования, так что, коль скоро вы купили мою книгу, поговорим о деталях.
Что касается этапов MSF, то здесь группа разработчиков должна принять на вооружение ряд принципов.
1. Видение/рамки. Основное внимание уделяется не требованиям, а рамкам работ.
2. План проекта. Заказчики и участники группы должны договориться о поставках, приоритетах и ожиданиях.
3. Закрытые рамки/Первое применение. Первая бета-версия готового продукта.
4. Выпуск. Продукт или услуга предоставляется рабочей группе и группе поддержки.
Роли в MSF распределяются следующим образом.
1. Руководство продуктом. Особое внимание уделяется оценке продукта с коммерческой точки зрения.
2. Управление программой. Разработка функциональных спецификаций, утверждение и корректировка графика.
3. Разработка. Конструирование продукта (или услуги), соответствующего спецификации и ожиданиям заказчиков.
4. Тестирование. Выявление всех проблем перед выпуском программы.
5. Обучение пользователей. Каждый пользователь должен получать от продукта максимум возможностей.