ТРИЗ в информационных технологиях

Выше уже было показано на многих примерах, как инструменты ТРИЗ могут быть использованы для развития информационных технологий и программного обеспечения. Программные продукты являются также и техническими системами передачи и обработки информации. Для них применимы законы развития технических систем и инструменты решения изобретательских задач.

Процесс программирования (проектирования, разработки и сопровождения программных продуктов) обычно заключается в итеративной работе по построению моделей предметной области, которые могут быть определены следующим образом:

1. Модель (общая постановка) задачи на естественном языке в терминах предметной области.

2. Модель архитектуры на языке моделирования.

3. Алгоритмическая модель на высокоуровневом языке программирования.

4. Модель на низкоуровневом языке ассемблер.

5. Модель на языке команд вычислителя, которая может быть исполнена им в динамическом окружении.

Обратим внимание на то, что языки построения этих моделей, по мере перехода от одной к другой, все более и более формализуются, и, наконец, становятся формальным языком, понимаемым вычислителем (как правило, компьютером). Некоторые переходы от одной модели к другой, а также средства построения некоторых моделей – автоматизированы, при этом используются инструменты программирования (редакторы текстов и моделей, трансляторы, редакторы связей и др.). Совокупность процессов, работающих с моделями, и дающих, в итоге, программный продукт, обычно называют технологическим подходом.

При построении моделей используется абстрагирование – принцип игнорирования второстепенных аспектов предмета с целью выделения главных. В программировании абстракции рассматриваются одновременно как по отношению к решаемой задаче, так и по отношению к физической машине (вычислителю). Заметим здесь, что такие термины ТРИЗ как «техническое» или «физическое» противоречие оказываются вполне корректными, несмотря на то, что работа ведется в основном с нематериальными элементами моделей.

Основными абстракциями в программировании являются абстракции архитектуры (модульности), управления и данных. Уточним, что с точки зрения архитектуры, программисты работают с малыми модулями (классами, функциями, процедурами), средними модулями (программами, библиотеками), и огромными (совокупностью взаимодействующих программ).

Инструменты ТРИЗ могут быть применимы к разрабатываемому (или сопровождаемому) программному продукту на каждом из пяти уровней моделей по нашей классификации. В первую очередь это относится к таким инструментам классической ТРИЗ, как законы развития технических систем, изобретательские приемы устранения технических противоречий (с учетом терминологической и семантической адаптации для нашей предметной области), вепольный (элепольный) анализ, задачи-аналоги, АРИЗ.

Мы уже приводили некоторые примеры решения изобретательских задач при помощи инструментов ТРИЗ: задачи о защите общедоступной программы, о визуализации информации о деятельности компании, о вычислении произвольного полинома, о программе расчетов в электрических сетях с трансформаторами, о редакторе документов с графическими объектами и другие.

Проиллюстрируем еще раз применение основных инструментов ТРИЗ на примере задачи об ускорении сортировки массива данных (задача 6).

Функциональный ИКР: Массив САМ уменьшает время сортировки во время работы алгоритма при использовании существующего алгоритма сортировки.

Противоречия требований:

ЕСЛИ создается новый алгоритм, ТО уменьшается время сортировки массива, НО на создание нового алгоритма уйдет слишком много времени.

ЕСЛИ используется существующий алгоритм, ТО массив сортируется, НО сортировка занимает слишком много времени.

Использование сокращенной таблицы применения приемов устранения противоречий. Можно использовать две пары требований:

– Скорость и Удобство изготовления (9-32);

– Скорость и Сложность устройства (9-36);

Получаем рекомендации по приемам: 13, 1, 10, 4, 34 (дробления, предварительного действия, асимметрии, отброса и регенерации частей).

Конфликтующие элементы: Массив целых чисел (в двух состояниях – отсортированные и не отсортированные), Алгоритм сортировки. Они взаимодействуют между собой, можно ограниченно менять массив целых чисел.

