Главная

Подходы

Концепция

Суть предлагаемого подхода можно выразить довольно просто. При разработке сложного системного проекта рекомендуется проработать ряд вопросов, которые в любом случае окажутся полезными. Эти вопросы сформулированы таким образом, что могут применяться как квалифицированным аналитиком, так и специалистом, далеким от знакомства с системным анализом.

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

Ответив на первую группу вопросов, разработчик может более четко увидеть условия, в которых выполняется проект, связь между проектом и общим развитием объекта, активные факторы, наличие необходимой инфраструктуры и так далее. Другими словами, изучается оболочка системы, которая в дальнейшем либо включается в проект, либо считается условно-постоянной.

КОНТРОЛЬНЫЕ ВОПРОСЫ

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

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

Стратегия. При работе со сложным объектом проект очень часто является лишь шагом в его развитии. Например, автоматизация отдела кадров на фоне развития предприятия. Нетрудно увидеть, что как предыдущие, так и последующие шаги должны быть уложены в некоторую цепочку развития, причем не только по основному результату (новая программа), но и по развитию инфраструктуры (повышение опыта группы разработчиков, обучение пользователей, освоение новых технических средств или методов работы и так далее).
Имея глобальную задачу, целесообразно выделять в ней главную часть в виде одной-двух "паровозных" систем второго уровня. По отношению к ним также проводится декомпозиция, и в итоге во всей системе появляются 2-3-4 ключевых комплекса, внедрение которых определяет общее развитие системы. Проект таким образом ориентирован не на автономную цель, а работает и на стратегические задачи тоже.

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

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

----------
Этот список вопросов или этапов выполнения проектов не претендует на необходимость применения в любом проекте, и тем более не претендует на полноту. Однако на этом сайте мы будем уделять основное внимание именно таким этапам, вытекающим из системных свойств объектов и их окружения. Тех свойств, которые весьма полезно учитывать на всех стадиях жизни проекта.