Программотехника 

Программотехника

3.2

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

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

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

Важный момент, который на этом этапе часто упускают из внимания, — это необходимость предусмотреть тот или иной вид устройств, позволяющих «вручную» протестировать или «выручить» полностью автоматизированный объект или управляющую последовательность, которые по неясным причинам не действуют должным образом.

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

Следует признать особую важность этого первого этапа. Если все спорные моменты и проблемы прояснить в самом начале, то последующие этапы не вызовут затруднений. Выяснить на этапе ввода в эксплуатацию, что пользователь хотел иметь изменяемую скорость вентиляторов и сигнализацию об опасном снижении давления и «думал, что вам об этом известно», — это не дает уверенности, что при запуске объекта все пройдет гладко. Если вы в чем-то сомневаетесь — спросите; а даже если и не сомневаетесь — все равно спросите еще раз и отбросьте в сторону ваши догадки и предположения.

На этом этапе также должны быть определены требования к тестированию системы. Если вы не продумали, как будете проверять ее работоспособность, то как вы узнаете, что выполняются все выдвинутые пользователем технические требования?

Рис. 3.1. Этапы проекта

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

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

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

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

Никогда не следует упускать из виду проверки, связанные с обеспечением безопасности; если оказывается, что в процессе эксплуатации системы при возникновении опасности не срабатывает аварийная защита, это гарантирует посещение вашего предприятия представителями комиссии по охране труда и технике безопасности.

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

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