ОВ – время сортировки массива.

ОЗ – взаимодействие алгоритма сортировки с массивом целых чисел.

Внутрисистемные ресурсы: ресурсы массива целых чисел.

Элепольное решение: Э1 – не отсортированный массив, Э2 – отсортированный массив, П – алгоритм сортировки. Так как размер массива отрицательно влияет на время работы алгоритма, то между Э1 и Э2 есть одновременно и полезная связь (массив все же сортируется) и вредная – это происходит слишком долго. Получаем рекомендацию по стандарту 1.2.1:

Либо взаимодействие между Э1 и Э2 можно считать не достаточно эффективным и тогда нужно использовать рекомендации стандарта 2.1:

В любом случае мы получаем рекомендации перехода к комплексному элеполю: один из элементов (в нашем случае это массив данных) должен состоять из нескольких элементов (то есть в нашем случае из нескольких массивов данных).

В соответствии с линией введения элементов (веществ) предлагается использовать для введения уже имеющиеся элементы или их модификации.

Ресурсный ИКР. Икс-элемент из ресурсов системы САМ УСТРАНЯЕТ большое время сортировки, СОХРАНЯЯ использование существующего алгоритма сортировки.

Противоречие свойств. Конфликтующий элемент (массив чисел) должен быть малого размера, чтобы обеспечить малое время выполнения алгоритма сортировки, и должен быть большим, чтобы хранить все необходимые числа.

ИКР свойств. Взаимодействие алгоритма сортировки с массивом целых чисел в течение сортировки должно САМО обеспечивать малый размер обрабатываемого массива и большой размер получаемого массива.

Решение. Согласно принципу дробления и принципу предварительного действия, нужно до начала сортировки разбить массив на части (например, на две равные части). При этом каждый из двух новых массивов будут меньше начального. Затем нужно применить алгоритм сортировки к каждому массиву по отдельности, после чего соединить отдельные упорядоченные массивы в один. При этом так, как время соединения упорядоченных массивов линейно зависит от их длины, а время сортировки пузырьком – квадратично, то общее время сортировки начального массива будет уменьшено. Причем чем длиннее массив, тем больший выигрыш во времени будет получен.

Важность совершенствования технологий развития программного обеспечения и информационных систем повышается с каждым годом. Объем передаваемой в сетях информации с 2005 по 2010 год увеличилась в 7 раз (рис. 5.2). С начала эры рост количества информации в мире идет в 1,38 млрд. раз быстрее, чем рост населения и в 60 млн. раз быстрее, чем рост ВВП.

Рис. 5.3. Диаграмма для развития идей программных продуктов
и проектов информационных систем.

Прогнозируется к 2050 году еще более резкое увеличение объемов информации в мире.

В этих условиях актуальность задачи повышения эффективности IT-менеджмента становятся важнейшими для развития современных технологий. Программные продукты относятся к числу самых сложных систем, создаваемых человеком. При этом с увеличением сложности программного продукта резко падает эффективность их создания. Продуктивность создания программных продуктов увеличивается очень медленно. Средний программист способен создать 60-80 полноценных строк операторов в день и с увеличением сложности программы этот показатель только падает. Коллективы разработчиков программных продуктов должны обладать целым рядом качеств, которые далеко не всегда удается совместить: динамичность для адаптации к новым ситуациям, дисциплинированность для возможности работать в команде в рамках общего проекта, креативностью для решения изобретательских задач, опытом и профессионализмом для использования уже известного в культуре создания программных продуктов. Один из вариантов последовательности в анализе и развитии идей эволюции программных продуктов и информационных систем представлен на рисунке 5.3.

Необходимы принципиально новые технологии создания программных продуктов. Важной составляющей этих технологий должен стать инструментарий ТРИЗ. Необходимо опираться не на сегодняшние пусть даже и очень актуальные задачи, а на тенденции в развитии систем, на системные подходы и на прогнозируемые задачи будущего.