Внутренние проблемы информационных систем

Внутренние проблемы ИС обусловлены особенностями согла­сования ее технических (Hardware) и программных (Software) со­ставляющих. На основании представленных выше соображений ИС - это по сути своей всегда тот или иной программно-аппа­ратный комплекс (ПАК) или совокупность таких комплексов, т.е. некое неповторимо индивидуальное единство, которое выполня­ет возложенные на него функции как целое, и его не следует в таком подходе разделять на составляющие.

Конечно, в каких-то стадиях работы с ИС вполне правомер­но рассматриваются отдельно технические и программные сред­ства системы. Но создаваться и тем более совершенствоваться они должны все равно как единый комплекс, ибо только в таком це­лостном представлении ИС может проявить полностью заложен­ные в ней возможности.

В связи с этим следует отметить важную роль, которую игра­ют специалисты по компонентам Software системы, т.е. по всем программным средствам, базам данных, каталогам, нормативам, технологическим процессам и т.д., которые далее будут фигури­ровать как «программисты» в таком широком смысле.

Если место технических средств в ИС определено: они уни­фицированы, этапы жизненного цикла обозначены, авторское право и права собственности на эти изделия сформулированы, то с программными средствами в ИС до сих пор еще не все ясно.

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

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

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

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

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

Поэтому в процессе формирования программных средств и программирования оказываются фактически скрытыми вопросы создания собственно системы, которые и ставятся в таких случа­ях как вопросы создания соответствующих программ. И решать эти вопросы берутся, как правило, программисты. Так и проис­ходят на практике указанное выше смешение акцента и очевид­ная гипертрофия роли программистов.

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

Хочется в связи с этим отметить, что если при создании «круп­ных» систем на больших предприятиях это отчетливо осознает­ся, то при создании ИС на малых предприятиях все эти опаснос­ти и заблуждения могут сыграть свою коварную роль. Это в зна­чительной мере будет определяться уровнем квалификации ру­ководства предприятия в стандартных методах менеджмента, а также подбором кадров специалистов по информатике.

Здесь можно также подчеркнуть, что программист может со­здавать систему «под себя», т.е. в той или иной степени его реше­ния по системе основываются на личных пристрастиях, часто во­обще ни с кем не согласуются в деталях и концепции ИС в целом могут не следовать. Выявленные в процессе отладки дефекты и неучтенные ранее требования ликвидируются и разрешаются «по ходу дела», т.е. имеют вид «заплат» - сиюминутных решений, не всегда согласуемых с общей структурой изделия и не документи­руемых надлежащим образом. Аналогично могут проводиться модификации отдельных программ, комплексов программ или системы в целом. В связи с этим можно с полным основанием утверждать, что такие программы и системы всецело привязаны к их авторам. Это означает, что уход из организации их создате­ля будет подобен катастрофе, поскольку станут непонятными не только программы, но и модули системы, и система в целом.

На этом основании вполне правомерен сделанный вывод об имеющей место гипертрофии роли программистов в современ­ной практике информатизации. Правда, программирование как профессия способствует системности мышления, поэтому не сле­дует исключать, что программисты могут строить системы впол­не системно. Тем не менее все-таки лучше, если такой специалист будет сертифицирован, и называть его тогда следует не програм­мистом, а системным аналитиком.

Необходимо подчеркнуть, что и в других странах, которые вроде бы должны были уже преодолеть перечисленные пробле­мы, положение немногим лучше. Хотя надежность и качество зарубежных средств информатики выше, насыщенность рынка тоже выше, обязательства перед покупателями соблюдаются луч­ше, приспособленность к решаемым задачам тоже лучше, одна­ко в прессе появляются все более острые вопросы и напряженные размышления по поводу того, что информатизация не дает жела­емого эффекта, что имеются специфические проблемы внутрен­ней организации автоматизированных систем. Такие материалы имеются и по Японии, и по США, и по Германии. Существо этих проблем, как оказывается, в значительной мере совпадает с теми, что были выше обозначены.