Geum.ru

Учебное пособие по курсу «Технология программирования»

Вид материалаУчебное пособие

Содержание


2. Некоторые аспекты технологии программирования и внедрения ПО.
Подобный материал:
1   2   3   4   5   6   7   8   9   10
^

2. Некоторые аспекты технологии программирования и внедрения ПО.



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

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

Программа может не работать, как предусмотрено в постановке, из-за неправильного понимания программистом поставленной задачи; ошибок в постановке; ошибок в программе; плохой отладки программы; из-за ограниченного набора входных данных и т.д. Основная причина в том, что в случае «технических» технологий выполняющее производство звено – законы природы, а в случае программирования выполняющее производство звено – программист, а программисту свойственно ошибаться. Более того, исследования показали, что в больших программных системах количество ошибок не может быть ниже определённого уровня (чаще всего встречается уровень 20%). Для больших программных сред всегда можно подобрать внутренне противоречивый набор входных данных

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

Но даже для простых правильно написанных программ, которые работают согласно всем требованиям можно подобрать пример, когда программа будет «выдавать» принципиально неверный результат. Форсайт Дж. приводит изящный пример программы решения квадратного уравнения с одним неизвестным (что может быть проще?), которая написана без ошибок, но не может в принципе (!) правильно решить некоторый класс этих уравнений [9]. Причина совсем простая: ЭВМ работает не на непрерывной числовой оси, как мы все привыкли понимать, а на дискретной. Расстояния между точками этой «дискретной прямой» растут при увеличении абсолютной величины числа соответствующего точке.

Таким образом, с одной стороны, производящее производственное звено – это слабо формализованная фигура программиста. С другой стороны, мы используем идеальные законы в неидеальной среде. Этот клубок дополняется ещё и следующим: как правило, заказчик не знает, чего хочет! Брукс Ф. [3] прямо утверждает: «Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами- программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют». Другими словами, ситуация как в русской народной сказке «Поди туда, не знаю куда, принеси то, не знаю что».

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

Кроме того, всё вышесказанное существенно меняет ориентиры в работе программиста: Цель работы программиста не создание абсолютно безошибочных программ, а создание программ выдающих ожидаемые пользователем результаты при обработке задаваемого множества входных данных. Вот эти, ожидаемые пользователем результаты и являются целью написания программы. Появятся они в результате работы программы, скорее всего заказчик примет вашу программу, хоть и с оговорками. Не будет ожидаемых результатов - ваша программа, скорее всего, не будет принята, как бы красиво вы её не запрограммировали. Помните: пользователю всё равно как и какими средствами вы реализовали программу. Заказчику нужен результат работы программы, получаемый на заданном количестве ресурсов. Такие интересные сведения как то, что вы написали программу на “C”, а не на Basice, оставьте своему коллеге-программисту. Нет, пользователю можно сказать об этом, но только тогда, когда он об этом спросит.

Отсюда же следует, что сначала цель работы программы, а уж потом её интерфейс. То есть, угождая заказчику и реализуя именно тот интерфейс, о котором просит заказчик, не забудьте про цели написания программы.

Вообще в программировании плохо работает знаменитый торговый принцип «клиент всегда прав». Для продажи продукта, в том числе и программ, этот принцип подходит, но для достижения результатов очень часто не просто обременителен, но и вреден. Все вдумчивые пользователи продуктов фирмы Microsoft могут подтвердить это. Во-первых, пользователь часто ищет царские пути на вершину. Во-вторых, пользователь часто не знает, чего хочет (см. выше и более подробно ниже). В-третьих, пользователь часто не представляет к чему приводит внедрение программного продукта.

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

Заказчик может потерять интерес к программе, потому что в процессе приёма он понял, что ему нужно совсем другое, а отнюдь не то, что реализовано. То есть: для того, чтобы сформулировать правильно требования к реализуемой системе, необходимо поработать хотя бы с её прототипом. Как правило, заказчик не имеет этой возможности. Тогда реализованная система выступает в роли собственного прототипа. Заказчик теперь может правильно сформулировать требования к заказу, но заказ-то уже выполнен. Это обычная ситуация, которая в последнее время в связи с возрастающей компьютерной грамотностью возникает всё реже. Тем не менее, какой бы не была компьютерная грамотность, эта ситуация будет иметь место. Одно дело знать о такой ситуации, а другое самому её пройти: «Чтобы понять, что такое плавать – надо залезть в воду».

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

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

Во-вторых, широкое внедрение программного обеспечения в производство имеет множество побочных, а для заказчика неожиданных эффектов. Перечислим основные из них.

Внедрение программного обеспечения в производство:

1. Меняет схему информационных потоков и документооборота. Например, при автоматизированном расчёте зарплаты, выводятся личные расчётные листки, а при ручном расчёте этого не делается. Или, при внедрении на предприятии электронной проходной появляется такой ежедневный документ как «список лиц нарушивших график прихода/ухода», который поставляется в отдел кадров. Ясно, что такого документа нет, при наличии обычной проходной.

2. Требует изменения штатного расписания предприятия: появляются новые должности и специальности; некоторые старые должности становятся ненужными. Очень часто появляются и новые подразделения, в свою очередь может потребоваться ликвидация старых подразделений. Мы все прекрасно знакомы с тем, что внедрение вычислительной техники привело к появлению на предприятиях должностей программист, инженер-электроник и т.д., отделов «вычислительной техники». С другой стороны, с внедрением электронного черчения исчезли такие должности как «чертёжник/ца». Внедрение обычных текстовых процессоров значительно уменьшило число машинисток.

3. У многих должностей изменяется состав обязанностей, уровень ответственности и требования к квалификации. Ранее инженер писал документ вручную и нёс его машинистке, теперь он может полностью набрать документ (во время составления документа) и сразу вывести его на печать; но теперь к квалификационным требованиям инженера добавилось «знание компьютера». Что очень важно, меняется значимость должностей, а также людей их занимающих. Последнее многими воспринимается весьма болезненно.

4. Изменяется трудоёмкость автоматизированного процесса, а, следовательно, должны быть пересмотрены нормативы и стоимости на заданные составы работ, да и сами составы работ. Внедрение программного обеспечения может не снизить, а увеличить трудоёмкость автоматизируемого процесса. Не следует забывать, что при внедрении автоматизированного бухучёта нигде не отказались от одновременного ведения ручной документации. Или при автоматизации учёта на складе возникает маленькая проблемка ввода накладных: их надо писать вручную, а также вводить в компьютер.

5. Автоматизированный документооборот в условиях России часто дороже ручного. Всё в соотношении заработной платы и стоимости вычислительной техники и расходных материалов. В России стоимость компьютера около 1000$ USA при средней заработной плате 200$ USA, но у низко оплачиваемых сотрудников ещё меньше. А в США при той же стоимости компьютера средняя заработная плата около 3000$. Отсюда видно, что в России выгоднее нанять низко оплачиваемого сотрудника, чем даже просто приобрести компьютер. С другой стороны, опять-таки набор накладных на складе на компьютере: понадобится сам компьютер, принтер и регулярная смена картриджей на принтере, что на порядок по стоимости превышает стоимость бланков накладных и шариковой ручки.

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

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

Вопросы к главе 2.
  1. Основное отличие технологии программирования от обычных технологий.
  2. Причины отличия технологии программирования от обычных технологий.
  3. Перечислите последствия внедрения программного обеспечения в производство.