|
Несмотря на предыдущий вывод, далеко не все «области простых программ» имеют столь четкие границы, что все программы для них уже написаны. В частности, если использовать компьютер для его изначальной задачи – для математических расчетов – то здесь число программ бесконечно: здесь нет принципиальных ограничений на структуру и объем проводимых вычислений. С помощью математического или иного моделирования можно исследовать что угодно, что существует в мире, проектируется для создания человеком или даже просто придумывается в виртуальной реальности. Аналогично, почти нет ограничений для интеллектуальной обработки какой-либо информации (распознавание образов, выявление трендов, корреляций и т.п.) и для решения большинства других видов научных задач. И даже вне науки существуют области, в которых невозможно разработать ПО на все случаи жизни, и при этом требуемое новое ПО не является «сложным» в вышеуказанном смысле. Например, это программы-тесты (с не подлежащим расширению наполнением) или программы для упрощенного проектирования разнообразной продукции [http://soft.mail.ru/subcat_list.php?cat=82] – мебели, интерьеров, электрики и т.п. – всего того, что не требует привлечения больших групп инженеров, дизайнеров и т.п. В таких программах «упрощенного» выполнения действий принципиально важна узкая область применения, то есть отсутствие стремления к универсальности (иначе из них мог бы получиться серьезная «настраиваемая» информационная система или пакет типа Photoshop/AutoCAD – с соответствующей потерей «простоты»). Резюмируем сказанное в разделе 7.2.2 про научные (или сходные с ними инженерные, тестирующие и т.п.) программы. В них не нужны следующие типичные характеристики современного ПО: - развитый («насыщенный», rich) пользовательский интерфейс, в т.ч. разнообразные табличные настраиваемые «отчеты»;
- возможность коллективной работы;
- безопасность (как отказоустойчивость и как защита от несанкционированного доступа).
И вообще, объем требований к таким программам существенно меньше объема требований к типичным современным информационным системам. Но с другой стороны, эти программы обладают весьма высокой сложностью в другом смысле: - нетипичность (понятность только узким специалистам) структуры входных и выходных данных программы;
- сложность алгоритмов обработки данных (в т.ч. математических);
- (только для некоторых научных областей) возможность настройки одной и той же программы (содержащей сложные алгоритмы) к работе в различных предметных областях;
Дополнительно к этому, в научных (и некоторых инженерных) программах желательны: - возможность применения одних и тех же методов/моделей по отношению к различным задачам – ключевое свойство науки (это некоторая трактовка универсальности, но по отношению не к готовой программе, а к ее частям);
- поддержка сложных структур данных (векторно-матричных, динамических и т.д.)
Достаточно смелое утверждение состоит в том, что для разработки такого ПО (и сопутствующих его разработке процессов) достаточно ОДНОГО специалиста (с некоторыми оговорками, см. ниже). Более того, во многих научных задачах, вопреки известной пословице, «одна голова лучше, чем две» (даже при наличии больших человеческих и финансовых ресурсов!). Один специалист должен заниматься и аналитикой/документацией, и разработкой/реализацией, и внедрением/обучением программного продукта, а такие вспомогательные вещи как конфигурационное управление должны быть редуцированы до минимума. Оговорки же касаются того, как в таком случае должна решаться проблема ограниченности временных ресурсов программного проекта. Основная оговорка – при большом объеме требований проекта «основному специалисту» нужны другие программисты-«помощники», которые привлекаются, как правило, не только за счет финансовой, но и других видов стимуляции (см. раздел 8.3). При этом, в отличие от стандартной методологии с разделением ответственности программистов по модулям (или по «слоям») программной системы, «помощники», как правило, занимаются частными, но алгоритмически или технологически сложными задачами, представляющими интерес для самих программистов. Что касается большинства остальных процессов разработки ПО (помимо программирования), то их суммарная трудоемкость для ПО вышеописанного типа составляется всего 50-100% от трудоемкости реализации (программирования), в то время как для более типичных современных проектов этот показатель составляет 200-300%. Следовательно, все остальные работы (анализ, проектирование, деплоймент, внедрение и т.п.) могут и, как правило, должны выполняться одним основным специалистом. Однако это возможно лишь при условии разносторонней подготовки основного специалиста (это и есть вторая основная оговорка к методологии индивидуальной разработки). Одним из вариантов реализации методологии индивидуальной разработки является коллектив из нескольких равноправных участников с существенно отличающимися интересами и навыками, но имеющих опыт работы в единой среде (включающей язык программирования и набор фреймворков). В этом варианте коллектив может параллельно выполнять несколько проектов, причем по отношению к каждому проекту ровно один член коллектива выполняет функции «основного специалиста», остальные – «помощников».
|
