Книга: Программное обеспечение и его разработка
Печальная участь первопроходцев
Печальная участь первопроходцев
Сказано точно. Изучение новых разработок показывает, что первый руководитель и второй, пришедший ему на смену, обычно кончают одинаково — их снимают. Только после одного или двух «кровопусканий» главное руководство может занять реалистические позиции. Почему люди вообще хотят стать руководителями больших разработок программного обеспечения? Потому что это наиболее быстрый способ продвижения по служебной лестнице, «путь наверх» — если, конечно, вы сможете удержаться.
Вы будете прекрасно вознаграждены, если преуспеете.
На этом пути можно достичь немыслимых высот, что принесет вам большое моральное удовлетворение. Лучшие руководители разработками программного обеспечения мне рассказывали с гордостью о том торжественном моменте, когда зажигались все огни и вся общенациональная система вступала в действие!
При управлении большими работами должно быть очевидно, что нужно пользоваться минимально возможным числом исследований и новейших методов.
Почему же это должно быть очевидно? Это не так очевидно, как можно было бы подумать! В 1961 г. комитет, созданный по предписанию президента Джона Ф. Кеннеди для расследования причин воздушной катастрофы над Нью-Йорком, вынес рекомендации по автоматизации управления авиалиниями. Комитет настоял на том, чтобы Федеральное авиационное агентство (FAA) для всех новых систем покупало только «отработанные» вычислительные машины. Это ограничение было наложено потому, что в конце 1950-х г. FAA стала вкладывать деньги в разработку вычислительных машин — и деньги стали уходить в эту область, а не на разработку собственно систем управления авиалиниями.
Похожая история произошла в середине 1970-х г. в системе здравоохранения. Разработчики перестали заниматься созданием системы, которая могла бы удовлетворить запросы врачей, медицинских сестер, администраторов, специалистов и обслуживающего персонала, и занялись разработкой «сети» мини-ЭВМ и распределенной базы данных.
Ни FAA, ни медицине не были нужны никакие новаторства в области аппаратуры по обработке данных. И без этого было достаточно хлопот с системными проблемами. При разработке больших систем не разрешайте вашим сотрудникам заниматься изобретательством. Пусть этим занимаются в научно-исследовательских центрах.
Небольшая консультационная компания потеряла 300 000 долларов — доход за несколько лет — при попытке закончить работы по контракту, в которых использовалась машина фирмы IBM «Series 1». Аппаратура была великолепной; а системное и инструментальное программное обеспечение было отработано не до конца. Каждый раз оказывалось, что люди натыкались на какую-нибудь неисследованную проблему. Программное обеспечение было новым! По этой причине фирма IBM не давала по нему никаких гарантий. И контракт был передан IBM.
- Системы, подсистемы и программное обеспечение
- Общесистемная незамкнутость
- Взгляд сверху вниз
- Различные подсистемы обработки данных в одной системе
- Отделение программного обеспечения от аппаратуры
- Перегрузка аппаратной подсистемы, которую можно принять за неполадку с программным обеспечением
- Стоимость и график разработки предсказать невозможно
- «Эффект заброшенных функций» при разработке больших программ
- Планирование развития
- Занятость
- Эволюционный подход к разработке больших систем
- Задачи руководства программным обеспечением проекта
- Результаты процесса разработки
- План разработки или проекта
- Производительность труда и оценки
- Производительность труда при разработке программного обеспечения
- База данных по производительности труда
- Определения терминов «строка программы» и «человеко-месяц»
- Два значения термина «строка программы»
- Категории программного обеспечения
- Определение человеко-месяца
- Изменчивость
- Вопросник по производительности труда
- Ошибки при подсчете СТП
- Форма отчетности по строкам программ
- Некоторые результаты сбора статистики
- Оценка
- Оценка размеров программы
- Факторы, определяющие трудность разработки
- Функциональные факторы
- Как проводить оценки
- Предположения при проведении оценок
- Организация усилий по разработке программного обеспечения
- Ключевые моменты больших проектов
- Надзор над разработкой
- Управление
- Экономия усилий
- Управление конфигурацией
- Автоматизированная матрица модулей/функций
- Ключ к успеху — руководитель разработки
- Выбор руководителя разработкой программного обеспечения
- Технический опыт
- Карьера разработчика программного обеспечения
- Пять стадий развития всех новых проектов
- Печальная участь первопроходцев
- Будет ли удовлетворен настоящий пользователь?
- Прослушивания
- Прослушивания очень важны
- Что необходимо выносить на прослушивания — и когда?
- Что такое «прослушивание»?
- Кто должен участвовать в прослушиваниях?
- В чем вред прослушивании?
- Отчеты на прослушиваниях — делайте их устно
- Первый выход на прослушивание или в группу инвентаризации
- Кадры и инструментарий
- Купить или сделать
- Разрабатывать самим или заказывать на стороне
- Как заказывать разработку программного обеспечения
- Вид заключаемого контракта
- Что делать, когда все идет прахом
- Поиски замены для руководителя
- Неуправляемый гигант
- Стандарты программного обеспечения
- Ничто не дается бесплатно — средства на стандартизацию тратятся с первых же шагов
- Склонность к фантазированию
- Сопротивление нововведениям
- Изменения дорого обходятся с самого начала
- Разработка или продолжающаяся разработка как наиболее дорогостоящая фаза
- Одна причина оптимистических оценок
- Научные исследования в программном обеспечении
- Отсутствие методов представления программ
- Разрабатывать программы так же, как и аппаратуру?
- Сходство между аппаратурой и программным обеспечением