Внутренние проблемы информационных систем
Внутренние проблемы информационных систем
Внутренние проблемы ИС обусловлены особенностями согласования ее технических (Hardware) и программных (Software) составляющих. На основании представленных выше соображений ИС - это по сути своей всегда тот или иной программно-аппаратный комплекс (ПАК) или совокупность таких комплексов, т.е. некое неповторимо индивидуальное единство, которое выполняет возложенные на него функции как целое, и его не следует в таком подходе разделять на составляющие.
Конечно, в каких-то стадиях работы с ИС вполне правомерно рассматриваются отдельно технические и программные средства системы. Но создаваться и тем более совершенствоваться они должны все равно как единый комплекс, ибо только в таком целостном представлении ИС может проявить полностью заложенные в ней возможности.
В связи с этим следует отметить важную роль, которую играют специалисты по компонентам Software системы, т.е. по всем программным средствам, базам данных, каталогам, нормативам, технологическим процессам и т.д., которые далее будут фигурировать как «программисты» в таком широком смысле.
Если место технических средств в ИС определено: они унифицированы, этапы жизненного цикла обозначены, авторское право и права собственности на эти изделия сформулированы, то с программными средствами в ИС до сих пор еще не все ясно.
В связи с этим декомпозиция ИС на компоненты и последующее агрегирование наталкиваются на вопрос о необходимости и возможности представления программ в качестве изделий, что определяет роль и место соответствующих специалистов.
Программисты всего мира вели ожесточенную борьбу и потратили много сил и времени на то, чтобы доказать наличие у программ всех признаков изделия, самостоятельную ценность программ как изделий и необходимость создания индустрии программных средств. При этом в отношении сначала программ, а теперь и информационных, и других средств возникают и понятие «жизненного цикла», а также понятия качества, надежности и т.д.
Однако в результате этой борьбы, как это часто бывает, как бы по инерции акцент в системах сместился в сторону программных средств: программы приобрели самоценность, как по мнению программистов, так и на взгляд многих руководителей (менеджеров) и в чем-то даже подменили собой систему в целом. Как следствие этого - определенное забвение того, что ПАК - это всегда неразрывное целое, о чем нужно помнить также и при создании программ. Программы создаются для того или иного ПАК и переносимы, как правило, лишь в известной степени, условно.
Совместимость программ и технических средств также условна и должна подвергаться проверке на специальных испытаниях. Однако в документации на программы нередко приводится настолько поверхностное описание технических средств, на которых реализуется создаваемая программа, что при этом вообще упускается из виду (и из документации, естественно) необходимость совместной отработки ПАК как единого изделия. Кроме того, часто технические и программные средства модернизируются независимо друг от друга, поскольку ничто этому не препятствует. Сопровождение же их разработчикам неинтересно и невыгодно, в связи с чем они активно от этой деятельности уклоняются. Пользователи и покупатели, ранее получившие эти средства, об изменениях обычно не уведомляются.
При этом всегда неявно или даже явно подразумевается, в конце концов, что программист, как минимум, энциклопедически образован. Он принимает все решения по архитектуре и конфигурации системы, выполняет рабочее проектирование, создает документацию, определяет требования к персоналу, обучает всех
Рекомендуемые материалы
работников поведению в среде системы и принимает решения по всем другим вопросам. Основа такого положения в том, что при создании систем в настоящее время основное внимание уделяется все-таки созданию программной среды, поскольку многие отечественные системы проходят еще стадию создания первой очереди.
Поэтому в процессе формирования программных средств и
В лекции "17 Заключение" также много полезной информации.
программирования оказываются фактически скрытыми вопросы создания собственно системы, которые и ставятся в таких случаях как вопросы создания соответствующих программ. И решать эти вопросы берутся, как правило, программисты. Так и происходят на практике указанное выше смешение акцента и очевидная гипертрофия роли программистов.
Из-за этого страдают системотехническая разработка, постановка задач, учет пользовательского интерфейса не только к программным средствам, но к системе в целом, не прорабатывается эргономический диалог «человек - система». Эти проблемы имеют собственную природу, методы решения и даже вполне хрестоматийные стандартные результаты. Поэтому существует опасность в таких условиях не получить ничего, кроме интуитивных решений, основанных на здравом смысле программиста.
Хочется в связи с этим отметить, что если при создании «крупных» систем на больших предприятиях это отчетливо осознается, то при создании ИС на малых предприятиях все эти опасности и заблуждения могут сыграть свою коварную роль. Это в значительной мере будет определяться уровнем квалификации руководства предприятия в стандартных методах менеджмента, а также подбором кадров специалистов по информатике.
Здесь можно также подчеркнуть, что программист может создавать систему «под себя», т.е. в той или иной степени его решения по системе основываются на личных пристрастиях, часто вообще ни с кем не согласуются в деталях и концепции ИС в целом могут не следовать. Выявленные в процессе отладки дефекты и неучтенные ранее требования ликвидируются и разрешаются «по ходу дела», т.е. имеют вид «заплат» - сиюминутных решений, не всегда согласуемых с общей структурой изделия и не документируемых надлежащим образом. Аналогично могут проводиться модификации отдельных программ, комплексов программ или системы в целом. В связи с этим можно с полным основанием утверждать, что такие программы и системы всецело привязаны к их авторам. Это означает, что уход из организации их создателя будет подобен катастрофе, поскольку станут непонятными не только программы, но и модули системы, и система в целом.
На этом основании вполне правомерен сделанный вывод об имеющей место гипертрофии роли программистов в современной практике информатизации. Правда, программирование как профессия способствует системности мышления, поэтому не следует исключать, что программисты могут строить системы вполне системно. Тем не менее все-таки лучше, если такой специалист будет сертифицирован, и называть его тогда следует не программистом, а системным аналитиком.
Необходимо подчеркнуть, что и в других странах, которые вроде бы должны были уже преодолеть перечисленные проблемы, положение немногим лучше. Хотя надежность и качество зарубежных средств информатики выше, насыщенность рынка тоже выше, обязательства перед покупателями соблюдаются лучше, приспособленность к решаемым задачам тоже лучше, однако в прессе появляются все более острые вопросы и напряженные размышления по поводу того, что информатизация не дает желаемого эффекта, что имеются специфические проблемы внутренней организации автоматизированных систем. Такие материалы имеются и по Японии, и по США, и по Германии. Существо этих проблем, как оказывается, в значительной мере совпадает с теми, что были выше обозначены.
