Технология программирования

Размер: px
Начинать показ со страницы:

Download "Технология программирования"

Транскрипт

1 2) смены программного обеспечения. Чаще всего это смена операционной системы. Опять-таки, если программа использует особенности операционной системы, то она будет жить не дольше ОС, в которой работает. Но нередко это бывает ПО, которое по тем или иным причинам перестало существовать или поддерживаться производителем. Бывает и наоборот: появляется новое ПО, которое поставленную задачу выполняет лучше или быстрее, или интерфейс нового ПО более дружественен к пользователю. 3) изменения внешних условий, положений, законов. Все банковские задачи и задачи бухучёта сильно зависят от законодательства. Смена законодательства может сделать ненужным эксплуатацию программы вообще или в том виде, в котором она существует. Предприятие может сменить номенклатуру выпускаемых изделий, часть изделий перестаёт выпускаться. Соответственно, становятся ненужными программы, используемые при выпуске этих изделий. Могут измениться временные требования к получению результатов работы программы. Пусть программа выполняла некий еженедельный прогноз, а теперь потребовался ежедневный. Или на выпуск некоего отчёта отпускали ранее две недели, а теперь стали требовать через три дня. Может смениться администрация, и новый начальник может потребовать совершенно другой отчётности. Вообще административная поддержка существования программы очень много значит, но об этом см. далее. Может смениться обслуживающий персонал. Если ваша программа неявно существенно использует квалификацию обслуживающего персонала, то при уходе квалифицированного персонала всякое возможно. Либо ваша программа используется в службе технической или другой поддержки, тогда она так или иначе должна согласовываться с менталитетом пользователя. Представьте, что вы сменили рынок, и теперь ваша продукция продаётся в мусульманских странах, а не европейских. Могут измениться технологические нормы на выпускаемую продукцию. Пусть, например, изменился ГОСТ и вышел новый, который ужесточил технологические нормативы. Очень даже может быть, что ваша программа к этому не готова. Внешних причин смерти можно найти множество. Однако бывают всётаки и внутренние причины смерти программы, но связаны они почти всегда либо с недостаточной квалификацией разработчика, либо с его недобросовестностью, а, изредка, и прямым злым умыслом. Пусть программисту утверждают, что некий массив не будет более N значений. Новичок и вставит в программу массив ровно на N значений. В результате чего программа не сможет обработать случай на N+k значений. Опытный программист либо задаст размер массива с запасом, либо сделает программу настраивающейся на заданное число значений. Пусть программист отладил программу так, что она обрабатывает 70% возможных случаев и не успевает отладить оставшиеся, так как необходимо уже сдавать программу. Тогда, дабы не потерять премию, недобросовестный разработчик может пойти на сдачу программы, объявив о её 100% готовности. Недобросовестность здесь проявляется не в том, что вы не отладили программу МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ухтинский государственный технический университет» (УГТУ) Г. Н. Гатин Технология программирования (практический аспект) Учебное пособие 2-е издание, переработанное Рекомендовано федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский государственный технический университет имени Н. Э. Баумана» в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки «Информационные системы и технологии» Ухта

2 УДК Г 23 Гатин, Г. Н. Технология программирования (практический аспект) [Текст] : учеб. пособие / Г. Н. Гатин. 2-е изд., перераб. Ухта : УГТУ, с.: ил. ISBN Учебное пособие по курсу «Технология программирования» написано на основе одноимённого курса лекций, читаемых автором в Ухтинском государственном техническом университете. В связи с выходом новых учебников по технологии программирования, в основном переводных, остро встал вопрос об учебнике по технологии программирования, исходящем из российских реалий, минимальным по объёму и понимаемым студентом. Учебное пособие в равной мере освещает как вопросы управления проектами, так и собственно технологические моменты современного программирования: ООП, CORBA, COM-технологии, переход от исполняемых модулей к промежуточным формам (байткоды). Подробно рассмотрены технологические вопросы алгоритмизации, данные, методы отладки, технологические фазы производства программного обеспечения. Пособие содержит достаточное количество контрольных вопросов для самостоятельной работы студента и самоконтроля. Учебное пособие предназначено для преподавателей и студентов специальности ИС, осваивающих методы и технологию создания программного обеспечения в рамках дисциплин «Технология программирования» и «Объектно-ориентированное программирование». Рекомендовано федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский государственный технический университет имени Н. Э. Баумана» в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки «Информационные системы и технологии». Регистрационный номер рецензии 1730 от г. Рецензенты: А. П. Петровский, зав. кафедрой полевой нефтегазовой геофизики Ивано- Франковского национального технического университета нефти и газа, академик Украинской нефтегазовой академии, почетный разведчик недр Украины, доктор физико-математических наук; А. В. Назаров, доцент, кандидат технических наук. ISBN Ухтинский государственный технический университет, 2003, 2012 Гатин Г. Н., 2003, ТЕХНОЛОГИЧЕСКИЕ ПРОЦЕССЫ И ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В предыдущей главе мы определили, что такое программа, и дали название технологических стадий в программировании. Уже при изложении истории видно, что понятие программа на протяжении истории, меняет своё содержание и свойства. Определение программы (отсюда далее под термином «программа», если это не приводит к противоречиям или разночтениям, будем понимать как одиночную программу, так и программный комплекс произвольной величины) как последовательности команд для ЦПУ/процессора хотя и правильное, мало что даёт в практическом плане. С другой стороны, исходный модуль, объектный модуль, загрузочный/исполняемый модуль это всё программа, однако сегодня существуют технологические схемы, в которых нет фактически исполняемого модуля. Так что понимать под программой? Когда и где появляется этот объект? Куда пропадает? И пропадает ли? Очевидно, что следует соотнести всё это с технологическими процессами или стадиями. В технологии принят термин жизненный цикл программного обеспечения, который очень хорошо отражает содержание вопроса. Рассматривая жизнь живого существа, мы обнаружим, что само живое существо весьма разное на каждом этапе развития. Если медвежонку, к примеру, требуется защита, то от взрослого медведя может потребоваться защита. Куколка настолько отличается от бабочки, что даже среды их существования различны. Исходный модуль столь же сильно отличается от исполняемого, но, очевидно, что это разные стадии существования одной ипостаси программы. Именно поэтому термин жизненный цикл программного обеспечения достаточно хорошо передаёт суть дела, только не следует понимать его буквально. Термин следует понимать в смысле, что любой объект создаётся, существует и, рано или поздно, прекращает своё существование. Сама же терминология прижилась, и её стали применять и к другим понятиям, например жизненный цикл ошибки [22]. В литературе нередко муссируется вопрос о причинах смерти программы. Несмотря на свою академичность, этот вопрос имеет и свою практическую сторону. Интуитивно ясно, что программа сама по себе умереть не может, то есть нет очевидных внутренних причин смерти программы, но имеются внешние. Программа перестаёт эксплуатироваться, а следовательно, и существовать по причине: 1) смены технического обеспечения. Если программа использует технические особенности машины, а такая ЭВМ, к примеру, перестала выпускаться и заменяется на другую. Даже сейчас, когда вся технология строится так, чтобы программа не использовала особенностей ЭВМ, это может произойти. Например, DOS-программа, которая работала с CGA-монитором, может не пойти на VGA-мониторе. Или: программа использовала для вывода графики перьевой графопостроитель, а сейчас всю графику выводят на струйных или лазерных принтерах; 31

3 Вопросы к главе 1 1. Выполнить краткий обзор истории технологии программирования. 2. Что такое машина фон Неймана? Основные принципы организации универсальной ЭВМ. 3. Что такое «программирование в коде» основные принципы, достоинства и недостатки? 4. Что такое транслятор? Редактор связей? Загрузчик? Почему они существуют? 5. Что такое исходный, объектный, загрузочный модули? Почему они существуют? 6. Краткая характеристика архитектуры IBM/360 сравните технические характеристики этой системы с техническими характеристиками современных ЭВМ. 7. Представьте, что вы программируете в коде: перечислите основные технологические моменты создания любой программы. 8. Что такое алгоритмический язык? Основные достоинства программирования на алгоритмическом языке? Недостатки? 9. Что такое операционная система? Почему они появились? 10. Что такое система команд ЭВМ? Чем ограничивается количество команд машины? 11. Что ограничивает размер байта? Что ограничивает длина команды машины? 12. Что такое программа для ЭВМ? К каким трём типам объектов можно отнести программу? Последствия этого. 13. Причины появления SQL? 14. Какие проблемы разрешали БД? 15. Чем Assembler отличается от алгоритмического языка? 16. Программирование на Assembler. Чем оно отличается от программирования в коде? 17. Что такое СУБД? 18. Что такое БД банк данных? 19. Перечислите технологические периоды развития ЭВМ. 20. Перечислите основные технологические фазы. 30 ПРЕДИСЛОВИЕ К ОБНОВЛЁННОМУ КУРСУ «ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ» Методические указания по курсу «Технология программирования» были написаны в 2002 г., а изданы в 2003 г. Автор рассматривает этот труд как учебник. Тогда, фактически, не было учебника по технологии программирования, хотя в англоязычной среде они уже появились. Однако, начиная с 2003 г., появилось множество переводных и оригинальных учебников по технологии программирования. Это свидетельствует о том, что дисциплина сложилась. Определился круг рассматриваемых ею вопросов, определилась её структура. Но обзор литературы показывает, что российские и англоязычные учебники (американские) существенно разнятся по содержанию и средним объёмам. Американские источники в основном рассматривают вопросы организации производства программного обеспечения (ПО), проектирования. Средние объёмы этой литературы страниц текста. Российские учебники в меньшей степени касаются организации производства с большим уклоном именно на технологические методы разработки программ (ООП и СОМ), средние объёмы учебников страниц. Это отражает состояние производства ПО и экономики вообще в России и США. В США сложившаяся структура производства, более ста лет капитализма. Основная проблема в том, что общепринятые способы управления техническим производством не дают обычных результатов в производстве ПО. Сами технологические методы описываются в специальной литературе для программистов, например: Технология COM+ Дж. Мюллера. Литература по технологии программирования чаще всего ориентирована на руководителей разработки ПО, которые в США, обычно, отнюдь не программисты, а менеджеры, читай управляющие. В России же ещё не устоялась капиталистическая организация работ на производстве вообще и в производстве ПО в частности. С другой стороны, руководителями работ в России в производстве ПО, как правило, являются программисты, а не управляющие. Отсюда и разница в подходе к предмету. Невозможно при написании учебника не учитывать жизненных реалий. К тому же слепое копирование западных технологий ещё ни разу в России не принесло ожидаемых успехов. Его, в общем-то, следовало ожидать: слишком разные условия жизни социальные, национальные, экономические, климатические и т. д. Отсюда, требуется учебник, средний по объёму, в идеале не более 300 страниц, в равной степени освещающий вопросы как организации производства, так и методы программирования, и достаточно доступный для понимания студента. Последнее очень важно. Дело в том, что для второкурсника, а технология программирования читается на втором курсе, большинство понятий и сведений технологии достаточно абстракты, новы и непонятны. Сам термин «производство ПО» неожиданен: какое может быть производство в таком творческом процессе, как написание программ? Предмет наполнен эмпирикой, а студент пока не умеет воспринимать эмпирические дисциплины. 3

if ($this->show_pages_images && $page_num < DocShare_Docs::PAGES_IMAGES_LIMIT) { if (! $this->doc['images_node_id']) { continue; } // $snip = Library::get_smart_snippet($text, DocShare_Docs::CHARS_LIMIT_PAGE_IMAGE_TITLE); $snips = Library::get_text_chunks($text, 4); ?>

4 С другой стороны, следует показать причины технологических изменений в программировании. Большинство учебников принимает как должное, что процедурное программирование сменилось ООП-подходом. При этом изложение нередко ведётся так, что, кажется, ООП было всегда, а как программировали ранее не так уж и важно. Тем не менее, у вдумчивого программиста возникает масса вопросов: Почему ООП не сместило процедурное программирование сразу по появлении? Можно ли сейчас писать в процедурном стиле? Так ли уж нужны классы, инкапсуляция, наследование и т. д.? Что явилось причиной успеха ООП? Последний вопрос чрезвычайно интересен, так как косвенно ставит вопрос когда мне (программисту) очередной раз переучиваться? Как видите, вроде бы чисто теоретический вопрос, а умные головы делают из него сугубо практические выводы. Отсюда мы видим, что разделение «теория практика» нередко достаточно условно. Сколько сломано копий по поводу инкапсуляции, но практики упорно мало используют сей драгоценный, с точки зрения теоретика, инструмент. Почему? Есть ведь причины, по которым теоретикам очень хочется ввести чистое ООП, а практики упорно используют то, что им удобно. Б. Страуструп называет жульничеством обход инкапсуляции, а практики попрежнему получают доступ даже к защищённым членам классов вопреки всякой инкапсуляции. Нам кажется, ларчик открывается весьма просто. Сама по себе инкапсуляция не увеличивает производительности труда программиста, а вот лишний код писать приходится, одних только функций Get/Set сколько придётся написать, а если у вас в классе все члены «public», то всего этого не надо. Вообще, производительность труда программиста и есть тот краеугольный камень, который определяет, будет ли жить предлагаемая технология. Сколько писали теоретики о вреде оператора go to, а практики продолжают его использовать. Всё правильно, без go to программа длиннее, как ни странно, нередко запутаннее, а значит, и отлаживать её придётся дольше. Всё правильно, не использование go to приводит к снижению производительности труда. Конечно, не всякая технология призвана повысить производительность труда. Согласны. Возьмём, например, COM-технологию. Сама по себе технология достаточно сложна, требует серьёзной квалификации, код по объёму увеличивается процентов на тридцать-сорок, да и работает не слишком быстро. Кажется, что эта технология лишь снижает производительность труда программиста. Но программист не пишет и не отлаживает сам значительный объём кода, который пришлось бы писать вместо уже используемого по COMтехнологии готового кода. Если принять во внимание эти возможные издержки, то мы обнаружим, что в итоге программист сэкономил много времени и сил и в сумме выиграл не только во времени, но и в производительности труда. Однако едва ли хоть один создатель новой технологии задумывается над повышением производительности труда программиста. Реальные цели любой создаваемой технологии весьма далеки от этого. Полученная в результате использования технологии производительность труда программиста определяет 4 За чрезвычайно короткий период времени ПЭВМ вытеснили большие ЭВМ, теперь их называют mainframe, почти отовсюду. ПЭВМ повлияли не только на программирование, но значительно изменили подходы к архитектуре ЭВМ, построению сетей ЭВМ и т. п. Сейчас трудно назвать область, на которую появление ПЭВМ не оказало бы существенного влияния. Простое сравнение технических характеристик ПЭВМ и старших моделей системы IBM/370 показывает, что у вас на столе стоит не менее десяти больших машин, и если ранее одна ЭВМ занимала не менее одного зала, то теперь она помещается на краю стола. Широкий приход ПЭВМ ознаменовал собой четвёртый этап в технологии программирования. При этом можно выделить два подэтапа: DOS-период это период до выброса на рынок операционной системы Windows-95, и Windowsпериод который длится и поныне. (Здесь и далее имеется в виду именно DOS для ПЭВМ, если не будет явно оговорено противное.) На рынке снова появились ЭВМ различных конструкций: от чисто игровых Spectrum, до профессиональных Risc-архитектура: Sun; IBM RISC Наиболее распространёнными были (и остаются) два клона: Macintosh и ПЭВМ на основе процессора Intel: IBM XT и затем IBM AT. С точки зрения технологии программирования, четвёртый этап характеризуется следующими явлениями: 1) появлением так называемых «коробочных» программных продуктов; 2) победным шествием языка C, а затем C++; 3) внедрением ООП (объектно-ориентированное программирование) в широкую практику; 4) появлением визуального программирования; 5) внедрением сетевых технологий; 6) появлением многокомпонентного программирования; 7) появлением технологий, не зависящих от платформы: Java и C#. Далее мы достаточно подробно рассмотрим все эти явления, но одно следствие всего вышесказанного отметим здесь. Программирование стало более доступным и внешне совсем простым. Появилось множество программных сред со средствами программирования. Молчаливо предполагалось, что любой (!) сможет этими средствами реализовывать для себя специфические задачи, возникающие в процессе обработки данных, что делает, в свою очередь, ненужным наличие программиста. Практика показала, что 90% пользователей не собираются программировать. Оставшиеся 10% используют средства программирования на любительском уровне, что естественно, так как они не программисты. Таким образом, реально спрос на программистов лишь увеличился. Тем не менее, появление сред со средствами программирования привело к появлению класса программистов-любителей. Как ни раздражает некоторых «профессионалов» наличие любителей, следует понимать, что ненормально как раз обратное их отсутствие. Занятие становится профессией тогда, когда оформляются все три класса работников: любители профессионалы исследователи. В этом смысле профессия «программист» завершила своё полное оформление лишь к восьмидесятымдевяностым годам XX века. 29

5 сты научились писать операционные системы. Написать небольшую операционную систему теперь под силу одному программисту. Трудоёмкость разработки операционной системы по-прежнему остаётся достаточно высокой, но это уже десятки человеко-лет, а не сотни, как оценивалось ранее. Обращаем ваше внимание, что сложность разработки не изменилась, уменьшилась трудоёмкость разработки. Трудоёмкость снизилась, во-первых, потому, что появилась теория и грамотный программист теперь может не изобретать велосипед. Во-вторых, увеличилась производительность труда, так как программирование на алгоритмическом языке оказалось гораздо производительнее программирования в коде, а результаты не менее эффективными. В- третьих, появилось множество инструментов программирования, ускоряющих процесс разработки; в-четвёртых, сама техника стала другой и, в частности, более производительной, одно дело программа в виде колоды перфокарт и совершенно другое хранение и корректировка программы на диске. В это же время появились первые сети и первые терминальные устройства. Скорость работы ЦПУ и надёжность работы техники позволяли одновременную работу множества пользователей. Операционные системы стали многозадачными. Всё это поставило вопрос ввода данных и программ не только с перфокарт или магнитного носителя, но в диалоге, а в качестве устройства ввода в диалоге мог выступить только телевизор/дисплей/монитор. Однако для этого монитор должен был обладать определённой самостоятельностью. Фактически, терминальное устройство должно было быть маленькой ЭВМ, которая могла хотя бы сохранить данные на время, пока основная большая ЭВМ не занималась этим терминальным устройством или вообще отключалась. В каком-то смысле, терминальные устройства были прототипами ПЭВМ, тем не менее, технологическая революция пришла с совершенно другой стороны, откуда её совсем не ждали. Между 1970 и 1980 (1973) гг. появились первые процессоры. Разрабатывались они как универсальные устройства управления другими техническими устройствами или средства управления технологическими процессами. Поскольку процессоры могли считывать команды с заданного технического устройства, то их можно было использовать в ЭВМ вместо ЦПУ. Это и было сделано Стивом Джобсом и Стивом Возняком при построении их первой персональной ЭВМ Apple. Идея Джобса и Возняка была в следующем: необходимо собрать настольную программируемую ЭВМ из стандартных блоков. Не программируемый калькулятор, а именно универсальную ЭВМ. Стоит ли упоминать о невероятном успехе этой идеи. История повторилась. Появление первых персоналок большинство производителей восприняло как чистое баловство (сравните с появлением первых трансляторов). Даже выпуская ПЭВМ, фирма IBM довольно долго считала, что никуда, кроме игр и развлечений, они использоваться не будут. Всё это привело к множеству неверных технических решений, от которых болезненно впоследствии избавлялись. А что произошло? Произошло внедрение ПЭВМ в производство. Произошла технологическая революция. широту использования технологии и её, так сказать, выживаемость. Если при решении некоторой задачи невозможно обойтись без плохой технологии, то программист всё равно будет её использовать, но если есть выбор, выбрана будет та технология, при использовании которой выше производительность труда. С другой стороны, не следует забывать, что иногда нас принуждают работать по той или иной технологии, например реализуется некий алгоритмический язык, в котором нет оператора go to. Единственное, что тогда можно сказать, что невозможно провести сравнительный анализ. Технология программирования межпрофильная дисциплина. Конечно, в курсе будет разбираться, например, технология ООП, но освещаться эта технология будет именно в свете технологии программировании. Для более детального разбора ООП следует обратиться к соответствующей литературе, например [5; 9]. Не следует забывать истории развития дисциплины. Только в свете истории можно оценить принимаемые технические решения, и очень часто выясняется, что не всё то золото, что блестит. Я всегда напоминаю, что тридцать лет назад наши технические возможности были на несколько порядков слабее, но мы считали на наших машинах всю бухгалтерию. Сейчас на столе у бухгалтера стоит (часто не одна) ПЭВМ, технические возможности которой просто невероятны (если вернуться на тридцать лет назад), но на этой ПЭВМ считают всё ту же бухгалтерию. Вот и оцените достижения прогресса в этой сравнительной плоскости. Поэтому одна из задач курса стимулировать студента к анализу используемых приёмов и методов. Нередко сделать это не так просто, так как в используемой литературе по методам программирования просто забывают про издержки и недостатки используемых приёмов. 28 5

6 ВВЕДЕНИЕ В среднем будущего программиста обучают программировать. Его знакомят со структурой ЭВМ электронно-вычислительной машины, знакомят с одним-тремя языками программирования, банками данных и т. п. Но уже при реализации курсового проекта у студента появляется множество вопросов: какая требуется форма отчётности; можно ли использовать тот или иной инструмент; что изменится, если будет использоваться вот такой подход? Обычно все эти вопросы касаются организации работы при программировании или, другими словами, всплывают вопросы технологии программирования. И вроде бы ответы на возникающие вопросы есть, так как элементы курса (технология программирования) есть в любой программисткой литературе, с другой стороны, множество вопросов, взаимосвязей и особенностей программирования именно в свете технологии нигде не освещаются, и каждый программист по мере развития вновь находит всё множество приёмов и методов. Это хорошо, когда он попал в крепкую команду программистов, где есть чему и у кого учиться, но гораздо чаще начинающий специалист оказывается в положении человека, обучаемого плаванию «методом бросания в холодную воду». Всякий, кто пытался на Basic реализовать серьёзную задачу, а не одноразовую программку, понимает, к чему приводит подобное обучение. Технология появляется тогда, когда появляется производство. Производство находится где-то между искусством и ремеслом. Ремесло не обладает технологией в силу ограниченности решаемых задач, хотя имеет множество способов и приёмов. Искусство не обладает технологией в силу уникальности каждой решаемой задачи, а потому набор способов и методов решения поставленной задачи часто точно также уникален и малоприменим, нередко совершенно не применим при решении другой задачи. Однако, в искусстве там, где оно смыкается с наукой, происходит появление и оттачивание новых технологий, и в этом смысле искусство стоит на плечах технологии производства. Для большинства термин «производство программ» (программного обеспечения) звучит достаточно дико, хотя никто не возражает против «производства кино», например. Тем не менее, существует процесс производства программ. Автор ещё раз подчёркивает, что это именно производство. Раз существует процесс производства, то существует и его технология. Таким образом, «технология программирования» изучает методы, способы, приёмы, используемые при производстве программ или программного обеспечения. Можно и по-другому: технология программирования изучает процесс производства программного обеспечения. Таким образом, к производству программ применимо множество производственных терминов таких, как трудоёмкость и производительность труда, технические, стоимостные и человеческие ресурсы и т. д. Но в программировании содержание этих терминов, их значения, выраженные в числах, существенно зависят от такого ресурса, как личность программиста. Все курсы программирования, в силу того, что это именно курсы программирования, не рассматривают программиста как существенное звено при написании про- 6 Таким образом: БД банк данных можно определить как совокупность программного обеспечения, форматов хранения данных, алгоритмов обработки данных и пространства на физическом носителе/носителях, отведённом для хранения данных. БД отвечает за целостность данных, безопасность доступа к данным и удовлетворительное время поиска данных независимо от их объёма. Большинство развитых БД имеют свой внутренний формат хранения данных, который скрывается не только от пользователя, но в общем случае и от программиста. Здесь скрывается используется в том смысле, что программист может не знать формата хранения данных и их физического расположения. Однако первые БД были достаточно тяжёлыми объектами в работе не только для пользователя, но и для программиста. Логическая структура данных обычно отражала иерархическую организацию данных, естественную для человека. Прямое отображение иерархической организации данных на физическое пространство носителя приводило к необычно сложной организации указателей. Первые БД использовали либо жесткую иерархическую структуру, либо сложный план навигации по указателям на физическое размещение данных на магнитных носителях. Хотя такие БД могли быть эффективными в обработке специфических данных и запросов, разработанных для них, они были абсолютно негибкими. Новые виды запросов требовали сложного перепрограммирования, а добавление новых типов данных влекло за собой полное перепроектирование базы данных, хранимой в БД, а нередко и самого БД. То есть первые БД были приспособлены под конкретные данные и запросы. Эти запросы первые БД выполняли очень быстро, а нестандартный запрос мог выполняться необычайно долго, если вообще приводил к реальному результату. А потом пришёл Эдгар (Тэдд) Кодд ( ) и принёс с собой реляционную алгебру. Так гласит легенда. В своей знаменитой статье "Реляционная модель данных для больших, совместно используемых банков данных" Кодд предложил замену иерархической или навигационной структуры простыми бухгалтерскими таблицами, содержащими строки и столбцы. Кодд предложил реляционный БД. Основное его достижение, что он предложил строгую математическую теорию построения реляционных БД. Уже в 1981 г. фирма IBM выпустила первый реляционный БД SQL/DS.DB2. Этот БД существует и поныне и позиционируется просто как DB2. Для технологии программирования важно, что незнание программистом физической организации хранения данных необратимо приводит к появлению средства запроса данных из БД. Раз программист не может обратиться непосредственно к адресам, он должен каким-то образом указать БД, какие данные ему нужны. Это привело к появлению структурированного языка запросов (SQL), разработанного Чемберленом и Реем Бойсом. Теперь программист не читает записи и не продирается сквозь частокол указателей при поиске данных он выполняет запрос на данные к БД, а БД либо возвращает ему данные, либо сообщает, что таких данных не найдено. На этом этапе программисты научились писать трансляторы. Была разработана теория трансляции, и если ранее трудоёмкость написания транслятора оценивалась в 10 человеко-лет, то теперь до 6 человеко-месяцев. Программи- 27

7 Уже при реализации программ корректировки программисты столкнулись с проблемой поиска данных вообще и скорости поиска в частности. Кроме того, большое число файлов в файловой системе приводило к неоправданно высокой трудоёмкости реализации программного обеспечения (ПО). Любое развитие технологии всегда либо уменьшает трудоёмкость, либо повышает производительность труда. Повысить производительность труда всегда сложнее, чем снизить трудоёмкость. Таким образом, прежде всего, программисты придумали, как написать в некотором смысле универсальные программы ввода, корректировки, удаления. То есть эти программы стали писаться так, чтобы они не зависели от формата файлов. Но для этого потребовалось неким образом описывать формат файла, после чего на этот формат можно было настроиться программам обработки и корректировки данных. Такие системы стали называться базами данных. Базы данных позволили не зависеть от формата конкретного файла, но некоторые форматы были очень нестандартные, то есть они не вписывались в общую систему базы данных. Это приводило к расширению базы данных, затем находился очередной неприятный формат файла история повторялась. Рано или поздно база данных становилась неуправляемой. Кроме того, оставалась проблема поиска. Некоторым прогрессом можно было считать появление СУБД системы управления базами данных. Это уже непосредственный предок банка данных. СУБД сгладили проблему хранения данных, они пытались так или иначе решить проблему поиска данных. Однако обострилась проблема объёма данных. При работе с базами данных программист, а при эксплуатации и пользователь, должны были знать структуру базы, то есть для того, чтобы найти данное, мы должны были знать, где оно находится, что при лавинно растущем объёме данных представляло проблему. Не только сами данные, но уже каталоги данных были велики. Первые СУБД, собственно, и автоматизировали работу с каталогами данных, сами данные хранились в отдельных файлах. Недостаток этой системы был в том, что отдельный файл всегда можно было удалить независимо от СУБД. Тем не менее, такая схема хранения данных сохранилась до наших дней. Её достоинство простота и малые размеры ПО. Для хранения средних объёмов данных такая схема вполне подходит, хотя вопросами целостности базы данных вынужден заниматься программист. Как только СУБД стали удовлетворительно решать вопросы поиска данных в больших объёмах они превратились в банки данных. Однако линия разделения БД и СУБД не только в этом. Достаточно быстро стало ясно, что нельзя хранить значительные объёмы данных в рядовой файловой системе. Дело не только в том, что пользователь может уничтожить какой-либо файл СУБД. Дело в надёжности технических устройств, а в семидесятых годах XX столетия этот вопрос был гораздо более актуален, чем сейчас. Чем больше по размеру был ваш файл, тем больше была вероятность технического сбоя при работе с таким файлом. Отсюда: БД должен был, хотя бы чисто технически, гарантировать целостность данных. 26 грамм. Иначе и быть не может, поскольку это вопросы технологии программирования. Только в технологии программирования могут быть рассмотрены вопросы влияния тех или иных ресурсов на конечный результат программирования программу. А можно ли не зависеть от личности исполнителя, читай программиста? Можно ли в одиночку реализовать большой комплекс программного обеспечения? Можно! К чему это приведёт? Чем отличается подобный комплекс от комплекса ПО, реализованного коллективом программистов? Случайны ли эти отличия, или так неотвратимо будет всегда? С одной стороны, ответ лежит на поверхности: все знают отличия кустарного продукта от промышленного. С другой стороны, любому специалисту приходится делать выбор между собственной реализацией поставленной проблемы и приобретением готового программного продукта. Заметим, что окончательный ответ на этот вопрос лежит, скорее, в области этики программирования, а не технологии, однако ответы на многие вопросы этики программиста тесно связаны с технологией программирования. За время своего существования, шестидесятые годы XX века начало XXI века, программирование сильно изменилось. Автор имеет в своём активе программу, написанную в коде ЭВМ «Минск-22». Сравните программирование в коде с программированием в Visual C++ (или C++ Builder) под Windows. Так ли существенно изменилась сама методология программирования? Неужели автору приходилось учиться «с нуля» каждые десять лет? Если все эти вопросы рассмотреть в контексте технологии программирования, то мы с удивлением обнаружим, что сама основа распределение в памяти машины и на внешних устройствах ЭВМ команд и данных, осталась, хотя теперь средний программист стоит значительно дальше от этого процесса, чем раньше. Такая отстранённость программиста от процесса «технической сборки программы» создаёт иллюзию ненужности знания «технических деталей», не говоря уже о понимании сути происходящего. Автор достаточно далёк от позиции обязательного требования досконального знания всех технических деталей. Сегодня это вряд ли возможно. Это в добрые семидесятые прошлого века программисты могли позволить себе быть универсалами. Однако автор считает, что только понимание сути процесса создания программы позволяет «не знать» некоторых технических деталей. Процесс же изучается только в технологии и нигде более. Вообще в программировании на сегодня (начало XXI века) сложилась парадоксальная ситуация. Само по себе программирование стало существенно сложнее (ООП объектно-ориентированное программирование и многокомпонентное программирование), но, благодаря визуальным средствам программирования (а они приходят и в Unix), создалась иллюзия простоты и доступности. Подобная ситуация приводит к широкому появлению «эникейщиков» (press any key) и «программистов», работающих на уровне чуда! Частично такая ситуация создалась стараниями рекламных агентств, представляющих продаваемое ПО, частично фирмами, его производящими, сознательно полностью не документирующими производимое ПО. Но в основном ситуация сложилась стараниями самих программистов, предельно упрощающих себе работу и перекладывающих рутинные функции на машину. Увы, прогресс имеет и оборотную сторону. С одной сторо- 7

8 ны, программист пишет машинно-независимую программу, но с другой стороны, он становится дальше от машины. С одной стороны, программист мыслит в терминах объектов, их свойств и методов, с другой стороны, его программа становится более длинной и менее оптимальной. За всё надо чем-то платить. Грамотный программист ясно представляет издержки новых операционных систем и методов программирования. Он понимает, что программа, написанная в парадигме ООП, может быть более длинной и, возможно, менее оптимальной, чем обычная процедурная программа, но сдаст программист такую программу значительно быстрее, да и отладит лучше. К тому же, как оказывается, пользуясь ООП, можно отлаживать значительно более длинные программы, чем при обычном процедурном программировании. Вот это «быстрее и лучше» и определяет появление новых методов в программировании. Если новшество увеличивает производительность труда программиста, то оно останется, как бы и кем бы оно ни было охаяно. Время самый дорогой ресурс в программировании. Всё развитие технологии программирования можно и нужно рассматривать с точки зрения увеличения производительности труда как отдельных программистов, так и коллективов программистов. Только тогда, когда происходило увеличение производительности труда, новые методы вытесняли старые. Не следует забывать, что увеличивать можно производительность труда как программиста, так и пользователя. Последнее сделал купец Билл Гейтс, выпустив свой Office и Windows. Теперь, как бы ни ругали программисты Windows и Office, но фактическим стандартом у чиновников является Word, Excel и Windows. Можно, конечно, ссылаться на безграмотность чиновников (в программировании), но отрицать увеличение производительности труда чиновника невозможно. От себя заметим, что плохо не то, что Microsoft выпустила вышеуказанные продукты, плохо то, что Билл Гейтс их начал продавать полусырыми. Кстати, почти одновременно с указанными событиями в машиностроительном и проектном черчении прошло победное шествие такой программы, как AutoCad фирмы AutoDesk, и, заметьте, почти полное отсутствие нареканий! Автор считает, что для студента-второкурсника технология программирования трудный предмет. Как правило, у студента нет ни одного реализованного проекта, понимание сути программирования либо отсутствует, либо ещё неразвито. Поэтому многие утверждения и понятия технологии для студента-второкурсника достаточно абстрактны. Как это ни парадоксально, но именно технологию программирования, предмет, наполненный эмпирикой, студенты воспринимают как нечто оторванное от жизни. Многие требования технологии совершенно непонятны, тем более что современные средства программирования позволяют всё делать как раз наоборот. Конечно, лучше всего читать технологию на четвёртом курсе, когда у студента за спиной три-четыре курсовых проекта. Однако не следует забывать старую истину: «Умные люди учатся на ошибках других». Безусловно, мы сделаем не одну свою ошибку, но давайте стремиться следовать этому утверждению. Существует и прямо противоположное заблуждение: рассматривать технологию программирования как некий свод волшебных правил и заклинаний, 8 серьёзную проблему, которая актуальна до сих пор. Достаточно ознакомиться с результатами работы фирмы Microsoft. Впрочем, это отдельный разговор. Развитие техники шло в сторону увеличения используемых ресурсов и удешевления технической базы. Тем не менее, оставались достаточно дорогие ресурсы, среди которых была оперативная память (сейчас оперативная память также представляет дорогой ресурс). Появилась идея виртуальной памяти. Потом стало ясно, что если программно можно моделировать память, то точно также можно моделировать любое техническое устройство и саму ЭВМ тоже. Таким образом, шестая версия операционной системы ОС/360 полностью базировалась на идее виртуальной машины. Сама же виртуальная память получила аппаратную поддержку, что существенно ускорило работу операционной системы. Идея виртуального устройства ясно показывает, что любое устройство можно реализовать программно, хотя чаще это называется моделированием. Справедливо и обратное: любая программа может быть реализована аппаратно! Однако с появлением системы IBM/360 развитие программирования и, соответственно, технологии программирования из маленького ручейка превращается в бурную широкую реку со множеством рукавов, течений, заливов, стариц и островов. Множество технологий начинают развиваться одновременно, параллельно друг с другом, дополняя друг друга, взаимодействуя между собой. Наиболее важным событием на этом этапе автор считает появление банков данных (БД). Сначала пришло осознание, что на универсальной ЭВМ действительно можно считать всё, что угодно, а не только вычислять. В широкой практике появились задачи бухучёта. По своей алгоритмической сути они были предельно просты: множество данных хранилось на внешнем устройстве, затем считывалось в оперативную память, там над данными выполнялись простые арифметические действия, и данные опять записывались на внешнее устройство. Именно так большинство программистов восприняло задачи бухучёта. Однако объёмы данных были необычно велики, а задачи критичны ко времени выполнения. Последние данные по зарплате поступали сегодня, а завтра необходимо было выпустить все документы по выплате заработной платы. При той технической надёжности ЭВМ, небольшой оперативной памяти и невеликом быстродействии ЭВМ подобный выпуск документов превращался в проблему. С точки зрения программиста, эти задачи были скучны. Данные хранились в некоторой файловой системе, которую под каждую задачу проектировал программист. Файловая система состояла из некоторого количества файлов, впрочем, количество это могло зашкаливать за сотню и более. Для каждого файла необходимо было написать программу ввода данных в файл, корректировки данных, удаления данных. Кроме того, требовались программы создания файловой системы, копирования и восстановления. Программ ввода, редактирования и удаления данных было столько же, сколько было файлов. Если у вас было сорок файлов, то, соответственно, вы имели дело со ста двадцатью программами. Все они были удивительно похожи друг на друга, различаясь только форматами файлов, но все программки надо было написать, отладить, документировать и т. п. 25

9 Понятия байт, интерфейс, файл и множество других были введены в употребление именно с появлением новой архитектуры. Итак, что же представляла собой конкретная модель системы IBM/360? Младшая модель IBM/360, так называемая модель 20, имела 128К оперативной памяти. Поставлялась с двумя-четырьмя дисководами (внешними), каждый объёмом 7Мгб; двумя-четырьмя ленточными накопителями на одну бобину магнитной ленты можно было записать примерно 28Мгб; перфоркарточными вводом и выводом и пишущей машинкой, как выходным устройством операционной системы. Впрочем, с пишущей машинки можно было выполнять и ввод команд системы. Рекомендуем сравнить эти характеристики хотя бы с характеристиками IBM PC XT. Кстати, наиболее распространённые тогда ЭВМ имели, чаще всего, память от 4К до 32К. Операционная система занимала 10К оперативной памяти и могла работать одновременно с тремя программами. При этом с операционной системой поставлялось несколько наиболее распространённых алгоритмических языков: обычно Fortran; Cobol; Algol и позже PL/1. Кроме того, обязательно поставлялся Assembler. Система поставлялась с полным комплектом документации. Рекомендуем сравнить с сегодняшней ситуацией в программировании. Не следует забывать, что такая машина занимала примерно полэтажа среднего здания, требовала установки искусственного климата и была ЭВМ группового пользования. Обслуживающий персонал составлял примерно электронщиков (при двухсменной загрузке); три-пять системных программистов; шесть-восемь операторов и от десяти и более проблемных программистов; кроме того, был ещё и штат администрации. Именно с приходом системы IBM/360 программирование стало понастоящему промышленным производством программ. Система IBM вытеснила с рынка все ранее существовавшие ЭВМ и этим унифицировала рынок и косвенным образом стандартизовала программирование. Что нового в технологии программирования появилось на третьем этапе? Операционная система ещё более отдалила программиста от машины. Произошло разделение на системных и проблемных программистов. Однако в среднем программисты оставались универсалами. Грамотный программист обычно знал один-два алгоритмических языка, мог работать на ассемблере. Перейти с одного языка на другой для него не составляло проблемы. Обычно на это уходил примерно один месяц сравните с переходом, при программировании в коде, с системы команд одной машины в систему команд другой, что требовало не меньше полугода упорной работы. Тогда программист мог, да и был обязан, знать всё. Время специализации ещё не наступило, время абсолютно не совмещающихся между собой машин ушло. Программисты научились писать большие программные комплексы. Не трансляторы или редакторы связей, тогда трудоёмкость этих программ измерялась цифрами порядка 10 человеко-лет. Речь идёт об операционных системах, трудоёмкость которых тогда оценивалась в несколько сотен и более человеко-лет. Организация работ по разработке большого программного комплекса представляла применив которые, любой получит работоспособную программу. Увы. В математике, литературе, программировании, да и вообще в любой отрасли, конечно же, существуют свои методы и приёмы, а также условия их применения. Достаточно открыть, например, книгу Д. Пойа Математическое открытие (1978 г.). Однако, прочитав эту замечательную книгу, мы не увидим в ней рецепта математического открытия по той простой причине, что такого рецепта не существует в реальности. Нет волшебных пассов, слов заклинаний или приёмов, позволяющих делать математические открытия. Точно так же нет их и в программировании. Какие методы и приёмы использовать при написании конкретной программы, решает такой неформализованный ресурс, как программист. Только от его знаний, умения, предпочтений и способностей зависят характеристики программы. Методы технологии могут существенно облегчить и ускорить разработку программы, но сами по себе эти методы не приводят к появлению «правильных» программ. Автор предполагает, что студент уже знает хотя бы один язык программирования и умеет писать на нём пусть небольшие, но работающие программы. Невозможно давать технологию программирования без связи с конкретными языками. Наибольшее число ссылок приведено на языках C и C++. Во-первых, эти языки, де-факто, стали стандартом. Во-вторых, наиболее последовательно идеи объектно-ориентированного программирования (ООП) проводятся именно в C++, а без ООП нет современной технологии. В завершении может быть сделана только одна рекомендация: программист программируй! Ничто не может заменить собственного опыта. Но если этот опыт не будет обдуман, пропущен через призму теории, то он не даст новых знаний и понимания. Такой опыт, скорее, есть набор ремесленных способов и приёмов, где уж тут говорить о производстве. 24 9

10 1. КРАТКАЯ ИСТОРИЯ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ (О законности термина «технология программирования») Предмет называется «Технология программирования», и согласно наименованию мы предполагаем, что в его курсе разбираются способы и методы создания работоспособных программ. В общем, это так. Однако, как всегда, при ближайшем рассмотрении дело несколько запутаннее, чем обычно кажется. Во введении мы определили, что технология появляется тогда, когда появляется производство. Затем очень кратко заметили, что если может выпускаться кино, то почему не могут выпускаться программы (под программой здесь и ниже, если это не приводит к противоречию, понимается как комплекс программ, так и одиночная программа). Параллель между кино и программами гораздо более широкая, чем многим может показаться, например: и кино и программы являются уникальными творческими объектами. Можно провести параллели как между самими объектами (кино программа), так и между технологиями производства. По многим причинам в нашу задачу не входит проведение этой параллели. Однако, следует привести цитату из [21]: Менеджеры программных проектов могут добиться большего, если будут применять методы управления, характерные для киноиндустрии. Конечно, во введении нет возможности разобраться во множестве вопросов. Но, произнося термин «технология программирования» и утверждая существование производства программ, необходимо ясно представлять, что такое программа и программирование. Нам надо знать, когда, собственно, появилось производство программ? Мы хотим быть инженерами! Роль ремесленника представляется для нас убогой (не следует забывать, что у многих ремесленников есть чему научиться). Роль свободного художника не всякому по плечу, да и количество необходимых свободных художников исчисляется единицами. Итак, технология [гр. techne искусство, ремесло, наука + logos понятие, учение] совокупность знаний о способах и средствах проведения производственных процессов (см. Словарь иностранных слов, стр. 688, 1955). Подчеркнём: производственных процессов. Естественно слышать технология обработки металлов, технология химических процессов, однако технология программирования несколько ненормальное сочетание. Никто не преполагает существование технологии математики или технологии литературы. Обычно к этим областям знаний понятие технология не применяется. Сейчас для нас это очевидно: в этих областях нет производства. Несмотря на то, что вычислительные центры при предприятиях появились более сорока лет назад, термин «производство программ» обрёл право на жизнь сравнительно недавно. Это было примерно тогда, когда широкий круг пользователей стал спрашивать, где можно приобрести программы? Тем не менее производство программ существовало уже более тридцати лет. 10 работал независимо от ЦПУ, а ЦПУ могло не приостанавливать своей работы на время работы канала или его неисправности. Распараллеливание работы канала и ЦПУ сделало возможным одновременное выполнение нескольких задач. Стандартизация подключения устройств ввода/вывода сделало конфигурацию ЭВМ изменяемой и расширяемой. 2. Введение понятия прерывания и разработка системы прерываний. Под прерыванием понималось любое событие, тем или иным способом меняющее предполагаемый ход работы ЦПУ. Прежде всего, разделили технические и программные прерывания, что сразу позволило выполнять предварительную диагностику останова ЭВМ, оператор мог предположить, кого звать: электроника или программиста. Прерывания ранжировались по приоритетам. При одновременном возникновении нескольких прерываний сначала обрабатывалось самое приоритетное. Каждое прерывание обрабатывалось собственной программой обработчиком прерывания. Прерывание могло быть маскировано и проигнорировано при выполнении конкретной программы, то есть обработку прерывания можно было отложить или вообще не делать. 3. Идея защиты адресного пространства. Адресному пространству приписывался определённый ключ защиты. Программа с одним ключом защиты не могла записать или прочитать что-либо из пространства с другим ключом защиты. Защита адресов поддерживалась на аппаратном уровне, что делало очень трудоёмким программный обход защиты. 4. Вышеописанная система не могла функционировать без набора программ, управляющих работой ЭВМ. Обработка прерывания требовала готовой программы обработчика прерывания. Стандартизация подключения внешних устройств позволила управлять устройствами единым образом, перекладывая учёт особенностей устройств на его собственные канальные программы. Вот это-то всё: обработка прерываний, управление внешними устройствами и ещё множество других функций, и возлагалось на операционную систему (ОС). Но поскольку ОС сама распределяла оперативную память под свои нужды, программист либо должен был знать, как ОС это делает, либо использовать уже готовые средства, которые позволяли бы не знать технических деталей распределения памяти. Обращаю ваше внимание, что программист может не знать технических деталей процесса распределения памяти, но обязан знать о том, что такое распределение памяти и примерно как этот процесс будет выполняться. Наличие ОС сделало невозможным программирование в коде при работе в системе IBM/360. Теперь программирование на алгоритмических языках навсегда вытеснило из широкой практики программирование в коде. Если быть более точным, то было вытеснено программирование в абсолютных адресах, поскольку программирование в относительных адресах осталось Assembler. Кроме того, осталась маргинальная ниша: системно-независимые программы. Дело в том, что саму ОС необходимо было как-то настроить на конкретную конфигурацию ЭВМ и, кроме того, каким-то образом ОС надо было установить на ЭВМ, что и выполнялось так называемыми системно-независимыми программами. Более того, почти все технические тесты также выполнялись в отсутствии ОС. 23

11 мять и прекрасно представлял, каким должно быть состояние памяти ЭВМ, мог изменить состояние памяти с пульта, передать управление в любую точку программы. При работе на языке распределение памяти выполнял транслятор, управление работой программы с пульта стало невозможным. Прогоняя программу на ЭВМ, программист теперь мог только посмотреть промежуточные или конечные результаты работы программы. Зато увидеть эти результаты можно было в нормальном человеческом виде, не надо было заниматься трансляцией плавающих чисел в десятичный вид. С одной стороны, вроде бы отладка и написание программ стали проще и естественнее, с другой стороны, технология разработки ПО изменилась. Новая технология принесла новые технологические приёмы и методы, и не все программисты сумели перестроиться. Очень многие кодировщики кодов расстались с программированием навсегда, хотя большинство сумело перейти в программирование на языках. То есть смена технологии всегда утрата определённой части человеческих ресурсов, причём нередко это касается наиболее квалифицированной части этих ресурсов. Можно и более эмоционально: смена технологии это человеческие судьбы. Ещё одно существенное замечание: при программировании на языке программист может не знать многих технических деталей, например систему команд конкретной машины. Теперь между программистом и ЭВМ появляется транслятор, а затем и операционная система. Программист становится более отдалённым от ЭВМ. Кстати, это наложило отпечаток даже на процесс отладки. Программист в коде не мог не выйти на ЭВМ, во время отладки его никто не мог заменить. Программист на алгоритмическом языке мог сдать колоду перфокарт с программой оператору и получить от него через некоторое время распечатку результатов работы программы непосредственный выход на ЭВМ не требовался! Можно не знать многих технических деталей, однако понимание процесса трансляции, сборки и работы программы, понимание работы процессора (ЦПУ) необходимо. Давно замечено, что программы программистов, знающих ассемблер, работают быстрее и лучше, содержат меньше ошибок. В конце шестидесятых фирма IBM анонсировала выпуск ЭВМ новой архитектуры IBM/360, поставляемой с операционной системой DOS (не путать с современной DOS для ПЭВМ). Это был третий виток в технологии программирования. Это была именно новая архитектура ЭВМ, а не просто новая модель машины. Основные идеи: 1. Выделение системы ввода/вывода в отдельную независимую подсистему, прежде всего техническую, а уж потом и программную. В новой архитектуре внешние устройства подключались в ЭВМ стандартным образом через так называемые каналы ввода/вывода. Канал представлял собой маленькую ЭВМ, которая могла выполнять только операции ввода/вывода и могла быть запущена командой ЦПУ. Канал мог информировать ЦПУ о начале операции ввода/вывода и её окончании, а также о своём состоянии. Самое важное, что канал 22 Определим программирование как процесс разработки/создания программ. Программа: также совершенно естественно определяется как последовательность команд, выполняемых центральным процессорным устройством (ЦПУ). Отметим, что мы говорим не процессор, а центральное процессорное устройство. Во-первых, ранние ЭВМ имели центральное процессорное устройство, а не процессор. Первый процессор появился только в 1970 г., а первая ЭВМ работала уже в 1943 г. (Марк-1: Говард Эйкен) [Конрад Цузе 1941]. Во-вторых, под ЦПУ понимается очень широкий класс устройств, основное свойство которых варьировать тип, сорт, вид выходной продукции в зависимости от настройки или последовательности выполняемых команд. Собственно эта настройка или конкретная последовательность команд и являлась для этого ЦПУ программой. Роль человека при работе с этими устройствами сводилась к «вводу» программы и запуску устройства, ну и, безусловно, был процесс создания программы. Отсюда видно, что поскольку мы говорим о сугубо техническом устройстве и управлении процессами технического устройства, то понятие «технология» применимо к процессу создания программ для подобного устройства. Любое техническое устройство функционирует по строго определённым правилам и при заданных условиях, и, следовательно, можно говорить о технологии использования этого устройства, подготовки «входных данных» и программы с целью получения вполне определённых «выходных данных». Однако появление уникальных технических устройств ( гг.) ещё не появление технологии работы на них. Появление технологии программирования достаточно уникально. В определённом смысле сама «технология программирования» появилась существенно раньше появления ЭВМ! (электронных вычислительных машин). Ещё в 1808 г. Жаккар Жозеф Мари изобрёл способ задания характеристик ткани для ткацких станков. Выполнялось это при помощи особого приспособления для ткацкого станка. Принципиально оно состояло из особой доски с отверстиями. Для каждого вида ткани набиралась своя доска, которая устанавливалась на ткацком станке. Безусловно, жаккардова доска является программой, управляющей работой ткацкого станка. Процесс разработки структуры этой доски, процесс её набора очень сильно напоминает процессы программирования. Саму программу можно было реально потрогать. Конечно, ни у кого не возникал вопрос о правомерности существования термина «технология программирования». В те времена никто не рассматривал жаккардову доску как программу. В конце XIX века Холлерит изобрёл сортировальные машины и придумал «перфокарту». На перфокартах можно было перфорировать ограниченный круг информации, только цифры и знаки «+» и «-». Сортировальные машины могли «считывать» перфокарты, сортировать их, складывать или вычитать заданные колонки. Что и как складывать, сортировать и, вообще, какие действия с какими колонками выполнять, задавалось при помощи коммутационных досок. Сорти- 11

12 ровальная машина непосредственный предшественник ЭВМ. Она уже была электрической. Коммутационная доска представляла собой рамку с набором гнёзд для подключения штекеров. Программа задавалась при помощи штекеров, соединённых проводами. Разработка схемы коммутационной доски и являлась программированием для расчётов, выполняемых на сортировальных машинах. Для одной из первых ЭВМ, а именно «Марк-1», программа набиралась специальным подключением проводов, что было достаточно трудоёмко и отнимало значительное количество времени. Хотя и здесь программирование существенно напоминало процесс набора коммутационной доски, появилось очень существенное отличие. ЭВМ «Марк-1» была первой универсальной машиной. Жаккардовы станки и сортировальные машины использовались в достаточно узкой области. «Программировали» их, как правило, специалисты, ремонтирующие эти устройства, то есть, по сегодняшним понятиям, инженерыэлектроники. Специальности «программист» не могло появиться. Впрочем, схему коммутации для вычислений на сортировальных машинах разрабатывали специалисты по расчётам, а набирали обычно инженеры, обслуживающие эти машины. Другими словами, на этом этапе мы уже наблюдаем определённое разделение труда. Интересно, что коммутационную доску можно было просто отсоединить от сортировальной машины, сохранив схему коммутации. То есть можно было создать себе библиотеку программ. При сопоставлении жаккардовой доски, коммутационной доски и схемы подключения проводов на «Марке-1» сразу обнаруживается удивительная схожесть всех трёх объектов. Ближе всех к технологии программирования стоял набор коммутационных досок для сортировальных машин. «Марк-1» уникальна, производства ещё нет; ткацкое производство всё же очень далеко от целей вычисления чего-либо, хотя элемент управления здесь налицо. Сортировальные машины дожили до конца семидесятых годов XX века и некоторое время существовали параллельно с ЭВМ. Так называемые машинно-счётные станции были именно производством: это были предприятия, использующие для выполнения больших объёмов счёта сортировальные машины. Перфокарта одно время была единственным носителем информации, которые «понимали» ЭВМ. ЭВМ «Марк-1» поставила на повестку дня вопрос ввода и хранения программы. Программа могла работать несколько минут, а набиралась несколько часов, при этом никто не гарантировал отсутствия ошибок в программе. Отличить техническую неисправность от ошибки в программе было очень трудно. Существует легенда, что первый запуск «Марка» не дал никаких результатов из-за ошибки в программе, хотя долго искали техническую неисправность. То есть основным результатом первой электронно-вычислительной машины (ЭВМ) был остро поставленный вопрос: Какими должны быть ЭВМ, чтобы быть достаточно универсальными? Каким образом задавать программы для ЭВМ, чтобы процесс ручного расчёта был значительно дольше выполнения этих же расчётов на ЭВМ? В 1945 г. Джон фон Нейман опубликовал доклад о принципах организации ЭВМ. С тех пор все ЭВМ фактически выполняются по схеме Неймана и могут называться машинами Неймана. На сегодня найдены ещё несколько схем 12 редко занимали более 200 м 2 площади, могли функционировать в довольно узких температурных пределах и т. п. Один из авторов книг по программированию совершенно серьёзно приводит следующую ситуацию: программист, вышедший на вычислительный центр (ВЦ), первым делом спрашивает: где ящик с Fortran-ом. Именно ящик. Поскольку Fortran представлял собой колоду перфокарт, выкрашенных, допустим, в зелёный цвет, и хранившуюся в ящике. Отыскав транслятор, программист вводил его с устройства ввода перфокарт и запускал за ним уже свою колоду с программой, окрашенной, как правило, в светло-коричневые тона (цвет картона). В результате работы транслятора на устройстве вывода перфокарт выводилась колода объектного модуля, окрашенного, допустим, в белый цвет. Теперь разыскивался ящик с редактором, и вся процедура повторялась, при этом программист добавлял все необходимые объектные модули подпрограмм: результатом работы редактора был, допустим, загрузочный модуль, выведенный на колоду красного цвета. Наконец, если ранее не произошло какого-либо критического события, наступала очередь загрузчика. Немудрено, что кодировщики кодов могли достаточно долго игнорировать появление алгоритмических языков. Сейчас понятно, чего не хватало тогдашнему программисту: во-первых, устройств хранения информации, а во-вторых, такой мелочи, как операционная система (ОС). Поэтому вскоре появились магнитные ленты, барабаны и, наконец, магнитные диски, а уже потом операционные системы. Впрочем, это не совсем верно. Примерно с 1965 г. любая ЭВМ поставлялась с некоторым набором управляющих программ, которые можно рассматривать как операционную систему. Это были не универсальные операционные системы, они не обладали множеством свойств, которые есть у современных ОС, но это всё-таки были операционные системы. Они не могли быть универсальными в связи с тогдашней уникальностью каждой ЭВМ. Этап примерно от 1958 г. где-то до 1970 г. можно назвать переходным этапом. Программирование в коде ещё удерживает свои позиции, но появились новые классы программ: загрузчики, трансляторы, редакторы связей, операционные системы. Не следует забывать, что параллельно с алгоритмическими языками появляются и ассемблеры. Появились алгоритмические языки, и программирование на алгоритмических языках медленно вытесняет программирование в коде. Понятие программа приобрело новые качественные черты и свойства. Сложились и выделились технологические этапы разработки ПО: постановка, разработка, внедрение/эксплуатация. Выделились новые профессии: программист, оператор, постановщик, инженер по сопровождению. Почему же программирование в коде всё-таки ещё удерживало свои позиции? Основная причина устаревшая архитектура ЭВМ. Каждая ЭВМ была уникальна. Набор внешних устройств, фактически, прошивался в ЦПУ, и сменить его было чрезвычайно сложно. В связи с уникальностью каждой машины невозможно было написать транслятор, который бы мог запускаться на любой ЭВМ. Это же касалось и операционных систем. Надо заметить, что отладка программ в коде и отладка программ на языке существенно различались. При работе в коде программист сам распределял па- 21

13 приобрела те самые эфемерные черты, к которым нельзя применить понятие «технология». Может возникнуть недоумение по поводу того, что мы с большим интересом разбираем всё это. В конце концов, какая разница технический объект программа или математический, ведь на работу программы это не влияет. Конечно, не влияет, но на существование программы как товара очень даже влияет. Пусть программа будет чисто техническим объектом. Что делает инженер сделавший изобретение: засекречивает его, патентует и только потом, может быть, публикует. По крайней мере, не ранее чем через тридцать лет (по американским законам). То есть программы следует засекречивать и патентовать. Что делает учёный, сделавший открытие или доказавший теорему: публикует суть своего открытия или доказательство теоремы, то есть поступает прямо противоположным образом! Тогда, если программы математические объекты, то программы следует публиковать. Наконец, можно рассматривать программу как некое авторское произведение и распространить на программное обеспечение законодательство по авторскому праву. Ну, во-первых, что это за произведение, у которого может быть несколько сотен авторов. Во-вторых, себестоимость литературного, например, произведения обычно не превышает стоимости потраченных канцелярских товаров и стоимости жизнеобеспечения автора. Себестоимость же программного обеспечения часто на несколько порядков выше, доходит до нескольких миллионов долларов, и, что очень важно, необходимые средства вкладывает чаще всего отнюдь не автор, читай программист. (Сравните всё только что сказанное с ситуацией в кино.) Вот, по крайней мере, три пути решения юридических вопросов, возникающих при появлении товарно-денежных отношений в программировании. Какой путь выбрать, зависит от того, как рассматривать программу. Очевидно, что программа обладает всеми вышеперечисленными свойствами, а именно: это технический объект; это совокупность некоторых математических утверждений; это авторское произведение, и это, безусловно, товар. Опираясь на то, что программа является техническим объектом, можно смело утверждать, что к программированию можно применить термин «технология». Недооценка любого из вышеперечисленных свойств программы приводит к грустным последствиям. В условиях России чаще всего игнорируются товарные свойства программы. Вы можете написать очень хорошую программу, но если на рынок ранее ваши конкуренты выбросят свою, пусть плохую программу, но покупаемую пользователем, то вам потом будет очень трудно вытеснить эту программу с рынка. Скорее всего, вашу программу вообще не будут покупать. Всё потому, что вместе с программой пользователь покупает и технологию работы с этим классом программ. Программу, как правило, недолго сменить, но сменить уже сложившую технологию работ, то есть изменить привычки пользователя, значительно сложнее. Выяснив, таким образом, что такое технология программирования, вернёмся в шестидесятые года и вспомним или выясним, как происходил выход программиста на машину. Отметим, что ЭВМ тогда были очень громоздки, не- 20 построения вычислительных машин, отличных от чисто электронных, но, в общем, принципы фон Неймана настолько общи, что в каком-то смысле все подобные устройства должны иметь устройства, указанные фон Нейманом. Вкратце принципы организации ЭВМ должны быть следующими. Если мы хотим, чтобы компьютер был универсальным и эффективным устройством, то компьютер должен иметь: - арифметико-логическое устройство или центральное процессорное устройство, выполняющее арифметические и логические действия; - устройство управления, организующее процесс управления программой; - запоминающее устройство или память для хранения программ и данных; - внешние устройства для ввода-вывода информации. Главное в этих принципах то, что программа и данные не различаются и могут храниться на одних и тех же устройствах. Важно, что и программа, и данные могут обрабатываться одним устройством. Мало того, что этот принцип позволил существенно упростить устройство ЭВМ, он же, фактически, «разрешил» существование таких программ, как трансляторы, ведь, что такое программа, как не входные данные для транслятора. Именно с машины Неймана понятия «программа» и «программирование» приобретают то наполнение и смысл, какой мы привыкли понимать. Но остался ли смысл в термине «технология программирования»? Итак, давайте рассмотрим процесс программирования и понятие программа для машины фон Неймана. Вспомним, как работает процессорное устройство. С заданного адреса памяти ЦПУ выбирает заданное число бит. Тогда не было понятия байт, память ЭВМ адресовалась в рабочих ячейках. Рабочей ячейкой называлась минимально адресуемая часть памяти ЭВМ. Несмотря на эквивалентность определения байта и рабочей ячейки, это существенно разные понятия. Длина рабочей ячейки была уникальна для каждой ЭВМ и варьировалась от 16 бит и более. Не могу указать реальный максимальный размер рабочей ячейки, но ЭВМ серии БЭСМ имели рабочую ячейку длинной в 49 бит. ЦПУ оперировало рабочими ячейками. В зависимости от интерпретации биты рабочей ячейки могли рассматриваться как исполняемая команда или как операнд вычислений. Несколько бит рабочей ячейки, интерпретируемой как команда, рассматривались как код выполняемой команды, остальная часть рабочей ячейки рассматривалась как последовательность адресов операндов. В зависимости от схемы адресации, в команде могло быть два или три адреса. Таким образом, ЭВМ были двухадресными или трёхадресными, существовали и одноадресные машины. В среднем интерпретация сводилась к выбору кода команды и выполнения некоторой операции с содержимым, выбираемым с адреса А1, и содержимым, выбираемым с адреса А2, и направить результат по одному из этих адресов или по адресу А3. Были ещё команды сравнения и перехода, а также специальные команды работы с внешними устройствами ЭВМ. На том этапе конфигурация ЭВМ прошивалась в ЦПУ вместе с командами их управления, почему изменить конфигурацию ЭВМ было очень даже не просто. 13

14 Программа и данные хранились в оперативной памяти или ОЗУ оперативное запоминающее устройство. ЭВМ при включении всегда пыталась запустить выбор команды с заданного адреса. Этот адрес для каждой машины был уникальным. Впрочем, с пульта ЭВМ можно было задать начальный исполняемый адрес программы. Ответственность за расположение программы и данных в памяти целиком возлагалась на программиста. Сама программа представляла собой последовательность цифр, которые могли интерпретироваться как команды. Причём программа писалась в реальных адресах. Технология программирования представляла собой методику написания, а также исправления в случае ошибки подобной последовательности цифр, извините, команд. Такое программирование называется программированием в коде. Программирование в коде широко использовалось до восьмидесятых годов XX века. Оно существует и сегодня и чаще всего используется при программировании технических контроллеров. Где-то с шестидесятых годов появляется программирование на алгоритмических языках, но долгое время использовались обе технологии одновременно. Причины этого см. ниже. Следует обратить ваше внимание, что новые технологии всегда некоторое время существуют параллельно со старыми. Подробное рассмотрение процесса смены технологий см. в главе Технологические скачки. Основные характеристики этапа программирование в коде с точки зрения технологии: Большое разнообразие ЭВМ. Каждая ЭВМ имеет свою систему команд, свой набор внешних технических устройств. Поскольку команды работы со внешними устройствами были вшиты в ЦПУ, а системы команд внешних технических устройств не стандартизованы, то конфигурация ЭВМ была неизменяема. Программы были непереносимы не только на ЭВМ разных типов, но зачастую даже между однотипными ЭВМ, в связи с постоянной модернизацией моделей. Поэтому производства программ, фактически, нет. Каждая программа представляет собой уникальный объект. Однако существует технология программирования в виде набора приёмов и методов, общих для всех ЭВМ. На этом этапе технологию программирования можно сравнить с технологией ювелирного производства сплав искусства и ремесла. Грамотный программист писал эффективные и короткие программы. Например: Брукс вспоминает случай, когда некий программист, он не приводит его имени, сумел реализовать в коде транслятор с Fortrana, уместив его в 4K памяти (!) сравните эти величины с параметрами современных трансляторов. Технические возможности машины использовались в полном объёме! Программы можно было ввести непосредственно с пульта ЭВМ и с него влиять на работу программы. По ходу работы программы можно было даже изменить саму программу. Но такие программы редко имели интерфейс, достаточный для нормальной диагностики останова. Если такая программа вставала или зависала, то определить, почему ЭВМ стоит, было трудно. Отметим, что прежде всего надо было разделить программные и технические ошибки между собой. Справедли- 14 зочный модуль. Теперь чаще всего говорят исполняемый модуль (EXE-модуль). Загрузочный модуль и был тем самым исполняемым кодом, он мог выполняться на машине. Сам же загрузочный модуль каким-то образом должен был попасть в память машины, и для того, чтобы он работал, ему необходимо было передать управление. Загрузку загрузочного модуля в память и передачу ему управления выполнял уже знакомый нам загрузчик. Ещё раз напомним, что обычно он строился таким образом, что при нормальном завершении исполняемой программы управление вновь возвращалось к загрузчику и он был готов загрузить следующую программу. Следует обратить внимание на появившиеся «накладные» расходы. При программировании в коде была только программа, которая непосредственно запускалась на машине программистом или инженером по сопровождению. Программирование на алгоритмических языках потребовало наличия трансляторов, редакторов и загрузчиков. На функционирование трёх указанных классов программ требовалось машинное время и другие ресурсы. Кроме того, программы, написанные человеком, были короче и работали быстрее тех, что генерировал транслятор. Почему же «хорошие» программы, закодированные программистом, были вытеснены «плохими», автоматически сгенерированными программами? Всё дело в производительности труда и конечном результате. Очень скоро обнаружилось, что производительность труда программиста при работе на языке в десять раз выше, чем при программировании в коде, что с лихвой окупало все появившиеся накладные расходы. Более того, программа, написанная на языке, гораздо лучше отлаживалась, её было намного проще сопровождать, другими словами, такая программа содержала меньше ошибок. Тогда и появился лозунг: сначала просто работающий модуль, а уже потом оптимальный, и широкому программированию в коде пришёл конец. Но наличие трансляторов и алгоритмических языков не только качественно изменило технологию программирования. Такой объект, как программа, приобрёл существенно новые черты. Прежде всего, программа перестала быть чисто техническим объектом. Программа в коде, написанная на листе бумаги, отдельно от машины представляла собой колонки никому не нужных цифр. Прочесть её сходу затруднялся даже автор. Если вы не знали, в командах какой машины написана программа, то могли смело выбрасывать текст. Программа на алгоритмическом языке могла быть прочитана и относительно легко разобрана практически любым грамотным человеком, а не только программистом. Программа могла быть запущена на другой машине, лишь бы имелся соответствующий транслятор. Программа стала товаром, которым можно было торговать! С этого момента все товарно-денежные отношения вошли в мир программирования, и так или иначе это необходимо учитывать. С другой стороны, стало возможным утверждать, что программа является некоторым математическим утверждением, а следовательно, все законы математики можно привлечь к анализу программы. Другими словами, программа 19

15 Почему для генерации кода программ потребовался алгоритмический язык? Основная причина в неоднозначности фраз и слов естественного языка. Если вы читаете коса, то без контекста вы никогда не сможете сказать, что это: коса девичья краса; коса сельскохозяйственный инструмент; коса речная отмель. Поэтому и появилась идея алгоритмического языка, фразы которого бы однозначно могли быть переведены в код ЭВМ программой, которую так и назвали транслятор, или переводчик. Появление трансляторов принесло качественные изменения в технологию программирования. Во-первых, вместе с трансляторами появились редакторы связей. Во-вторых, программы перестали быть чисто техническим объектом. В-третьих, с появлением трансляторов стала явственно ощущаться необходимость в наличии неких комплексов программ, управляющих работой ЭВМ. Итак, почему появились эти новые классы программ? Транслятор это программа, переводящая один класс утверждений в другой. Это, в общем, правильное определение 40 лет назад звучало по-другому, и в него вкладывался другой смысл: транслятор это программа, переводящая предложения алгоритмического языка в код машины. Даже в этом определении не говорится об исполняемом коде. Транслятор не мог сгенерировать сразу исполняемый код. Проблема всё та же распределение памяти ЭВМ. Для генерации исполняемого кода требовалось знать начальный адрес загрузки программы. Нижние адреса большинства машин использовались в некоторых технических целях, что также необходимо было учитывать при генерации кода. Но, очень важно, FORTRAN имел оператор CALL ИМЯ, вызывающий подпрограммы, а также заголовок для подпрограммы: SUBROUTINE. Предполагалось, что подпрограммы могут быть транслированы отдельно от программы, их вызывающей. Отсюда видно, что транслятор не мог знать заранее, где находятся уже оттранслированные подпрограммы, и, главное, транслятору не были известны адреса загрузки подпрограмм; да и подпрограммы один раз должны быть загружены с одного адреса, а другой раз с другого. Выход из этой ситуации был очень простой: транслятор все программы транслировал в некие объекты, адрес загрузки которых был ноль. Эти объекты содержали исполняемый код и даже могли бы выполняться при загрузке с нулевого адреса, до первого вызова подпрограммы. Чтобы объект, получаемый в результате работы транслятора, можно было выполнить, следовало изменить все адреса его на величину адреса загрузки, а также согласовать адреса вызова подпрограмм. Логично всю эту работу было поручить ЭВМ, то есть потребовался новый класс программ редактор связей. Таким образом, исходный текст программы стали называть исходным модулем. При программировании в коде исходный текст и исполняемый код идентичны. Объект, получаемый транслятором в результате трансляции, называется «объектный модуль». Объектные модули не могли выполняться непосредственно на машине. Программа, разрешающая все внешние ссылки объектных модулей, называется редактор связей. Кроме того, тогда редактор связей настраивал программу на конкретный адрес загрузки, получая на выходе загру- 18 вости ради, скажем, что это беда не метода программирования в коде, а тогдашней архитектуры ЭВМ. Программы в коде тяжело корректировать. Ведь в коде записаны конкретные адреса расположения данных или команд, и любая вставка чего-либо в середину текста сдвигала весь конец текста, а следовательно, необходимо было поправить все адреса. Технология исправления середины программы без изменения её конца существовала и называлась вставка заплатки. Первая подлежащая исправлению команда заменялась на команду безусловного перехода на адрес, находящийся за данными. Там вставлялся правильный код, который завершался командой перехода обратно на правильно выполняемую команду. Но когда вы на десяток уже вставленных заплаток вставляли ещё некоторый другой десяток новых заплаток, а на них ещё и следующие заплатки, вам становилось ясно, что лучше переписать программу снова от начала до конца. Программы в коде плохо интегрируемы. То есть написать подпрограмму, которую могут использовать множество других программ, очень даже непросто, хотя и возможно. На основании этого можно сразу утверждать, что реализация такой идеи, как библиотека стандартных подпрограмм, превращалась в серьёзную проблему, так как требовала в своей основе некоего соглашения о распределении памяти между программистами вычислительного центра, а рано или поздно находилась задача, которая не вписывалась в рамки этого соглашения. Кроме того, дабы как-то всё-таки освободить программистов от написания таких функций, как вычисление, например, синуса, в память ЭВМ прошивались так называемые стандартные подпрограммы. Программирование в коде кропотливый и трудоёмкий процесс. Практика показала, что скорость программирования составляла примерно 10 команд в день, но это у опытного программиста. Ниже мы ещё остановимся на производительности труда программиста, а сейчас нас интересуют другие вопросы. Переход с одной системы команд на другую или с одной машины на другую у опытного программиста занимал примерно полгода. На обучение программированию в коде новичка уходило до года. Однако именно на этом этапе разработка программ начала выходить на промышленный уровень. Количество вычислительных центров стремительно росло. Возникают вопросы обмена программным фондом между одинаковыми машинами. Поскольку на подготовку программиста уходило до года и более, появляется стремление к единообразию. Появилась возможность говорить о производстве программ, производительности труда программиста, внедрении в производство готовых программ. Поскольку производство программ начало выходить на промышленный уровень, появился процесс отладки. Принципиально он был и раньше, но теперь появилась возможность выделить технологический процесс. Именно на этом этапе выделяются основные технологические процессы: постановка, программирование, отладка, эксплуатация/сопровождение. Именно на этом этапе появилась профессия программист. То есть произошло чёткое разделение труда. В связи с выделением технологических стадий появились специальности постановщик, про- 15

16 граммист, оператор, инженер по сопровождению. Из списка обязанностей инженера-электроника исчезла ввод программ в память ЭВМ. Принадлежность всех вышеуказанных процессов к программированию ни у кого не вызывала сомнения. То, что эти процессы всё-таки технологические, также ни у кого сомнений не было, поскольку программа была сугубо техническим объектом. Невозможно было рассматривать программу в отрыве от системы команд машины. Основные недостатки «программирования в коде» чрезвычайно низкая производительность труда программиста, значительная трудоёмкость написания любой программы и «машинные» требования к кодированию. Поэтому, как только стало ясно, что такое «программирование в коде», появилось множество идей по «упрощению» технологии программирования. Большинство из них было направлено на повышение производительности труда программиста, «упрощение» технологии программирования, повышение эффективности отладки. Основная идея была следующей: раз человек ошибается, а кодирование программы однообразный и достаточно рутинный процесс, нельзя ли заставить кодировать программу саму ЭВМ? Оказывается можно: в 1958 г. Джон Бэкус реализовал первый транслятор с алгоритмического языка Fortran. Кстати, попытка избавиться от рутинных процессов, а заодно с ними и от источника ошибок программиста, прослеживается по всей истории программирования. Каждый раз, когда создаётся новый «сверхмощный» язык, максимально приближённый к естественному, заявляется, что теперь любой сможет без ошибок писать на этом языке, а следовательно, пропадает необходимость в программисте. В действительности необходимость в программистах только растёт, количество ошибок не уменьшается. Ошибки перемещаются на другой уровень и становятся сложнее; пропадают некоторые классы ошибок, но появляются другие. Само программирование и его технология медленно усложняются при внешнем упрощении используемых в программировании методов. Но в широкой практике сначала были автокоды. Автокод программа, которая могла ввести математическую формулу, перевести её в код ЭВМ и запустить процесс вычислений по введённой формуле для вводимого множества значений. Тогда полагали, что основное назначение ЭВМ выполнять сложные математические расчёты для значительного объёма входных данных. Принципиально было наличие большого объёма входных данных. Даже сложение и вычитание для объёмов в сотни, тысячи, миллионы чисел человек делал с ошибками, а вот ЭВМ это могла сделать без ошибки! Оказалось, что человеческая форма записи математических выражений неудобна для ЭВМ. Для машины больше подходила так называемая польская запись, которая, в свою очередь, плохо приемлема для человека. После того, как Дейкстра опубликовал удобный алгоритм перевода математических выражений в польскую запись (стековый транслятор арифметических выражений), разработка автокода превратилось в рутинную процедуру. Тем не менее, автокод был, скорее, первым приближением к ассемблеру, а не к алгоритмическому языку. Основные недостатки автокода автоматизация очень узкого класса операций и невозможность организации сложного процесса вычислений. 16 Но широкое использование автокодов привело к появлению такого класса программ как загрузчики. Загрузчик программа, вводящая (загружающая) в память ЭВМ другую программу и передающая управление введённой программе. Правильно написанная программа не портила кода загрузчика (не использовала адреса, занятые загрузчиком) и по завершению работы возвращала управление загрузчику. Таким образом, загрузчик мог вводить следующую программу. Обращаем ваше внимание на то, что управление всем процессом, неиспользование чужих адресов, возврат управления, возлагалось на программиста. При всех своих недостатках автокоды были самыми настоящими трансляторами. Конечно, эти трансляторы транслировали очень узкий класс утверждений, но автокоды обладали всеми атрибутами и свойствами трансляторов. Кстати, на основе стека можно реализовать транслятор с любого алгоритмического языка (см., например, [13]). Вообще любую программу можно рассматривать как транслятор. Ведь, что такое программа как не объект, переводящий входные данные в выходные или один класс утверждений в другой, а это, в свою очередь, и есть задача транслятора. Собственно FORTRAN и переводился как формула транслэйшин. Тем не менее, FORTRAN реализовался именно как алгоритмический язык, а не как автокод. Здесь следует заметить, что смена терминологии не такая уж безобидная вещь, как многим кажется. Конечно, бывают ситуации, когда как бы ни назвали, лишь бы в печь не ставили. В большинстве случаев, однако, предварительно продекларированные цели определяют инструменты и пути достижения цели, что, в свою очередь, влияет на способы вашего мышления и действий. Вроде бы это чисто философские проблемы, но вы стремитесь достичь цели наименьшими усилиями в наискорейший срок, а это уже вопросы технологии. Собственно, это и есть основная задача любой технологии. Алгоритмический язык это не просто автокод с добавлением операторов описания данных, в автокодах, в общем-то, не было понятия «оператор». Выше уже говорилось, что автокод скорее, шаг к разработке ассемблера. При разработке автокодов стало понятно, как выполнять генерацию кода ЭВМ, но не ставилось задачи независимости от системы команд машины. Идея же алгоритмического языка как раз и состоит в том, чтобы написать программу таким образом, что запустить её можно будет на любой ЭВМ. Каким образом программировать так, чтобы не зависеть от системы команд машины? Тогда многие сомневались, что это вообще возможно. Тогда никто не знал, как писать трансляторы, не было теории трансляции. Было ещё очень тяжёлое соображение, отвергающее идею алгоритмического языка: как бы вы не писали, но квалифицированный программист в коде напишет программу, которая будет значительно оптимальнее программы, сгенерированной автоматически. То есть человеческая программа будет и короче сгенерированной, и работать будет быстрее! То есть управляющими (менеджерами) разработка трансляторов и алгоритмических языков рассматривалась как обыкновенное баловство или решением задачи типа сколько ангелов можно разместить на конце иглы?. 17

17 на складе: приход/расход материалов оформляется бумажными накладными, которые пишутся в трёх экземплярах (на склад, в бухгалтерию, поставщику/пользователю). Ведёт всё это хозяйство кладовщик, образование которого может быть средним неполным, так как требуется только умение писать и читать, а также умение выполнять четыре действия арифметики. При этом кладовщик имеет не самый низкий статус на производстве, так как только он может быстро сказать, что есть на складе, а чего нет. Себестоимость всего этого процесса минимальная зарплата кладовщика, стоимость бланков накладных и канцелярских товаров. Теперь на склад поставили компьютер с принтером и потребовали, чтобы приход/расход оформлялся электронными накладными, которые по сети тут же оприходовывались бы в бухгалтерии. Вот теперь на себестоимость процесса упадёт амортизация компьютера, принтера, стоимость картриджей, стоимость обслуживания всей этой техники, притом, что бумажные накладные никто не отменял. Кроме того, теперь кладовщик должен уметь обращаться с компьютером, то есть иметь не менее среднего образования, что означает, косвенно, увеличение его зарплаты. А вот статус кладовщика упадёт до минимального, так как теперь любой, имеющий доступ к базе данных материалы, может определить наличие материалов на складе. Этот очень простой пример показывает, что широкое внедрение программного обеспечения в производство имеет множество побочных, а для заказчика часто неожиданных эффектов. Перечислим основные из них. Внедрение программного обеспечения в производство: 1. Меняет схему информационных потоков и документооборота. Например, при автоматизированном расчёте зарплаты выводятся личные расчётные листки, а при ручном расчёте этого не делается. Или, при внедрении на предприятии электронной проходной появляется такой ежедневный документ, как «список лиц, нарушивших график прихода/ухода», который поставляется в отдел кадров. Ясно, что такого документа нет при наличии обычной проходной. 2. Требует изменения штатного расписания предприятия: появляются новые должности и специальности; некоторые старые должности становятся ненужными. Очень часто появляются и новые подразделения, в свою очередь, может потребоваться ликвидация старых подразделений. Мы все прекрасно знакомы с тем, что внедрение вычислительной техники привело к появлению на предприятиях должностей программист, инженер-электроник и т. д., отделов «вычислительной техники». С другой стороны, с внедрением электронного черчения исчезли такие должности, как «чертёжник/ца». Внедрение обычных текстовых процессоров значительно уменьшило штат машинисток. 3. У многих должностей изменяется состав обязанностей, уровень ответственности и требования к квалификации. Ранее инженер писал документ вручную и нёс его машинистке, теперь он может полностью набрать документ (во время составления документа) и сразу вывести его на печать; но теперь к квалификационным требованиям инженера добавилось «знание компьютера». Что очень важно, меняется значимость должностей, а также людей, их занимающих. Последнее многими воспринимается весьма болезненно. 64 на все 100%, это для больших программ невозможно в принципе, а в том, что вы не сообщили заказчику о том, что существуют такие-то 30% случаев, когда ваша программа может не работать. Иногда программист боится, что ему не будет выплачена определённая сумма, которую ему обязаны будут выплатить по завершению работы, и он сознательно выпускает продукт с ограниченным сроком работы, это уже типично злой умысел. Или: разработчик может написать новое ПО так, чтобы вынудить пользователя закупить новую версию ПО, что постоянно делает фирма Microsoft, например. С другой стороны, современную систему лицензирования ПО иначе как злым умыслом назвать очень трудно. Ведь если вы внимательно прочитаете лицензию, то обнаружите, что пользователь берёт на себя множество обязательств, это за свои-то деньги, а поставщик не несёт никакой ответственности, но об этом более подробно см. ниже. Из разбора причин смерти ПО косвенно выясняется среднее время жизни программы: 5-10 лет. Программа, которая эксплуатируется дольше, уже долгожитель. Такие программы, как ОС UNIX или БД Oracle, живут уже более тридцати лет, но если вы сравните между собой Oracle 1.0 и Oracle 9.2, то обнаружите, что это существенно разные программы, хотя базовые принципы остались. Таким образом, программа может существовать достаточно долго, но она при этом обязательно изменяется развивается. Не изменяются программы, решающие либо ограниченный круг вопросов, либо некие базовые вечные задачи, обращение матрицы, например. При изменении программы важно сохранение преемственности. Пусть программа версии 1 решает некую задачу на заданном потоке данных. Та же программа версии 2 обязательно должна обрабатывать тот же поток данных, без всяких изменений и с теми же результатами. Если вы существенно меняете формат входных данных, даже не меняя всего остального, то это другая программа, решающая те же задачи: она должна называться по-другому. Можно сделать так, чтобы программа вводила поток данных как в новом формате, так и в старом, а уж пользователь сам разберётся, какой формат данных ему удобнее. Заметим, что рассмотрение жизненного цикла программы мы начали со смерти программы, события, которое не имеет отражения в технологических стадиях/фазах. Смерть программы происходит тихо, чаще всего без оформления каких-либо документов. Иногда в приказе на запуск новой программы бывает пункт о прекращении с такого-то числа эксплуатации такой-то программы. Вообще, процесс смерти много проще и короче во времени, чем процесс рождения. В случае смерти программы часто отсутствует процесс утилизации нет похорон, которые в нашем случае звучат так: стереть, удалить, не хранить. Рождению же программы должен обязательно предшествовать процесс проектирования. Сравните с производством любого технического устройства: сначала проектирование-конструирование, затем процесс получения рабочей документации стадия рабочий проект и наконец, выпуск продукции. При производстве ПО всё точно также: постановка, разработка, внедрение/ эксплуатация/сопровождение, но само содержание выделенных стадий несколько другое, что очень важно: нет чётких границ между стадиями. Особенность 33

18 производства ПО в том, что часто бывает возврат на предыдущую стадию. Технологические стадии взаимосвязаны и проникают друг в друга и чаще всего выполняются одновременно! Безусловно, возврат от эксплуатации к постановке достаточно редок, но постановка разработка снова постановка сплошь и рядом. С другой стороны, рассматривая сопровождение, мы обнаружим, что это разработка во время эксплуатации. При рассмотрении любой технологической стадии всегда требуется ответить на следующие вопросы: содержание технологической стадии, состав работ, состав и квалификация исполнителей, результаты, сроки. Чаще всего все эти составляющие выбираются из американской литературы и без всяких изменений переносятся на российскую почву, см., например, ГОСТ Р ИСО/МЭК [5], который является переводом ISO/IEC Ещё раз напоминаем, что технология программирования инженерная дисциплина. Её содержание сильно зависит от реалий общества, в котором она применяется. Следует ли говорить, что менталитет культур очень разный, разная организация производства, а значит, и технология производства ПО в России будет отличаться от технологии производства ПО в США. Невозможно не учитывать эти различия. На некоторые отличия мы обратили уже внимание во введении. Далее мы также постараемся постоянно показывать разницу в подходах в России и США. Выпуск конкретного ПО в целом принято называть проектом. Отметим, что в России проектная стадия традиционно заканчивалась рабочим проектом и рабочей документацией, далее шло производство. Распространение понятия проект на разработку ПО и его эксплуатацию подчёркивает разницу между выпуском технической продукции и выпуском ПО. Само содержание технологических стадий зависит от вида проекта и его величины. Под величиной проекта понимается его трудоёмкость. Различают малые, средние и большие проекты. Величина проекта существенно влияет на проектирование и реализацию. Большой проект может потребовать совершенно иного технологического и организационного подхода. Фредерик Брукс в своём бестселлере «Мифический человеко-месяц» [4] подробно разбирает основные трудности, возникающие при проектировании и реализации большого проекта. Отнесём к малым проекты трудоёмкостью до сотни человеко-месяцев. Это могут быть простые трансляторы, генераторы отчётов и т. п. Ещё раз обращаем ваше внимание на то, что ранее трудоёмкость реализации транслятора оценивалась на порядок больше. Средние проекты до 1000 человеко-месяцев и большие свыше Основные проблемы малых разработок находятся в области нехватки ресурсов, денежных средств, кадров, но в общем малый проект, чаще всего, реализуется одним человеком, и если при достаточном наличии средств возникают проблемы, то обычно это проблемы личности, а не организации или технологии производства. В больших и средних проектах приходится решать проблемы наилучшего укомплектования штатов, организации и технологии разработки. Основная проблема взаимодействие между собой специалистов и программных модулей или подсистем. С ростом числа модулей сложность системы растёт нели- 34 Видим, что степень отладки программы зависит не только от квалификации программиста, но и от задачи, от выделенных ресурсов, от ожиданий заказчика, от целей разработки. Программисту очень важно сначала прийти к цели разработки, а уж потом всё остальное. Отсюда следует, что сначала цель работы программы, а уж потом её интерфейс. То есть, угождая заказчику и реализуя именно тот интерфейс, о котором просит заказчик, не забудьте про цели написания программы. Вообще в программировании плохо работает знаменитый торговый принцип «клиент всегда прав». Для продажи продукта, в том числе и программ, этот принцип подходит, но для достижения результатов очень часто не просто обременителен, но и вреден. Все вдумчивые пользователи продуктов фирмы Microsoft могут подтвердить это. Во-первых, пользователь часто ищет «царские пути» на вершину. Во-вторых, пользователь часто не знает чего хочет (см. выше). В-третьих, пользователь часто не представляет, к чему приводит внедрение программного продукта. Этап внедрения важен тем, что именно при его реализации у пользователя открываются глаза. Пользователь/заказчик понимает, чего он хочет. Пользователь может оценить объём работ не только по внедрению программы, но и затраты по её эксплуатации. Важно, чтобы программист понимал последствия внедрения его программы. Разработчик часто полагает, что он осчастливил заказчика, реализовав его задачу. В большинстве случаев это не так. Бывают случаи, когда заказчик, даже оплатив разработку, отказывается от её внедрения в производство. Самое интересное, что оснований для этого более чем достаточно. Внедрение программного обеспечения в производство тоже работа, которая требует денег, времени и других ресурсов. Нередко заказчик не готов к этому. Предполагалось, что программа будет установлена на компьютер пользователя и тот будет работать на ней. Но тут выясняется, что пользователя необходимо обучить работе с программой, что база данных программы пуста, что подготовка данных для программы требует времени и т. д. и т. п. На современном этапе большинство программ работает с базами данных. Для нормальной работы с такой программой требуется определённое начальное заполнение базы данных. Трудоёмкость заполнения базы данных может превышать трудоёмкость разработки. Понятно, что в составе работ по разработке программы нет ввода данных в базу. Чаще всего ввод данных в базу требует весьма квалифицированного пользователя, который может отсеять ошибочные данные, ликвидировать в них противоречия, в первую очередь, ввести данные, которые будут необходимы при текущей или будущей работе. Только пользователь может ввести правильно данные в базу. Именно поэтому ввода данных в базу нет в составе работ по разработке. Однако в большинстве случаев пользователь в своих текущих планах не предусматривает работ по вводу данных в базу. Программа же с пустой базой данных становится бесполезной, дорогой, никому ненужной игрушкой. Компьютеризация производства нередко удорожает производственный процесс, что видно на простом примере автоматизации прихода/расхода материалов на склад. Пусть у нас небольшое предприятие. До наличия компьютера 63

19 Конечно, каждая истина конкретна. Если вы реализуете в результате всего только 10% заказанных возможностей, то вряд ли заказчик вам оплатит полную стоимость договора на разработку, да и подумает, иметь ли с вами дело в дальнейшем. Но если вы реализовали более 80% возможностей, то заказчик может пойти либо на продолжение договора для реализации оставшихся возможностей, либо согласится отказаться от нереализованных. Не следут забывать, что выявление ошибок продолжается до конца жизненного цикла программы. Наибольшее число ошибок обнаруживается после или во время приёмо-сдаточных испытаний. Однако следует принимать во внимание, что «самая сложная задача программирования получить полную и непротиворечивую спецификацию, и сущность создания программы на практике во многом состоит в «отладке спецификации». (Ф. Брукс) [4]. Что для нас важно? Важно то, что в больших системах мы не можем снизить число ошибок ниже определённого уровня. Важно то, что цель написания программы выдача ожидаемых пользователем результатов на заданных данных при заданном количестве ресурсов. Всё это не означает, что ошибки не стоит ликвидировать, в любом случае надо стремиться максимально уменьшить число ошибок в реализуемой среде. Возникает вопрос: когда следует остановиться? Один из простых ответов на этот вопрос гласит: остановиться следует тогда, когда вы, устраняя одну ошибку, своими исправлениями вносите две или более новых ошибок. Однако такое явление может наблюдаться и при определённой усталости программиста. То есть, когда вы начинаете не устранять ошибки, а умножать их число, вам сначала надо просто отдохнуть, а уж потом подумать, что делать далее. Если же вы в обе стороны от нуля по оси X отложите усилия по устранению ошибок, а по оcи Y количество ликвидированных ошибок, то получите стандартный колокол нормального распределения. Это означает, что на устранение 60% ошибок понадобится примерно 30% усилий, измеряемых в неких единицах. На устранение следующих 10% ошибок примерно те же 30% усилий, на устранение следующих 5% примерно 40% усилий и т. д. На устранение каждой последующей ошибки понадобится всё большее количество усилий, читай времени и средств. Таким образом, первый критерий завершения программы будет гласить: отладку следует прекратить тогда, когда стоимость устранения ошибки будет значительно выше эффекта её ликвидации. Другой критерий завершения отладки программы зависит от задачи. Надо ли говорить, что программы, выполняющие те же самые бухгалтерские расчёты, нередко сдаются такими, что работают только при эксплуатации самими разработчиками. Они доотлаживаются уже в процессе ОПЭ (опытнопромышленная эксплуатация), а бывает и позже. А вот программа управления технологическим процессом должна быть отлажена гораздо серьёзнее, полусырой её никто не допустит даже до ОПЭ. С другой стороны, фирма Microsoft доказала, что операционные системы могут даже продаваться полусырыми, и весь мир бесплатно тестировал её Windows 95 (!). Однако не следует забывать, что Windows всё-таки офисная операционная система. 62 нейно. С увеличением числа разработчиков резко увеличивается объём межличностного и межгруппового общения, а следовательно, происходит распределение ответственности. Поскольку время межличностного и межгруппового общения не учитывается в предварительно определённой продолжительности реализации разработки, то проект обязательно выбивается из графика, а добавление новых сотрудников только усугубляет обстановку. Кроме того, при большом числе сотрудников и отсутствии специальных методов управления трудно добиться концептуального единства проекта. Для достижения последнего требуется, чтобы проект исходил от одного человека или от малой группы специалистов. (Проведите параллель: фильм снимает режиссёр!) Ф. Брукс подробно рассматривает в своей книге [4] трудности, с которыми сталкивается реализация больших проектов. Он один из немногих даёт конкретные рекомендации и даже более того, во втором издании ввёл 19 главу «Мифический человеко-месяц двадцать лет спустя», где он обсуждает правильность своих рекомендаций в сегодняшних реалиях. Сейчас нам достаточно знать о различии в реализации больших и малых проектов, желающих получить конкретные рекомендации отсылаем к замечательной книге Брукса. Следует учитывать, что при увеличении времени реализации проекта руководству приходится искать технологии производства, не зависящие от личности программиста. Дело не в том, что каждый программист уникален, дело в том, что за значительный срок выпуска ПО программист может сменить место работы, да к тому же он ещё и смертен. По виду проектов выделим три группы программных проектов (Майерс [15]): проект, управляемый пользователем, контролируемый пользователем и независимый от пользователя. Тут необходимо заметить, что при любой разработке, а не только ПО, существуют требования к будущему выпускаемому продукту. Эти требования определяет пользователь (!). Точно так же требования к ПО определяются пользователем. Не следует забывать, что ПО разрабатывается для удовлетворения нужд пользователя. В случае проекта, управляемого пользователем, требования к ПО разрабатываются непосредственно организацией-пользователем. Разработчик ПО является подрядчиком или субподрядчиком этой организации. Чаще всего это правительственные заказы или заказы крупных организаций. В проекте, контролируемом пользователем, требования к ПО формулируются совместно разработчиком и пользователем либо только разработчиком, но тогда требования утверждаются пользователем. В проекте, независимом от пользователя, вся ответственность на определение требований ложится на разработчика ПО. Чаще всего это общедоступные рыночные продукты. Однако и здесь пользователь косвенно участвует в определении требований: продукт, игнорирующий требования пользователя, будет плохо покупаться им. Важно участие в определении требований как пользователя, так и разработчика. Не участие в определении требований разработчика ПО повышает его шансы неправильно понять или неправильно интерпретировать требования. 35

20 Обычно пользователь или его команда несёт ответственность за полноту и точность требований, а разработчик за проверку осуществимости и понятности. Ещё раз отмечаем, что конкретный состав работ и наличие технологических стадий зависят от трудоёмкости проекта и его вида, но в любом проекте можно выделить постановку, разработку, эксплуатацию. Здесь и далее под эксплуатацией мы будем понимать совокупность процессов внедрения, эксплуатации и сопровождения. Обращаем также ваше внимание на то, что обычно эксплуатация технического продукта не входит в технологию его производства, а в производстве ПО это весьма существенная технологическая стадия. В процессе изучения предмета мы будем постоянно встречаться с отличиями технологии программирования от других технологий. На очень важное отличие обращает внимание Алан Купер [12]. Дело в том, что сначала в США при управлении разработки программного обеспечения (ПО) попытались применить методы организации производства, наработанные в таких областях как производство автомобилей, предметов бытовой техники и т. п. Всё это естественно. Первые опыты организации производства ПО были выполнены в фирме IBM, которая выпускала ЭВМ. Разработка ПО рассматривалась как вспомогательная область в производстве ЭВМ. Фирма предполагала зарабатывать на продаже ЭВМ, а не на производстве ПО. ПО поставлялось вместе с ЭВМ и рассматривалось как её неотъемлемая часть. В технических производствах обычный состав затрат на производство распадался на две основные составляющие: затраты на материальные средства, или материальные активы, и переменные затраты оплата материалов и сотрудников, занятых на производстве. Материальные активы составляли от 70% и более; снизить эти затраты было очень затруднительно, к тому же снижение этих затрат почти всегда приводило к увеличению доли ручного труда и снижению производительности труда, что тут же увеличивало переменные затраты. Переменные затраты, наоборот, легко управлялись: снижение почасовых ставок, интенсификация труда сотрудников и т. д. При производстве ПО материальные активы составляют до 40% затрат, к тому же их стоимость постоянно снижается (!). Переменные же затраты только увеличиваются, составляют основную долю, к тому же отсутствует основной путь их снижения снижение оплаты программиста. Каким образом увеличить производительность труда программиста, тоже не ясно. Кроме того, производство ПО сильно зависит от личности программиста. На конвейер можно поставить практически необученного человека, что позволяло в любой момент сменить состав работников на конвейере в случае их нерадивости, например. Сменить же программиста в середине разработки, как правило, совершенно нереально. Здесь уместно напомнить. В США большой опыт организации научных исследований, то есть организации работ, сильно зависящих от конкретной личности. Обычная схема здесь: средства выделяются под конкретную личность, но организация, выделяющая средства, назначает менеджера, контролирующего расход выделенных средств и тем косвенно контролирующего ход исследования. Тем не менее, менеджер в ход собственно исследований не вме- 36 число ошибок, а не скрыть их. Персонал, участвующий в привычных приёмосдаточных испытаниях, меньше нервничает, а значит, и меньше ошибается. Основная цель промежуточных приёмо-сдаточных испытаний снизить стоимость устранения выявленной ошибки. Интуитивно ясно, чем позднее обнаружена ошибка, тем дороже стоимость её устранения. Распределение стоимости устранения ошибок по фазам см. на рис Требования/спецификации Сопровождение Рис. 3.3 Распределение стоимости устранения ошибок по фазам На рисунке видно, что ликвидация ошибок в стадии сопровождения наиболее дорогое удовольствие, что, впрочем, естественно. Недостаток этого рисунка в том, что ошибка ошибке рознь. Одно дело выявить при сопровождении ошибку программиста, которую, чаще всего, тут же ликвидируют (имеется в виду нормальное сопровождение с доступом к текстам программ), другое дело обнаружить на этой же стадии ошибку постановки, которая может привести к переработке всей реализации программы. Показательны следующие статистические данные: если ошибка фиксируется и устраняется на этапе формирования требований к проекту, организации это обходится в 139 долларов. В процессе кодирования средняя стоимость ошибки достигает 1000 долларов. На этапе тестирования, столь любимом многими компаниями, устранение ошибки обходится уже в 7000 долларов, а на этапе внедрения в 14 тысяч долларов [3]. Поэтому действия персонала при обнаружении ошибки зависят от того: 1) на какой стадии была обнаружена ошибка; 2) на какой стадии была сделана ошибка; 3) трудоёмкости ликвидации ошибки. Если трудоёмкость устранения ошибки более 10% трудоёмкости самой разработки, то стоит подумать, надо ли устранять ошибку. Не дешевле ли отказаться пока от части возможностей, но сдать программу вовремя. Однако такие решения обязательно согласуются с заказчиком. Не так плохо сдать программу вовремя, хоть и с ошибками, плохо утаить обнаруженную ошибку от заказчика. 61

21 Приемо сдаточные испытания и сопровождение 54% Отладка 46% Рис. 3.2 Распределение выявленных ошибок по фазам Из рисунка видно, что в основном ошибки выявляются на этапе сопровождения, хотя и при отладке (рис. 3.2) выявляется достаточно значительное количество ошибок. Принципиально это зависит от квалификации и добросовестности программиста. Квалифицированный программист делает меньше собственных ошибок и лучше и быстрее находит как свои, так и чужие ошибки. Добросовестный программист просто пропускает большее число контрольных примеров. Только от квалификации программиста зависит плотность ошибок в программе. Не от типа задачи, не от языка программирования, не от среды реализации плотность ошибок не зависит. На рис. 3.2 нет разделения, но примерно 20-30% ошибок выявляются во время приёмо-сдаточных испытаний. Причин для этого как минимум две: Первая нервозность, а следовательно, и повышенная вероятность ошибочных действий персонала во время приёмо-сдаточных испытаний. Не следует забывать, что во время приёмо-сдаточных испытаний наибольшая вероятность ошибок персонала, но цель приёмо-сдаточных испытаний выявить ошибки реализации программного обеспечения, а не ошибки персонала. Вторая участие в приёмо-сдаточных испытаниях заказчика и пользователя сдаваемой системы (!). Сдаваемую программную среду, может быть, впервые после окончания постановки, видит пользователь. Надо ли говорить, что пользователь лучше всех знает, что ему нужно, но хуже всех представляет как передать это своё знание разработчикам, а мыслит он отнюдь не в терминах и понятиях программиста. Отсюда, кстати, рекомендация: устраивайте промежуточные приёмосдаточные испытания. Это позволит выявить ошибки на ранних стадиях реализации, а значит, у вас будет время на устранение ошибок. Кроме того, заказчик и пользователь привыкают к сотрудничеству с разработчиками. Они видят, что разработчик стремится к наиболее полной и адекватной реализации постановки, что разработчик стремится выявить как можно ранее возможно большее 60 шивается. Исследования организует и направляет научный руководитель, та самая личность, под идеи которого выделили средства. Кстати, производство кино выполняется по этой же схеме. Почему в производстве ПО не устоялась эта схема? Всё дело в неуникальности разработки ПО. Каждое научное исследование уникально, а вот производство ПО нет. С самого начала фирмы, производящие ПО, а тем более, когда появились фирмы, основным занятием которых стало производство ПО, стремились запустить поток производства ПО. А поток характерен тем, что управляет им уже менеджер, а он стремится избавиться от зависимости от личности программиста. Менеджер стремится так наладить производство, чтобы в любой момент любое работающее звено можно было заменить на такое же! Менеджер производит прибыль, деньги, а не программы. Программист им рассматривается как винтик, может быть, очень дорогой, но всё-таки винтик, который можно и нужно в любой момент заменить на другой такой же. (В любом случае, вольно или невольно, менеджер стремится к этой схеме. При производстве денег нет места личности.) Однако здесь профессиональные менеджеры встретили неожиданные трудности. С. И. Бобровский [3] приводит следующую статистику: 25% американских компаний, выпускающих ПО, имели опоздание с выпуском ПО на 7-12 месяцев, 30% на месяца, 20% более чем на 24 месяца. Практика показала, что в срок и рамки бюджета укладывается 17% всех проектов. Остальные проекты превышают бюджет на 189%, сроки на 222%, а реализуется в них 61% требуемых заказчиком возможностей [9]. Более того, практика показала, что профессиональные менеджеры проваливали более 50% всех программных проектов. Однако у программистов, руководящих проектами, почти не было провальных проектов! (Не следует забывать, что не любой программист может стать менеджером.) С. И. Бобровский [3] косвенно ставит эту проблему, задавая вопрос: Чем заняться? Тем, что приносит деньги, или тем, что интересно? За сорок лет развития программирования и технологии найдено несколько схем организации производства ПО. Оказалось, что можно организовать как потоковое производство ПО, так и уникальное, но затраты на производство ПО будут сильно зависеть от конечной цели и поставленных задач и от объёма проекта. Кроме того, одни технологии оптимальны при выполнении малых проектов, а другие больших. Стоимость и время выполнения проекта сильно зависят от требуемого качества выпускаемого ПО и его сложности. То есть при предварительной оценке стоимости проекта следует учитывать объём проекта, сложность проекта и требуемое качество. Одна из методик оценки объёма проекта совместно со сложностью метод функциональных точек. За функциональную точку принимается, например, пользовательский экран, таблица в базе данных. В принципе, за функциональную точку принимается объект обработки, для простоты оценивают одну функциональную точку в заданном числе операторов языка (см. С. И. Бобровский [3]). Отсюда мы видим, что нет строгого определения функциональной точки, а её конечное измеримое выражение зависит как от языка программирования, так 37

22 и от определённого произвола эксперта. Но здесь же заметим, что количество функциональных точек можно определить только после определённой проработки задачи, точнее, только после постановки и начала разработки (см. ниже). Один программист, как правило, может выполнить проект объёмом не более 100 функциональных точек примерно за 6 месяцев год, при примерно 15% провалов. Большинство коммерческих приложений укладываются примерно в 1000 функциональных точек. Для разработки требуется группа около 10 человек и примерно год времени. Где-то 15% групповых проектов тоже проваливаются, а вот программист одиночка при таком объёме терпит крах уже в 65% случаев. Для проекта объёмом в функциональных точек требуется около 100 разработчиков. Остро встают вопросы организации совместной работы нескольких групп сотрудников. Работы длятся от 1,5 до 5 лет, и при этом запланированные сроки чаще всего не выдерживаются [3]. Видим, что универсального способа измерения объёма проекта не существует. Например, на стоимость разработки серьёзно влияют ресурсы целевой системы, на которой будет развёрнут продукт. Например, объём ОЗУ: одно дело ваш сортируемый массив помещается в ОЗУ и вы используете внутренние сортировки, другое дело вам приходится разбираться с внешними сортировками, если массив не помещается целиком в память. С другой стороны, возникает вопрос: объём ресурсов целевой системы это требование, выставляемое заказчиком, или спецификации, разработанные системными аналитиками по результатам постановки задачи. Отсюда следует, что у нас нет чёткого деления технологического процесса производства программ на фазы, хотя мы и выделяем постановку, разработку, эксплуатацию. С другой стороны, американцы делают гораздо более подробное деление: требование/цели/спецификации, внешнее проектирование, внутреннее проектирование, реализация, отладка/тестирование, внедрение, эксплуатация/сопровождение. Ларчик просто открывается: для того чтобы менеджер, который не разбирается в программировании, мог контролировать процесс разработки программ, он должен иметь набор формализмов, следуя которым, можно было бы реально контролировать процесс разработки и влиять на его ход. Необходим набор формализмов, который бы позволял управлять разработкой проекта. Определим постановку как процесс получения документа, называемого техническое задание (ТЗ). См. [6], где подробно разобран состав как ТЗ, так и собственно постановки. Мы можем определить, что должно входить в постановку и ТЗ, каким должен быть результат постановки, насколько важна постановка, но не можем сказать, как она делается. Конкретная методика выполнения постановки зависит от области, в которой она делается, то есть от той задачи, которая предлагается к программированию. Насколько важна стадия постановки? Чрезвычайно важна. Она определяет успех всего проекта. Можно долго искать философский камень и, в конце концов, с удивлением понять, что его просто не существует. Постановку вы- 38 В этой связи существует одна очень интересная ошибка рассматривать результаты постановки, чаще всего, требования, как нечто незыблемое, безошибочное, а следовательно, неизменяемое. Отсутствие постановки в жизненном цикле ПО косвенно отражает допущение безошибочности постановки. Кроме того, раз постановка безошибочно сделана, из жизненного цикла ПО исключается пользователь, что приводит к программированию ради программирования и неизвестно для кого. С. И. Бобровский [3] замечает: Согласно статистике, от 60 до 90% ошибок в сложных программах связаны с неверной или неправильной формулировкой требований к будущему продукту. Ошибки в требованиях приводят к тому, что в архитектуру системы изначально закладываются противоречия, устранить которые на этапах реализации практически невозможно. Ошибки могут быть сделаны на любой стадии производства программного обеспечения. При проектировании возникает до 61-64% ошибок и лишь остальные при реализации (см. рис. 3.1; Р. Гласс [7]). Кроме того, ошибки, допущенные при проектировании, влияют на все последующие стадии, а их ликвидация обходится гораздо дороже. Иной раз ошибки, пропущенные на этой стадии, приводят к пересмотру всей схемы реализации программы. Ф. Брукс отмечает, что ошибки, делаемые программистом, в большинстве случаев менее существенны, чем концептуальные ошибки, получаемые при проектировании. Реализация 36 39% Проектирование 61 64% Рис. 3.1 Распределение допущенных ошибок по фазам Из графика видно, что, рассматривая постановку или результаты проектирования как безошибочные, мы закладываем в будущую программу не менее 60% концептуальных (!) ошибок. Это не ошибки программиста, которые влияют, чаще всего, только на его программу, это ошибки постановки, которые принципиально могут обрушить будущую программную среду. Программистов как специалистов, сдающих окончательный продукт заказчику, должно интересовать, когда и сколько выявляется ошибок, стоимость их ликвидации, что делать при выявлении ошибки. Распределение выявленных ошибок приведено на рис

23 даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.» Другими словами, ситуация как в русской народной сказке: «Поди туда, не знаю куда, принеси то, не знаю что». Из всего вышесказанного следует, что вы не можете слепо использовать приёмы и методы технологии при программировании, какими бы эффективными они не казались. Результаты могут быть совсем не те, на которые надеются исполнители. Ваша цель не в том, чтобы использовать, например, ООП при программировании, а в том, чтобы понять, нужно ли вообще ООП при выполнении конкретного задания. Любые средства должны использоваться строго по необходимости. При прочих равных условиях программа, использующая меньшее количество ресурсов, предпочтительнее программы, запрашивающей их больше. Кроме того, всё вышесказанное существенно меняет ориентиры в работе программиста: цель работы программиста не создание абсолютно безошибочных программ, а создание программ, выдающих ожидаемые пользователем результаты при обработке задаваемого множества входных данных. Вот эти, ожидаемые пользователем результаты и являются целью написания программы. Появятся они в результате работы программы скорее всего, заказчик примет вашу программу, хоть и с оговорками. Не будет ожидаемых результатов ваша программа, скорее всего, не будет принята, как бы красиво вы её не запрограммировали. Помните: пользователю всё равно, как и какими средствами вы реализовали программу. Заказчику нужен результат работы программы, получаемый на заданном количестве ресурсов. Такие интересные сведения, как то, что вы написали программу на языке С, а не на Basic, оставьте своему коллегепрограммисту. Нет, пользователю можно сказать об этом, но только тогда, когда он об этом спросит. Однако, если мы изначально поставляем пользователю некоторый технический продукт с ошибками, то хотелось бы хоть немного разобраться с тем, что такое ошибка, когда они возникают, как влияют на жизненный цикл программного обеспечения, как много их бывает? Одну из версий Windows NT тестировало 250 инженеров в течение года и выявило 30 тысяч ошибок. Впечатляет, но ведь никто не отказался от Windows NT под предлогом наличия в ней ошибок. В последнее время всё чаще говорят о жизненном цикле ошибки. В отличие от программы ошибка завершает свой жизненный цикл смертью. Все стремятся снизить количество ошибок в выпускаемом продукте, но что такое ошибка, в общем, никто не знает. Нет строгого определения ошибки. Одна и та же ситуация или явление могут в зависимости от условий рассматриваться и как ошибка и как правильное ожидаемое поведение системы. Рассмотрите ситуацию обозначаемому словом сдаться. «Сдаться на милость победителя» для сдающегося это ошибка, но для победителя это ожидаемая и весьма желаемая ситуация. Сдаться на милость своей дамы: ситуация, рассматриваемая как желаемая обеими сторонами, но обратите внимание, насколько всё здесь зависит от конкретики. 58 полняют чаще всего одни специалисты, а программируют другие. Крайними в этой схеме являются те, кто программирует: они выполняют окончательную сдачу «работающего проекта» и часто они, косвенно, несут ответственность за ошибки постановщиков. Важность стадии постановки лучше всего характеризует следующий эмпирический закон: один час постановки пять часов отладки. Это касалось ещё тех времён, когда программа писалась на бланке и бланк сдавался на перфорацию. Теперь, в связи с работой на мониторе можно утверждать: один час постановки десять часов отладки. Экономьте своё время тщательно прорабатывайте постановку задачи. В науке есть утверждение: решить задачу может каждый, а вот поставить нет. Что значит поставить задачу? Поставить задачу значит описать, как её решить. Не следует забывать, что между постановкой задачи и её решением часто лежит пропасть. Ещё в 1954 г. Клод Шеннон в своей статье «Могут ли машины играть в шахматы?» доказал, что ЭВМ может играть в эту замечательную игру. Свою статью он закончил фразой «таким образом, в реализации программы остаются только технические трудности». На преодоление этих технических трудностей ушло более сорока лет при смене четырёх поколений ЭВМ. Таким образом, в постановке должно быть описано, как решить задачу, то есть постановка должна содержать, с одной стороны, алгоритм решения задачи, а с другой стороны, конкретные спецификации задачи: входные/выходные документы, технологические допуски на данные; сами данные и их форматы и т. д. Результатом постановки будет документ, который так и называется Постановка задачи. Объём выходных документов постановки может быть от нескольких листов формата А4 до многих томов. Предполагается, что любой прочитавший постановку задачи поймёт, как решать задачу. Сегодня, нередко, неявно выполняют подмену понятий. Вопрос как решать задачу? подменяют на как из входных документов получить выходные. Это сильно сужает класс задач, который рассматривается как программируемый в свете жизненного цикла ПО. Ну не существует у такой задачи, как игра в шахматы, ни входных документов, ни выходных. Ну не существует таких документов в любой задаче по управлению технологией производства и во множестве других задач, которые тем не менее программируются. Любая формализация в чём-то обедняет формализуемый процесс. В этом смысле постановку задачи отформализовали так, что потерялась суть постановки как таковой. Рассматриваются требования, цели, спецификации это часть результатов постановки, но не сама постановка. Временно последуем за нашими друзьями, американскими специалистами, а затем посмотрим на постановку с нашей российской колокольни. Требования, цели, спецификации: эта фаза по-другому может быть названа системным анализом (обратите внимание, что понятие постановка подменяется на совершенно новое и нигде не определённое системный анализ ). В этой фазе изучается и определяется задача. Подчеркнём: задача определяется, но не решается. Очень часто требования и цели смешиваются с процессом проектирования, который, в свою очередь, совмещается с разработкой программы, 39

24 особенно часто, когда постановку выполняет программист, что бывает гораздо чаще, чем хотелось бы. Причина в большинстве своём неправильное понимание как потребностей пользователя, так и сути самой задачи. Отсюда стремление уйти от решения трудных или плохо определённых проблем в задаче и соблазниться её частичным решением или подменить декларируемую цель на некоторую другую, ту, которая получается в процессе программирования. Всё это обязательно приводит к переработке уже существующих программ, надо ли говорить, насколько это трудоёмкий и неприятный процесс, к тому же плохо оплачиваемый. Как указывалось выше, требования к ПО разрабатывает пользователь. Тут уточним: пользователь должен входить в состав группы, разрабатывающей требования. Требования к средней или крупной системе должна разрабатывать небольшая группа. Одним из членов этой группы должно быть должностное лицо, обладающее высокими полномочиями. Директор предприятия, главный инженер, его заместители. Важно уже на этапе определения требований привлечь на свою сторону руководство предприятия. Дж. Мартин [15] прямо указывает на необходимость участия уже в процессе проектирования программной системы членов администрации. Далее будет показано, что любое внедрение ПО влечёт за собой административные мероприятия, и именно администрация лучше всего понимает, как и что в таком случае необходимо будет сделать. Проект, лишённый административной поддержки, в лучшем случае будет оплачен. То, что он не будет внедрён, однозначно. Вину же за неработающий проект чаще всего возлагают на программистов. Однако пользователем ПО чаще всего бывает не администрация, а другие специалисты. В выработке требований к ПО и далее в проектировании должен участвовать именно специалист-пользователь: если это система продажи билетов, то наличие кассира в группе постановки обязательно. Только специалист-пользователь естественным образом определит требования к системе, причём сделано это будет в терминах и понятиях пользователя. Следующим членом группы будет, как предлагает Г. Майерс [15], специалист по внешнему проектированию. В нашем понятии это собственно постановщик, специалист, понимающий, как решать поставленную задачу, какие требуются алгоритмы, данные, допуски. Очень хорошо, когда этот специалист знаком с программированием, но чаще всего необходим специалист по внутреннему проектированию. Обычно это программист, либо будущий непосредственный руководитель разработки, либо руководитель подразделения, которое займётся разработкой ПО. Требования должны быть выражены в терминах пользователя и языком, понятным пользователю. Никаких программистких терминов. Допускаются общеизвестные термины, когда требуется явным образом указать среду работы будущего продукта и мощности техники, на которой предполагается эксплуатация ПО. Желательно так указать требования, чтобы будущему пользователю было понятно, чего он хочет. Беда в том, что пользователь частенько не понимает, чего он хочет! В лучшем случае присутствует желание пусть машина за меня работает. Когда же в результате того, что машина работает вместо пользователя, последнего увольняют, пользователь и понимает, чего он хотел на самом деле НЕКОТОРЫЕ АСПЕКТЫ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ И ВНЕДРЕНИЯ ПО Ещё раз напоминаем, что между технологией программирования и традиционным производством есть существенная разница. Дело в том, что если при производстве, например, металла с заданными свойствами некто выдерживает все технологические параметры, то он обязательно достигает цели. В программировании можно выдержать все спецификации и требования постановки, все спецификации и требования технологии и пользователя и с удивлением обнаружить, что программа, совершенно правильно написанная, либо не работает, либо работает не так, как ожидает заказчик (и программист, кстати, тоже!), а заказчик потерял к реализованному программному обеспечению всякий интерес. Тут надо различать два разных момента: программа работает не так, как это предусмотрено в постановке; заказчик потерял интерес к реализованной программе. Программа может не работать, как предусмотрено в постановке, из-за неправильного понимания программистом поставленной задачи; ошибок в постановке; ошибок в программе; плохой отладки программы; из-за ограниченного набора входных данных и т. д. Основная причина в том, что в случае «технических» технологий выполняющее производство «звено законы природы», а в случае программирования выполняющее производство «звено человек», а человеку свойственно ошибаться. Более того, исследования показали, что в больших программных системах количество ошибок не может быть ниже определённого уровня (чаще всего указывается уровень 20%). Для больших программных сред всегда можно подобрать внутренне противоречивый набор входных данных. Внутренне противоречивым набором входных данных назовём такую совокупность входных данных, которая «проходит» все технологические контроли, но в результате обработки которой большая программная система либо выдаёт неверный результат, либо вообще не выдаёт результата. Но даже для простых, правильно написанных программ, которые работают согласно всем требованиям, можно подобрать пример, когда программа будет «выдавать» принципиально неверный результат. Дж. Форсайт [23] приводит изящный пример программы решения квадратного уравнения с одним неизвестным (что может быть проще?), которая написана без ошибок, но не может в принципе (!) правильно решить некоторый класс этих уравнений. Причина совсем простая: ЭВМ работает не на непрерывной числовой оси, как мы все привыкли понимать, а на дискретной. Расстояния между точками этой «дискретной прямой» растут при увеличении абсолютной величины числа, соответствующего точке. Таким образом, с одной стороны, производящее производственное звено это слабо формализованная фигура программиста. С другой стороны, мы используем идеальные законы в неидеальной среде. Этот клубок дополняется ещё и следующим: как правило, заказчик не знает, чего хочет! Ф. Брукс [4] прямо утверждает: «Я пойду дальше и стану утверждать, что на практике клиенты, 57

25 Вопросы к главе 2 1. Что такое жизненный цикл программы? Перечислите основные «за» и «против» этого термина. 2. Что такое постановка? Перечислите основные фазы постановки. 3. Кратко охарактеризуйте содержание результатов постановки. 4. Требования, цели, спецификации? 5. Кто выполняет постановку? Дайте желаемый состав группы, выполняющей постановку. 7. Цели? На какие вопросы прежде всего должны дать ответ цели? 8. Почему необходимо программировать, ориентируясь на цели? 9. Спецификации? Что должно туда входить? 10. Чем различаются процессы внешнего и внутреннего проектирования? 11. Внешнее проектирование? Кто, когда, зачем? 12. Внутреннее проектирование? Кто, когда, зачем? 13. Величина проекта? На что она влияет? 14. Производительность труда программиста? Различия в программах опытного программиста и новичка. 15. Критерии правильности программы? Что такое хорошая программа? 16. Что такое разработка? 17. Что такое архитектура ПО? 18. Концепция уровней абстракции. 19. Достоинства «концепции уровней абстракции». 20. Проектирование сверху вниз. 22. Распределение стоимости разработки ПО по технологическим стадиям. 23. Сопровождение ПО: кратко охарактеризовать технологическую стадию. 24. Особенности жизненного цикла коробочного ПО. 25. Какие экономические различия при управлении производством технических продуктов и производством ПО? 26. Почему менеджеры стремятся к технологиям, не зависящим от личности программиста. 27. Как делятся проекты по величине проекта? 28. Как делятся проекты по взаимоотношению к пользователю? 56 Цели то, чего необходимо достигнуть. Алан Купер [12] подчёркивает, что при проектировании программ важно проектирование взаимодействия программы с пользователем, или, по-другому, проектирование интерфейса ПО. Так как чаще всего проектирование взаимодействия не выполняется вовсе, то программы взаимодействуют с человеком псевдомашинным образом, что часто удобно для программы и программиста, но чрезвычайно неудобно для человека. Один из путей повышения качества программного обеспечения проектирование этого самого взаимодействия, но это проектирование обязано быть ориентированным на цели!, достигаемые пользователем. Однако цели могут быть личные, корпоративные, практические, ложные. Как это ни странно, но при проектировании взаимодействия наиболее важными целями считаются личные цели. С вашим продуктом будет работать конкретный пользователь. Он будет стараться достигнуть целей вашего бизнеса, но только после того, как достигнет своих собственных целей. Сущность качественного проектирования взаимодействия заключается в изобретении таких взаимодействий, которые помогут пользователям достигать практических целей, не препятствуя достижению личных целей. Требуется разделить и явно сформировать цели проекта и цели программы, что чаще всего не делается. Процесс принятия целей прежде всего, процесс поиска компромиссов между противоречивыми требованиями. Все цели должны быть сформированы официально. В случаях, когда программисты не имеют списка целей проекта, они получают противоречивые и неожиданные результаты. Цели проекта должны давать ответы на вопросы (Г. Майерс [15]): 1) ориентировочная стоимость каждого процесса; 2) календарный план проекта; 3) цели для каждого процесса тестирования; 4) цели в области адаптируемости: должно быть ясно, в какой степени проектируемое ПО может быть модифицировано; 5) критерии оценки готовности продукта к использованию; 6) вопросы сопровождения и документации. Цели программного обеспечения зависят от задач. Но необходимо сделать несколько кратких замечаний об общих правилах формулирования целей. Цели должны быть чёткими, явными, разумными и измеримыми. Цель, которую нельзя понять, бесполезна. Цели должны быть известны всем разработчикам проекта. Цели должны быть достижимы. Все цели необходимо формулировать по возможности в количественных терминах. Каждая цель должна быть сформулирована достаточно подробно. Г. Майерс [15]рекомендует вместе с целями сформулировать и не цели. Цели и задачи разные вещи. Цель это конечное состояние, тогда как задача переходный процесс, необходимый для достижения цели. Различать задачи и цели просто: задачи меняются вместе с технологией, тогда как цели 41

26 стабильны. Цели стабильная сущность. Это основная причина, по которой проектирование под цели всегда уместно. Чаще всего программисты проектируют и разрабатывают под задачи, только при анализе целей может быть найдено верное решение. Для качественного проектирования необходимо так выполнить систему, чтобы позволить пользователям достигать практических целей, не отказываясь от целей личных. Любая система, идущая вразрез с личными целями, в конечном счёте обречена на неудачу, независимо от того, насколько качественно позволяет достигать целей иного рода. Следует хотя бы просто перечислить некоторые цели. Личные цели: Не чувствовать себя глупо. Не совершать ошибок. Выполнить адекватный объём работы. Развлечься (получить удовольствие или хотя бы не страдать от скуки). Корпоративные цели: Цели большинства корпораций увеличить прибыли. В своём большинстве, если пользователь не акционер компании, в которой он работает, корпоративные цели противоречат личным. Кратко перечислим: Увеличить прибыль. Увеличить рыночную долю. Победить конкурентов. Нанять больше сотрудников. Предложить новые продукты и услуги. Выпустить акции компании в свободное обращение. Гигиенические цели: Программа, которая не позволяет достичь какой-либо корпоративной цели, потерпит неудачу. Практические цели: Практические цели восполняют пробел между стремлениями компании и стремлениями отдельного пользователя. Например, практическая цель удовлетворения требований клиента соединяет корпоративную цель (более высокие прибыли) с личной целью пользователя (работать продуктивно). Избегать собраний. Удовлетворять требованиям клиента. Сохранять информацию о заказах. Создавать математические модели бизнеса. Однако следует помнить, что надо проектировать такое ПО, которое позволяет достигнуть, прежде всего, личных целей. Чаще программисты стремятся к практическим целям и задачам: они понятнее и привлекательнее. Однако интерфейс, ориентированный на задачи, провоцирует пользователя на ошибки и снижает их способность быть продуктивными на личном уровне. Помните: если пользователь не может достичь личных целей, то он не способен эффективно достигать целей компании. Наиболее эффективны счастливые и довольные сотрудники. Тем не менее, если программа игнорирует 42 Требования пользователя Требования / спецификации 10% Сопровождение 50% Проектирование 10% Реализация 10% 55 Отладка 20% Эксплуатация Рис. 2.1 Жизненный цикл программного обеспечения, распределение стоимости по фазам Отсюда видно, что, несмотря на свою ценность, стадия проектирования как таковая занимает не более 20% стоимости программного обеспечения. Стадия собственно программирования около 30%. А вот стоимость сопровождения составляет аж половину стоимости программного обеспечения, что было далеко не очевидно до исследования. Следует учесть, что стоимость сопровождения зависит от сроков эксплуатации программы и количества изменений, выполненных во время сопровождения. Что следует из рис. 2.1? Из него следует, что если объём продаж вашего ПО не велик, то как бы вы не увеличивали стоимость вашего ПО, большой прибыли вы не получите. Приобретение ПО одноразовая акция, а бесконечное увеличение стоимости продукта снизит его конкурентные возможности и приведёт к тому, что покупатель перестанет приобретать дорогой продукт. А вот на сопровождении ПО можно заработать стабильную прибыль. Так и делают фирмы, производящие тяжёлые продукты. Первый год покупатель пользуется бесплатной технической поддержкой фирмы, но далее заключается договор на техническое сопровождение ПО. Стоимость сопровождения зависит от приобретённого ПО и ожидаемых возможностей поддержки. Обычно стоимость технической поддержки составляет от 10% до 30% стоимости приобретённого ПО, но заключается договор на техническую поддержку ежегодно! Однако в современных реалиях можно получать доход и с объёма продаж, что доказала фирма Microsoft. Относительно невысокая стоимость ОС Windows окупается громадным количеством установок и драконовским лицензионным соглашением. Себестоимость копии Windows не превышает стоимости магнитного носителя, а согласно лицензионному соглашению вы не можете в каждый конкретный момент времени иметь более одной копии лицензионной версии.

27 е) составляется список пожеланий пользователя; ё) расширяются возможности программы, если это расширение ничего разработчику не стоит. ОПЭ выполняется заказчиком. Заказчик издаёт приказ об ОПЭ, где перечислены лица, ответственные за проведение работ с внедряемой программой и взаимодействие с разработчиками, сроки проведения ОПЭ, назначается состав будущей группы сопровождения программы (она может состоять и из одного человека). В приказе об ОПЭ указывается, чем заканчивается ОПЭ. После окончания ОПЭ чаще всего программа поступает в эксплуатацию/сопровождение, о чём также составляется приказ. В приказе обязательно указывается, кто, на каких должностях, с какой квалификацией работает с программой. В соответствующие должностные инструкции вносятся изменения. Эксплуатация программы этап, завершающий жизненный цикл программного обеспечения. В России эксплуатация обычно не предусматривала изменений в эксплуатируемой программе. Могла поменяться технология работы с программой, если это было возможно и необходимо. При обнаружении ошибки в программе о ней обязательно сообщали разработчику, возможности программы, при которых выявлена ошибка, просто переставали использоваться, если разработчик не исправлял программу. В любом случае, группа сопровождения исключительно редко модифицировала программу. Как правило, на модификацию программы заключался договор с разработчиком. В США эксплуатация подразумевала модификацию программы, причём модификация программы возлагалась на группу сопровождения. Однако сразу же обнаружилось, что квалифицированные программисты не хотят заниматься сопровождением программ. Р. Гласс [7] приводит следующее рассуждение: «Бедное, старое, никем нелюбимое сопровождение. Оно заключается в удовлетворении потребностей пользователя: устранении ошибок, проведении доработок по просьбе пользователя и, вообще, повышении полезности программы. Программисты стремятся избежать такой работы, не находя в ней творческой «искры». Если проект сигнал к бою, его реализация и отладка атака и возвращение с победой, то сопровождение это ежедневная оборона, жизненно необходимая, но обычно непочётная. Как ни парадоксально, но занимающийся сопровождением программист, который, возможно, является наиболее важным лицом, определяющим судьбу программы у заказчика, зачастую далеко не самый способный и уважаемый человек у себя в коллективе. Этим и обусловлена самая большая помеха при сопровождении отсутствие квалифицированных кадров. Прекрасно настроенная скрипка Страдивари в руках такого «специалиста» может стать пригодной только для растопки печи. Подобным отношением, лишающим сопровождение очарования и почёта, можно загубить всё то хорошее, что было достигнуто на предыдущих фазах разработки». Возвращаясь к жизненному циклу программного обеспечения, рассмотрим, сколько занимает каждая стадия в «жизни программы». Обычно рассматривают распределение стоимости каждой стадии (схемы приведены из Р. Гласс [7]): 54 практические цели, ориентируясь только на цели пользователя, то она превращается в компьютерную игру. Ложные цели: Многие из ложных целей ставятся программистами. Как правило, эти цели облегчают создание программного обеспечения, но именно они и делают из программ танцующих медведей [12], то есть программ, взаимодействующих с человеком псевдомашинным образом. Примеры ложных целей: Экономия памяти. Уменьшение потребности в клавиатурном вводе. Поддержка работы браузера. Обеспечение целостности данных. Ускорение ввода данных. Увеличение скорости исполнения программ. Использование новейших технологий или возможностей. Улучшение внешнего вида и т. д. Обратим внимание, что эти цели понятны программисту и непонятны пользователю. Спецификации к спецификациям относят описание входных, выходных и внутренних обменных данных, а также некоторых состояний программной системы. Ясно, что большинство входных данных определены до процесса проектирования. Множество выходных данных, но не все, также определены до процесса проектирования, иначе не понятно, что проектировать. Тем не менее, некоторый объём как входных, так и выходных данных определяется только при проектировании. Форматы и способы представления, необходимые в ходе решения задачи, определяются только при проектировании. То есть имеются спецификации, определяемые в процессе постановки, а есть спецификации, определяемые в процессе проектирования, фазе, следующей за постановкой. Обе фазы взаимосвязаны. В результате проектирования могут быть откорректированы не только спецификации, полученные в результате постановки, но и требования, и даже сама постановка. Исключительно редко по результатам проектирования меняются цели. Однако это маргинальный случай: смена цели меняет всё! Если у вас поменялась цель, то вы выполняете уже постановку задачи, которая решает, вообще говоря, другие проблемы, а отнюдь не те, что ставились первоначально. Детальные спецификации должны обязательно иметь: 1. Описание входных данных: точное описание форматов представления, допустимых значений, области изменения. 2. Описание выходных данных: во-первых, то же, что и для входных данных, во-вторых, точное описание работы результатов всех функций, сообщения об ошибках. Требуется описать функциональные связи входных данных с выходными, чтобы читатель спецификаций был в состоянии представить, какие варианты выходных данных получаются при вводе в систему заданного варианта входных данных. Для всех функций необходимо указать результаты при вводе неверных входных данных. 43

28 3. Преобразования системы: требуется описать преобразования и состояния системы с точки зрения пользователя. Например, в библиотечной системе при сдаче книги пользователем необходимо изменить запись в карточке пользователя и изменить запись о наличии книг в библиотеке. 4. Защита системы: необходимо перечислить все уровни защиты системы. Кто к какой информации имеет доступ и какие функции может запускать. 5. Эффективность: минимальные требования к скорости работы системы и потребляемым ресурсам. 6. Некоторые замечания по программированию, например: систему необходимо реализовать так, чтобы она имела сопряжение с другой заданной системой, и т. п. Кроме того, в спецификации должен входить «контрольный пример», по возможности со всеми промежуточными шагами, если таковые имеются. Контрольным примером называется один или более конкретных наборов входных данных с соответствующими им выходными данными. Заметим, что иметь контрольный пример не всегда возможно, а иной раз выполнение ПО на контрольном примере настолько трудоёмко, что от этого отказываются. Обратим внимание, что всё это внешние спецификации данные, форматы и преобразования с точки зрения пользователя. Здесь нет ни способов, ни форматов представления информации в машине. Всё это появится только в результате процесса внутреннего проектирования системы, выполняемого программистом. Мы подробно разобрали требования, цели, спецификации, чтобы увидеть, чего же нет в такой трактовке постановки. А нет в ней самой малости: каким образом, имея все эти требования и спецификации, получить результат или достигнуть цели? Нет собственно постановки! Как можно запрограммировать задачу, не зная её сути? Либо программист разберётся в задаче, на что требуется ох как много времени и знаний, либо кто-то ему аккуратно распишет последовательность действий со всеми технологическими ограничениями. Вот это расписывание последовательности действий и есть процесс постановки. Нужна она для того, чтобы неграмотному программисту предоставить алгоритм или путь решения программируемой задачи. Но даже тогда, когда за программирование берётся специалист, прекрасно разбирающийся в задаче, всё равно необходима постановка. Во-первых, в объёмных задачах нельзя на память представить все цепочки как данных, так и их преобразований. Во-вторых, реализацию объёмной задачи выполняет не один человек, следовательно, все должны иметь один руководящий документ. В-третьих, постановка всегда определённая формализация, то есть в процессе постановки происходит разделение формальных и неформальных действий при решении задачи. Постановка даёт ответ на вопрос о возможности решения задачи на ЭВМ и указывает путь, как это сделать. Кстати, отсюда следует, что постановка может дать вывод о невозможности сегодня решения поставленной задачи на ЭВМ. Безусловно, лучше понять это на этапе постановки, а не в результате многократных, безрезультатных попыток написания ПО, вроде бы решающего поставленную задачу. 44 Основная наша беда, а может быть, наоборот, в том, что чаще всего все процессы постановку, проектирование, реализацию, внедрение, эксплуатацию, сопровождение делает один специалист, который и называется программистом. На самом деле и в США в мелких, а часто и в средних фирмах всё также выполняется программистами: узкую специализацию, а следовательно, и значительное число сотрудников могут позволить себе только крупные фирмы. Вообще величина фирмы влияет на технологию производства ПО, это будет хорошо видно при обзоре существующих технологий (см. ниже). Завершается реализация приёмо-сдаточными испытаниями. В комиссию по приёму программы входят обе стороны: заказчик и подрядчик. Желательно, чтобы от заказчика входили лица, которые выполняли постановку, но, в общемто, это дело заказчика. До испытаний формируется набор тестов; формулируется, что должна делать программа и как себя вести. Если программа проходит тесты, то пишется акт о приёме программы в опытно-промышленную эксплуатацию (ОПЭ), который подписывается всеми членами комиссии. Программа вместе с сопровождающей документацией передаётся заказчику, который начинает опытно-промышленную эксплуатацию программы. Если программа не проходит испытания, то комиссия определяет степень готовности программы к опытно-промышленной эксплуатации. Существует два основных сценария дальнейшего развития событий: Программу передают в ОПЭ с указаниями сроков, исполнителей и способов ликвидации выявленных ошибок. Обычная практика при этом ликвидация ошибок за счёт подрядчика. Если программа по каким-то причинам не может быть передана в ОПЭ, но подрядчик берётся ликвидировать ошибки в достаточно короткие сроки (обычно не более месяца), то назначается новый срок сдачи программы. Ликвидация ошибок и в этом случае за счёт подрядчика. Надо понимать, что этот сценарий может быть реализован не более одного раза. Если заказчик не принимает программу по объективным причинам, то об этом составляется акт, который сопровождается протоколом претензий. Там подробно указываются причины отказа считать программу готовой. Дальнейшее развитие событий зависит от множества причин и может быть самым разным. От отказа оплачивать разработку и разрыва взаимоотношений с подрядчиком до заключения нового договора на продолжение разработки с соответствующим финансированием. Опытно-промышленная эксплуатация это этап внедрения программы. Разработчики могут не участвовать во внедрении, но общепринята практика заключения договора с разработчиком на участие в ОПЭ. Во время ОПЭ: а) ликвидируются обнаруженные ошибки, которые не были найдены ранее; б) пользователь обучается работе с программой; в) пересматривается документация на программу так, чтобы отвечать в первую очередь на вопросы пользователей; г) составляется список наиболее часто выполняемых запросов, чтобы далее автоматизировать их выполнение; д) составляется список претензий пользователя; 53

29 Кроме того, здесь имеется ещё одна сложность. Поскольку иерархическая декомпозиция состоит в том, чтобы переходить на следующий уровень не прежде, чем закончится проектирование предыдущего, она может задержать определение разрешимости проблем, которые таит в себе более низкий уровень. Истиной является то, что в программировании имеются серьёзные проблемы на всех уровнях детализации, и в большинстве случаев они вскрываются только тогда, когда начинается детализация самого нижнего уровня. Иерархическая структура может, конечно, рухнуть, если один из её низших элементов развалится. Отметим, что мы начали обсуждать процесс разработки программы, но опять незаметно вернулись к процессу внутреннего проектирования. Наша цель была в том, чтобы показать, что процесс внутреннего проектирования и разработки программы очень тесно связаны между собой и их разделение весьма условно. При проектировании даже средних программных комплексов разработка программы невозможна без предварительного внутреннего проектирования. Всегда желательно выполнить проектирование, но проектирование должно выполняться с учётом будущего программирования, иначе могут быть чрезвычайно неприятные явления, которые, к тому же, нельзя будет впоследствии исправить. Представьте, что вы пишете программный комплекс, имитирующий поведение человека. Интуитивно хочется разделить этот комплекс на два подкомплекса: мужчина и женщина. Однако, спроектировав структуры подкомплексов мужчина/женщина, вы тотчас же обнаружите, что список функций (модулей) с обеих сторон будет совершенно одинаков, за исключением полового поведения и поведения во время беременности. Естественно, возникает желание реализовывать каждую функцию одним модулем, что должно сэкономить ресурсы, уменьшить размеры программы и т. д. Вот так и появляются гермафродиты: поскольку каждый модуль будет обладать возможностью «поведения» как мужчины, так и женщины. Мало того, что каждый модуль станет сложнее и, конечно же, менее надёжен, мы потеряем возможность по вызову модуля быстро определить, в какой среде (мужчина/женщина) этот модуль работает в данный момент. (Действительность менее удручающа большинство современных средств позволяет иметь в системе несколько модулей, выполняющих очень похожие функции, имеющих одно имя: перегрузка функций в C++.) После проектирования, а нередко одновременно с ним, выполняется кодирование программы или её написание, а затем отладка программы. Отладка будет рассмотрена ниже в отдельной главе. При реализации больших систем процессы сборки, тестирования и документирования рассматриваются как отдельные и их часто выполняют специальные группы. Тут ещё одно отличие российской действительности от американской. По многим причинам в России процессы сборки, тестирования и документирования никогда не рассматривались отдельно от написания программы и её отладки. Во-первых, в России никогда не было узкой специализации. А во-вторых, американцы утверждают, что в России не реализовывались большие программные проекты, с чем, конечно, мы можем обоснованно поспорить. Ещё раз напоминаем, другие реалии общества другая организация работ. 52 Однако в старых американских учебниках существует этап внешнего проектирования, который относят к фазе проектирования системы. Внешнее проектирование процесс описания ожидаемого поведения разрабатываемого продукта с точки зрения внешнего по отношению к нему наблюдателя. Цель построение внешних взаимодействий будущей системы без конкретизации её внутреннего устройства. Результатом этого процесса должны быть полные и правильные внешние спецификации. Методологии этого процесса не существует. Можно делать опросы, предварительные обследования, заполнять различные предварительные входные формы и т. д. Мы не можем точно сказать, как именно следует выполнять эту часть проектирования, хотя точно известно, что должно появиться в результате выполнения этого процесса. Но два момента требуется осветить. Во-первых, эту часть проектирования желательно выполнять как можно меньшим числом персонала, в идеале всего одним специалистом, если такое возможно. Во-вторых, они не должны быть программистами. Внешнее проектирование, прежде всего, касается понимания обстановки, проблем и потребностей пользователя, психологии общения человека с машиной. С некоторой натяжкой можно этап внешнего проектирования принять за постановку. Просто описание ожидаемого поведения системы, вообще говоря, не описание решения задачи, но свойства процесса те же. Мы не знаем, как его выполнять, но знаем, что получить в результате. Мы знаем, кем должен выполняться процесс. Мы знаем, что процесс существует и без него трудоёмкость реализации программного обеспечения вырастает на порядок, а то и более. Обращаем ваше внимание, что постановка сильно влияет на процесс разработки ПО. Таким образом, постановка это подробное описание алгоритма или алгоритмов решения задачи, ограничений и условий применения этих алгоритмов. Постановка может выполняться группой специалистов, но основную её часть делает один специалист по решению разрабатываемой задачи. Важно участие в группе постановки как высокого административного лица заказчика, так и конкретного пользователя будущей системой. Результатом постановки становится документ под названием Постановка задачи, который подписывается всеми членами группы постановки, а также администрацией заказчика. В случае участия в группе постановки представителя подрядчика он также подписывается под постановкой. Один из вопросов, на которые должна ответить постановка: Какова трудоёмкость реализации проекта? Отсюда становится ясна стоимость разработки. Обращаем ваше внимание на то, что постановка одна из фаз проекта, а следовательно, трудоёмкость постановки должна учитываться в объёме реализации проекта, стоимость постановки входит в стоимость реализации проекта. Постановка это этап. После постановки начинается этап проектирования и далее разработки. Предполагается, что с этих этапов к постановке не возвращаются. На самом деле это ошибочное допущение. Как нет программирования без ошибок, так и в постановке могут быть ошибки. В последнее время стало модным исключать постановку из жизненного цикла программного обеспечения. Постановка точно не программирование. 45

30 Программист может не участвовать в постановке. Конечно, это верно, кто б спорил. Но сторонники этой точки зрения должны будут объяснить несколько явлений. Почему лучшие постановки получаются у программистов, освоивших область программируемых задач? На какой этап передаётся управление в случае обнаружения ошибок в постановке на любом последующем этапе? Это отнюдь не академические вопросы. Отсутствие постановки как этапа жизненного цикла программного обеспечения предполагает отсутствие ресурсов на её реализацию: времени и финансов, а также трудовых ресурсов. Каким образом должно появиться ТЗ? Кто и как должен разработать безошибочные и непротиворечивые требования и спецификации? Кто должен исправлять ошибки в постановке при обнаружении их на этапе разработки или, ещё хуже, на этапе эксплуатации? Удивительное дело: постановка отсутствует, но документ Постановка задачи должен быть, никто не отрицает его необходимости. Отсутствие этапа постановки приводит к тому, что заказчик заказывает задачу непосредственно командам программистов, не предусматривая в реализации времени на постановку. Однако: час постановки десять часов отладки. Постановка всё равно будет каким-то образом сделана, но произойдёт это за счёт времени, отведённого под разработку. Кроме того, в этом случае резко увеличивается время отладки ПО и падает качество ПО. Надо ли говорить, что такой проект обязательно выбьется из графика, что при реализации такого проекта обязательно будет перерасход сметы. Более того, так как постановка теперь делается программистами, то она реализуется не так, как это представляет пользователь, не в терминах и понятиях пользователя. Тем не менее стандарт ISO/IEC жизненный цикл программного обеспечения, а за ним и наш российский ГОСТ Р ИСО/МЭК не предусматривает такого этапа, как постановка. Существуют: заказ, поставка, разработка, эксплуатация, сопровождение. Казалось бы, что разработка включает в себя постановку, проектирование, программирование, отладку. Отнюдь, там нет собственно постановки или внешнего проектирования. Однако есть удивительная оговорка! : Если модель жизненного цикла программных средств не определена в договоре, то разработчик должен определить или выбрать модель жизненного цикла программных средств, соответствующую области реализации, величине и сложности проекта. При этом должны быть выбраны и структурированы в модели жизненного цикла программных средств работы и задачи процесса разработки. Другими словами: наш стандарт вам не указ, если он вас не удовлетворяет разработайте свой. Для каких же случаев подходят вышеприведённые стандарты. Есть только одна область, где явным образом, вроде бы, отсутствует постановка и где требования, цели, спецификации разрабатываются программистами для программистов, а иногда и пользователей: коробочные программные продукты. Во-первых, это проекты, не контролируемые пользователем. Во-вторых, эти проекты разрабатываются фирмами на свой страх и риск. В-третьих, в большинстве случаев это программные продукты для программистов (кто же 46 Отсюда видно, что даже этот поверхностный анализ идеи показывает часть недостатков, присущих системам, реализуемым по схеме «система, управляемая портом (сообщениями)». Поэтому на вопрос «Могла ли фирма Microsoft сделать свой продукт лучше (с точки зрения программиста, а не пользователя)?», автор всегда отвечал: «Конечно же, могла, но родимые пятна всё равно останутся». Такие системы всегда будут рыхлыми, потребляющими неоправданно много ресурсов и неустойчивыми в работе. А что вы хотите? Имея хаос на входе, трудно на выходе получить порядок. Оба метода описывают желаемые свойства системы, а не сам процесс проектирования. Другими словами, оба метода задают требования и спецификации. Плохо это или хорошо? Роберт Гласс в «Руководстве по надёжному программированию» (1982 г.) [7] приводит следующий любопытный пример. «Если вам дадут требования и спецификации на слона и попросят его спроектировать, вы, вероятно, задумаетесь: с чего начать, особенно если вы никогда до этого не видели слонов. Начнёте ли вы с хобота, поскольку это наиболее необычная часть, или с ног, потому что они вам понятнее, или с мозга, так как он управляет поведением животного? А может быть, со всего сразу, потому что вам надо осознать задачу в целом?» Проектировщик программ сталкивается с аналогичной проблемой. Как вы отнесетесь к задаче в целом, если ее спецификация содержит тысячи мельчайших деталей? Решить эту проблему очень важно, так как многие программы имитации слонов в действительности имитируют собак с прицепленным хоботом [7]. Очевидно, решение должно состоять в разделении спецификации на обозримые части. Одним из методов, применяемых здесь, будет «проектирование сверху вниз». Проектирование сверху вниз начинается с наиболее абстрактного описания функций системы. По этому общему описанию (верхнего уровня) последовательно создаются более детальные описания. Процесс детализации продолжается до получения проекта, пригодного для программирования. Результирующий проект имеет вид иерархического дерева. Каждый его уровень должен включать в себя законченное описание системы, прежде чем начнется построение следующего уровня. Смысл проектирования сверху вниз состоит в том, что оно дает обозримое описание на каждой стадии, а также представление взаимосвязи всех составных частей проекта. Такой подход позволяет своевременно замечать возникающие проблемы и не переходить к последующей детализации до тех пор, пока полностью не завершён предыдущий уровень. Рассматриваемый подход иногда называют «иерархической декомпозицией» из-за ступенчатой природы процесса. Поскольку проектирование состоит в разбиении программы на обозримые части, целесообразно использовать метод, заключающийся в определении и разделении выполняемых функций. Однако в этой связи возникает фундаментальный вопрос: что же такое наиболее абстрактное описание системы? Если спецификация написана правильно, то оно ясно определено; если же нет, то вопрос остается открытым и проектировщик вынужден строить дерево программы, не имея возможности найти вершину. 51

31 Однако никто не знает, как правильно выполнить разбиение задачи на подзадачи. Никто не знает, какое разбиение можно считать правильным. Возможно, самое правильное разбиение то, которое минимизирует время и стоимость реализации. Но время реализации сильно зависит от квалификации программистов, реализующих проект. Считаем нелишним привести соотношение производительности труда программистов. Впервые эта цифра появилась в исследованиях Сакмана. Он приводит, что производительность труда у разных программистов соотносится как 1 : 25. Такого соотношения производительности труда нет ни в одной отрасли. Это, безусловно, крайние цифры, но 1: 10 вы гарантировано встретите в собственной практике. Кроме того, программы, написанные более опытным программистом, чаще всего требуют меньше ресурсов (1 : 2) и работают быстрее (1 : 2), не говоря уже о том, что они содержат меньше ошибок вообще и не найденных в частности. (Сегодня нельзя утверждать соотношение 1 : 2, так как очень часто программы реализуются в таких средах программирования, где ресурсы сильно зависят от самой среды: Microsoft Visual, C++ и т. п.) Программы, написанные опытным программистом, легче читать, они яснее концептуально. Разбиение задачи на подзадачи сосредоточивает внимание на подзадачах или функциях, выполняемых в них. При этом происходит некоторое абстрагирование от интерфейса или взаимодействия функций (модулей) между собой. Можно основное внимание уделить именно интерфейсу, то есть методу связи между подсистемами или программами. Система, управляемая портом. Каждая подсистема рассматривается как асинхронный процесс. Если одна из подсистем передаёт данные другой, то она просто посылает сообщение в порт другой подсистемы/системы. Подсистема сама определяет, какое сообщение ей выбирать из порта. Отметим, что порт может быть и техническим устройством. Однако так описывали этот метод тридцать лет назад. С точки зрения современности, тут явно изложена идея системы, управляемой сообщениями. Сегодня мы все знаем несколько реализаций таких систем: Windows. С точки зрения технологии программирования, здесь несколько особенностей. Вопервых, существенно меняется структура программы главными становятся обработчики получаемых сообщений, а не модули, вызывающие эти обработчики. Во-вторых, поскольку поступление сообщений случайно, то обработчики любого сообщения могут быть вызваны в любой момент, что приводит к глобальному хранению сведений обо всех обработчиках (реестр). В-третьих, обработчики сообщений вызываются асинхронно, а следовательно, о синхронной обработке сообщений должен заботиться сам процесс, инициализируемый этими сообщениями. Кроме того, асинхронность неявно требует увеличения объёма используемых ресурсов, так как каждое сообщение может обрабатываться параллельно с любым другим. В-четвёртых, так как число сообщений постоянно растёт, а все они молчаливо предполагаются системными, то операционная система начинает неоправданно разбухать. Понятие «системный несистемный» начинает размываться. Очень важно: такие системы чрезвычайно трудно продумать и правильно спроектировать. 50 лучше программистов понимает, что нужно программистам). В-четвёртых, именно в этой области можно выделить этапы заказ, поставка как этапы жизненного цикла ПО. В-пятых, это область закрытого, читай лицензионного ПО, поскольку при открытом ПО этапы заказ, поставка, в общем-то, можно выделить чисто условно. Постановка необходима и для коробочных программных продуктов, и для программ, разрабатываемых программистами для программистов. Просто в этом случае постановка настолько сливается с разработкой в единое целое, что создаётся впечатление её отсутствия. Мы уже замечали выше, что фактически все этапы жизненного цикла осуществляются одновременно и нет чёткого выделения границ. Не так важно наличие этих границ. Важно понимание наличия и необходимости этапов технологии производства ПО, понимание того, что должно появиться в результате выполнения этапа. С точки зрения российских специалистов, далее начинается этап разработки или реализации. Выполняют его уже программисты. Нередко в группу разработки входят и постановщики, что позволяет быстрее реагировать на ошибки в постановке, выявленные при реализации проекта. Кроме того, снижается вероятность того, что программисты что-нибудь неправильно поймут в постановке. Со своей стороны постановщик знакомится с процессом разработки, что позволяет выполнять постановку с учётом процесса разработки. Результатом разработки должна быть работающая программа. С точки зрения американских специалистов, далее начинается процесс внутреннего проектирования, который выполняют программисты совместно со специалистами по проектированию. То есть специалисты США явно выделяют этап «проектирование системы», который предшествует разработке. В России этап проектирование при производстве ПО явно не выделяется. Во-первых, потому что часть проектирования это постановка, которая выполняется одним коллективом, а часть проектирования это уже разработка, которая выполняется другим коллективом. Во-вторых, объём и состав работ проектирования сильно зависят от величины проекта, в частности в малых проектах, проектирование, как таковое, отсутствует. Эти разночтения отражают факт, что любой реализации должен предшествовать этап планирования реализации. Чем больше трудоёмкость проекта, тем труднее выполнить правильное планирование реализации. Для нас важно, что в этапе планирование реализации должны участвовать программисты. Опять-таки в российских реалиях это планирование делают только программисты, откуда следует, что они должны уметь это делать. В американских реалиях процесс планирования выполняет, прежде всего, менеджер или специалист по планированию, что предполагает либо наличие соответствующих специалистов, либо знакомство менеджера с программированием. При проектировании реализации следует рассмотреть все внутренние функциональные и другие связи. Провести анализ форматов представления данных. Темпа обмена данными и последовательностью их появления. Попытаться проанализировать предполагаемые временные характеристики системы. Рассмотреть всю структуру ввода/вывода и согласовать по форматам. Рассмот- 47

32 реть всю структуру программы в целом для проверки распределения требований по компонентам, распределения памяти, последовательности вычислений и работой с базами данных. Основная цель: разбить задачу на подзадачи, систему на подсистемы, определить и утвердить интерфейс взаимодействия подсистем/подзадач. Разбиение целого на части преследует, прежде всего, цель уменьшения сложности. Интуитивно предполагается, что часть проще целого. Разбиение позволяет распределить объём работ между разными программистами, группами разработчиков, при этом время реализации уменьшается. В среднем можно сказать, что правильное разбиение задачи на две части уменьшает время разработки вдвое. Но в общем случае при разбиении задачи на N частей время не уменьшается в N раз, более того, возможны случаи увеличения времени разработки. Разбиение должно быть оптимальным: слишком крупное не уменьшит сложности задачи, а значит, и времени реализации; слишком мелкое потребует много времени на собственно разбиение, неоправданно может увеличить количество разработчиков и всегда резко увеличивает объём проектирования и отладки взаимодействия частей между собой или трудоёмкость отладки интерфейса. Кроме того, при большом числе частей задачи увеличивается объём общения между собой групп, реализующих эти части. Ни время, ни сложность этого общения обычно нигде не учитываются, но время реализации увеличивается. При излишнем разбиении на части теряется единство концептуальности и проект всё более напоминает ситуацию из басни И. А. Крылова Лебедь, рак и щука. Разбиение системы на подсистемы называется построением архитектуры системы. Разработка архитектуры это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы, подзадачи и уровни абстракции. Процесс разработки архитектуры шаг, необходимый при проектировании систем, но не обязательный при реализации малого проекта. Один из методов построения архитектуры системы уровни абстракции (более подробно см. Г. Майерс [15]). Концепция уровней абстракции была предложена Дейкстрой. Система разбивается на различные иерархически упорядоченные части, называемые уровнями, удовлетворяющие определённым проектировочным критериям. Каждый уровень является группой тесно связанных модулей. Идея уровней призвана минимизировать сложность системы за счёт такого их определения, которое обеспечивает высокую степень независимости уровней друг от друга. Это достигается благодаря тому, что свойства определённых объектов такой системы (ресурсы, представление данных и т. п.) упрятываются внутрь каждого уровня, что позволяет рассматривать его как «абстракцию» этих объектов. Строгого определения уровней абстракции нет. Чаще вместо определения уровней абстракции перечисляют их желаемые свойства, например: 1. На каждом уровне ничего не известно о внутреннем строении других уровней. Связь между ними осуществляется только через заранее определённые связи Предположения, которые на каждом уровне делаются относительно других уровней, должны быть минимальны. 3. Каждый уровень располагает определёнными ресурсами и либо скрывает их от других, либо предоставляет другим уровням некоторые их абстракции. 4. Каждый уровень должен иметь высокую прочность и слабое сцепление. Ещё раз повторим: «Идея уровней призвана минимизировать сложность системы за счёт такого их определения, которое обеспечивает высокую степень независимости уровней друг от друга». Плюсы и минусы подобного подхода. 1. Лёгкое внесение модификаций в систему. Ясно, что модификации ограничиваются изолированными частями системы. Кроме того, уровни абстракции чётко указывают, какие части подлежат изменению. 2. Следующим несомненным плюсом будет мобильность: простота изменений системы при переносе в другую операционную систему. 3. Несомненным плюсом является ясность системы: строение уровней часто определяет, какой уровень выполнить аппаратно, а какой программно. 4. Концепция позволяет выполнять параллельную и практически независимую разработку каждого уровня. Минусы: Это метод проектирования системы, а не метод разработки программы. Выполняется процесс разбиения на уровни либо проектировщиком системы (редко), либо руководителем коллектива программистов, которым предстоит реализация проекта. Непосредственное перенесение этой методологии в разработку программ приводит к некоторым проблемам. Например, часть констант системы начинает дублироваться на каждом уровне; нередко производится излишнее дробление системы на промежуточные уровни, а это, в свою очередь, замедляет функционирование системы. Если некоторому уровню потребуются услуги уровня, отстоящего от него через несколько других, то чаще всего приходится получать эту услугу через все промежуточные уровни. Сама концепция исходит из предположения, что нижним уровням никогда не потребуются услуги верхних, что неверно. Концепция достаточно идеальна: предположение о минимизации на уровне сведений о других уровнях, а ещё лучше, полное отсутствие знаний даже о наличии других уровней, практически невыполнимо. Обратите внимание, что само разбиение производится при полном знании структуры системы. Знатоки ООП (объектно-ориентированное программирование) обратят внимание на то, что концепция уровней абстракции сильно напоминает концепцию класса/объекта. У нас есть открытые и закрытые члены класса, членфункции класса. Класс взаимодействует с другими классами ограниченным набором функций (методов). Доступ к закрытым членам невозможен извне. Принципиально с классом можно работать, ничего не зная о его внутренней структуре (читай реализации) класса. Иерархия уровней иерархия классов. Чего нет в концепции уровней, так это наследования. 49

33 Традиционно первыми тремя уровнями занимаются языки программирования, а последними тремя базы данных. Это объясняет, почему под данными чаще всего понимаются только данные первых трёх уровней. Данные последних трёх уровней чаще называют информацией. Вопросы хранения данных в БД подробно рассматриваются в соответствующих курсах. Нам важно понять, что сохраняемость данных есть во времени: время жизни как простой переменной, так и сложного объекта; но есть и в пространстве. Ранее под пространством понималась оперативная память и память, располагаемая на внешних носителях. Появление сетей поставило проблемы сохранения данных при передаче их по сети. Если быть более точным, то любая схема клиент-сервер поднимает вопросы сохранения данных в пространстве, так как клиент и сервер, в общем случае, находятся в разных адресных пространствах, даже существуя на одной машине. Однако, прежде чем сохранять данные, их требуется описать. Алгоритмические языки, относительно необходимости описывать данные, можно разделить на три группы: языки с обязательным описанием данных (C++, Pascal, например); языки с частичным описанием данных (FORTRAN); языки, допускающие отсутствие описания данных (Basic). Не следует думать, что отсутствие в языке средств описания данных это плохо. Во многих очень серьёзных языках данные можно либо вовсе не описывать, либо не описывать частично, например такой язык, как АПЛ, не имеет средств явного описаний массивов, но великолепно динамически работает с массивами. Явное описание данных или декларация служит трём главным целям. 1. Более эффективное хранение структур данных и доступ к ним. Наиболее очевидная цель декларации состоит в том, чтобы указать свойства структур и данных, остающихся неизменными во время выполнения программы. Транслятор оптимальным образом размещает данные в памяти и генерирует соответствующие команды работы с данными. 2. Улучшение управления памятью. Именно декларация позволяет определить области видимости данных и время их существования. Декларация позволяет применять к управлению данными более простые алгоритмы. Если массив объявлен и имеет статическое распределение в памяти, то достаточно знать тип данных и границы массива. Если массив создаётся динамически и размеры его могут быть динамически изменены в ходе работы программы, то необходимо где-то хранить информацию о точках создания и уничтожения или перераспределения массива, кроме того, чаще всего добавляется информация от операционной среды о блоках памяти и т. п. 3. Статическая поверка типа. В языке программирования операция называется специфической, если тип её операндов и результата неизменен. Операция называется универсальной, если тип её операндов и результата может меняться. Ясно, что специфические операции выполняются значительно быстрее, так как не требуют слежения за типом данных. Структура команд машины вообще построена так, что в ней отсутствуют универсальные операции. В свою очередь, программист стремится как можно меньше контролировать типы данных, и просто необходимо ему позволить использовать универсальные операции Изменяется трудоёмкость автоматизированного процесса, а следовательно, должны быть пересмотрены нормативы и стоимости на заданные составы работ, да и сами составы работ. Внедрение программного обеспечения может не снизить, а увеличить трудоёмкость автоматизируемого процесса. Не следует забывать, что при внедрении автоматизированного бухучёта нигде не отказались от одновременного ведения ручной документации. 5. Автоматизированный документооборот в условиях России часто дороже ручного. Всё в соотношении заработной платы и стоимости вычислительной техники и расходных материалов. В России стоимость компьютера около 1000$ USA при средней заработной плате 200$ USA, но у низко оплачиваемых сотрудников ещё меньше. А в США при той же стоимости компьютера средняя заработная плата около 3000$. Отсюда видно, что в России выгоднее нанять низко оплачиваемого сотрудника, чем даже просто приобрести компьютер. С другой стороны, опять-таки набор накладных на складе на компьютере: понадобится сам компьютер, принтер и регулярная смена картриджей на принтере, что на порядок по стоимости превышает стоимость бланков накладных и шариковой ручки. Вообще, от внедрения компьютерных технологий ожидают экономической эффективности. Трезвое рассмотрение последствий внедрения программного обеспечения приводит нас к выводу, что часто ничего, кроме убытков, не получено. Пусть на крупном предприятии внедрена автоматизированная бухгалтерия. Нередко при этом штатное расписание самой бухгалтерии никто не урезает, то есть число сотрудников осталось таким же, каким было при ручной работе. Однако для поддержки ПО бухгалтерии создаётся группа программистов, отвечающих за работу бухгалтерского ПО. Теперь в накладные расходы войдёт стоимость амортизации ПО, компьютеров и компьютерной периферии, а также материалов, используемых при эксплуатации техники. Большое предприятие значит работа бухгалтерского ПО через серьёзный банк данных, а это отдельный сервер, группа администрирования БД, группа системных программистов, поддерживающих работу сети, группа электронщиков, поддерживающих работу техники. Список издержек можно продолжать. На малых предприятиях то же самое, но часто программист, поддерживающий ПО, отвечает за все перечисленные проблемы. Он и системный, и сетевой, и администратор БД, и электроник. Каким же образом компьютерная бухгалтерия вошла в жизнь, принося одни убытки? Ну, во-первых, наше законодательство разработано так, что вы не сможете работать в ручном режиме. Например, оно обязывает предприятия держать счёт в банке, а банк, в свою очередь, требует электронной проводки документации. Во-вторых, сроки получения многих документов уменьшились, хотя нередко увеличилось количество получаемых документов, компьютер ведь позволяет. В-третьих, не следует игнорировать желания администрации. При грамотной постановке вопроса администрация получает реальные возможности контроля рабочего процесса. Оперативная компьютерная реакция на неожиданную проблему может окупить издержки производства. Не следует забывать, структуры, обслуживающие бухгалтерию, используются и другими службами. 65

34 Поддержка внедрения и эксплуатации ПО администрацией предприятия чрезвычайно важна. Пользователь ведь уже исполняет свои обязанности, и ему совершенно не хочется обременять себя ещё и обучением работы с программой, параллельным выполнением обязанностей по эксплуатации программы и выполнением своих обычных обязанностей. Заставить пользователя перейти на использование ПО может только администрация предприятия. Заинтересованность администрации предприятия в эксплуатации ПО выражается в ряде административных мероприятий, таких как приказы, распоряжения, изменения в должностных обязанностях, введение новых должностей, сокращение ненужных должностей, перенаправление документальных потоков и т. д. Никто лучше администрации не сделает этого. Только администрация предприятия имеет право делать это. Вот почему за внедрение ПО должно отвечать лицо, обладающее властными полномочиями. Лучше всего, если это будет руководитель предприятия, но и его заместители могут поддержать внедрение ПО. Чем ниже ранг административной поддержки, тем уже область внедрения ПО. Если за внедрение ПО отвечает начальник отдела, то и внедрено ПО, скорее всего, будет только в этом отделе. Сотрудники других отделов подчиняются своим начальникам и будут игнорировать внедрение ПО, так как у них и так уже есть обязанности, которые надо эффективно исполнять. Отсюда видно, что даже обыкновенное использование программного обеспечения должно сопровождаться административными мероприятиями или технико-административными мероприятиями. Причём все эти мероприятия должны реально проводиться в жизнь и поддерживаться руководством. Вопросы к главе 3 1. Основное отличие технологии программирования от обычных технологий. 2. Причины отличия технологии программирования от обычных технологий. 3. Перечислите последствия внедрения программного обеспечения в производство. 4. Цели в работе программиста. 5. Распределение выявленных ошибок по технологическим фазам. 6. Какие действия необходимо предпринять при обнаружении ошибки? 7. Стоимость ликвидации ошибки? 8. Когда следует прекратить отладку? 9. Различия в программах опытного и начинающего программиста. 10. Приведите пример внедрения компьютера в производство. 11. Экономическая эффективность внедрения компьютера в производство. 6. ДАННЫЕ И СТРУКТУРЫ ДАННЫХ Любую программу можно рассмотреть как некий набор операций, который применяется к некоторым данным в некоторой последовательности. Во время выполнения программы существуют, условно, две группы данных: данные, определяемые программистом, и данные, определяемые системой. Данные, определяемые программистом, состоят из элементов, которые программист явно определяет в своей программе и которыми он манипулирует сам числа, массивы, файлы и т. п. Данные, определяемые системой, формируются средой функционирования программы и зависят как от языка реализации, так и от операционной системы и техники, на которой функционирует программа. Например, ЭВМ может иметь аппаратную реализацию виртуальных адресов, а может и не иметь, что, конечно, влияет на наличие служебных данных. Хотя программист и не определяет явно служебных данных, он обязан знать об их наличии и учитывать при программировании. Грамотный программист нередко может получать доступ к служебным данным и сам их менять или использовать. В своё время в DOS большинство грамотных программистов при работе с графикой пользовались непосредственным доступом к видеопамяти, а не стандартными средствами графики, это было на порядок быстрее. В Pascal возможны массивы с задаваемыми границами, а следовательно, где-то хранится информация с описанием массива и его границами, чего нет в C, где нет многомерных массивов и нет операций с массивами и т. д. Или: любой C-программист, только начав работать в C со строками, быстро разбирался, что в C нет операций с массивами, а следовательно, и со строками, и вообще в C строка это простая последовательность байт, ограниченная байтом 0x00. Обратите внимание на то, что программиста вынуждают знать внутреннее представление строк! Спросите любого Basicпрограммиста: Как представляется строка в Basic? В девяти случаев из десяти вы не получите правильного ответа. Важно понимать, что язык может способствовать ознакомлению программиста с внутренним представлением (C++) и, наоборот, всячески скрывать наличие служебных данных, препятствуя проникновению «программиста» «вовнутрь» (Basic). Данные, переменные, объекты существуют в памяти и живут во времени. Гради Буч [5], рассматривая сохраняемость данных/объектов, делит их на следующие группы: Промежуточные результаты вычислений выражений. Локальные переменные в вызове процедур. Собственные переменные: глобальные, локальные, динамически создаваемые. Данные, сохраняющиеся между сеансами выполнения программы. Данные сохраняемые при переходе на новую версию программы. Данные, которые вообще переживут программу

35 Вопросы к главе 5 1. Формы представления постановки. 2. Блок-схема программы. 3. Алгоритм. Что это такое? Привести пример. 4. Пять основных свойств алгоритма. 5. Продемонстрируйте на примерах свойства мощности, особенности и красоты алгоритма. 6. Влияние объёма данных на используемый алгоритм. 7. Сущность алгоритмизации. 8. Необходимые соглашения для реализации библиотеки стандартных программ. 9. Основные различия между программой и подпрограммой. 10. Достоинства разбиения программ на подпрограммы. 11. Глобальные переменные; достоинства и недостатки. 12. Общая используемая область памяти; достоинства и недостатки. 13. Процедурная абстракция: что это такое? 14. Схемы запуска других процессов. 15. Вызов подпрограмм: передача параметров. 16. Вызов в С++ программ с переменным числом параметров. 17. Передача в подпрограммы параметров с умалчиваемыми значениями. 18. Перегрузка функций. 19. Схема включения подпрограмм в программу. 20. Что такое препроцессор? Зачем он нужен? 21. Достоинства и недостатки схемы язык-ядро. 22. Достоинства и недостатки схемы язык-оболочка. 23. Что влияет на разбиение программы на модули? 24. Схемы компоновки программ. 25. Что такое реентерабельная программа? 26. Какие основные типы программ/подпрограмм вы знаете? 27. Почему на блок-схемах трудно отобразить данные? 28. Основные недостатки блок-схем. 4. КРАТКО ОБ УПРАВЛЕНИИ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Управление методикой разработки программного обеспечения только часть технологии программирования. Некоторые зарубежные источники только управление и включают в технологию программирования. Однако простое рассмотрение жизненного цикла программного обеспечения показывает, что это не так. Попытка управлять производством ПО как обычным техническим процессом не дала ожидаемого эффекта. Причина в том, что существенную часть производства ПО составляет неформальная творческая составляющая, неизвестно, как выбираемая программистом. Неформальный производящий элемент программист. Другие экономические характеристики процесса. Производимый продукт не является чисто техническим, но обладает другими существенными характеристиками, например программа математический объект, уникальный объект, авторский объект и т. д. Признание уникальности такого объекта, как программное обеспечение, приводит к мнению, что едва ли существует единая методика управления процессом производства ПО. Это действительно так. Используемая методика, если она выбрана правильно, зависит от величины проекта, величины фирмы разработчика, разрабатываемой задачи, опытности как управляющего персонала, так и коллектива разработчиков, и множества других более мелких факторов. Приверженцам любой методики управления всегда следует сначала понять, подойдёт ли эта методика при управлении заданным проектом, поскольку цель производства ПО программное обеспечение, а не управление этим производством. Никогда не следует забывать, что управление производством всегда ещё и управление коллективом и методика, используемая одной командой, может не прижиться в другой. Конечно, наличие любой методики лучше её отсутствия. Интуитивно ясно, что малую одиночную программку можно писать и без управления как такового, а многолетнюю разработку невозможно привести к конечному результату в отсутствии методики управления. С другой стороны, сторонники любых методик управления должны объяснить факт существования и успешного развития такой системы, как Linux. Существование открытых систем ПО показывает, насколько важным в производстве ПО является личность программиста. С другой стороны, существуют методики, игнорирующие уникальность программиста и рассматривающие его как в любой момент заменяемый элемент. Нельзя сказать, что истина лежит посередине, поскольку каждая методика используется в своей области. Любая крупная компания, выполняющая трудоёмкие проекты (от нескольких сотен человеко-лет), заинтересована в технологиях, не зависящих от конкретной личности, в таких компаниях ценят управленцев, а не исполнителей, читай разработчиков. Мелкая компания нередко целиком зависит от конкретных личностей и не может позволить себе не учитывать личность, здесь разработчика уважают не меньше, а иногда и более, чем управленца

36 Программистам следует помнить, что лучшие управляющие производством ПО вышли из программистов, поэтому им следует быть знакомыми с методиками управления проектами. Кроме того, это позволит программистам лучше понять управленцев, так как всякая методика определённый формализм, который предъявляет к программисту множество требований и, в любом случае, интенсифицирует его труд. Любая методика управления ходом проекта тесно связана с методикой проектирования, а программист обязан знать методики проектирования. Методы контроля реализации проекта появились давно, используются повсеместно и прежде всего там, где присутствует пара «менеджер исполнитель». Традиционно полагается, что менеджер не разбирается в том, чем он управляет, а исполнитель не умеет управлять, что, конечно же, далеко не так. Тем не менее все методики управления исходят из этого, хотя и предполагают оценку трудоёмкости работ менеджером (?). Одна из методик контроля хода проекта разработана Министерством обороны США в середине 60-х годов, то есть задолго до появления реальных потоков программного обеспечения. Пентагону требовалось контролировать ход выполнения работ компаниями-подрядчиками, причём отнюдь не в производстве ПО. Методика называется C/SCSC Cost/Schedule Control Systems Criteria. Методика предполагает получение некоторого количества измеримых характеристик процесса проектирования/разработки, и на их основе отслеживается ход выполнения работ. С. И. Бобровский [3]: простой пример контроля всего по двум характеристикам: сроки бюджет: Рис Оценка состояния проекта [3] 68 Вычислительные обычно характеризуются большим объёмом вычислений и незначительным объёмом ввода/вывода. В вычислительных задачах, как правило, используется достаточно серьёзная математика, и программисту, специализирующемуся на вычислительных задачах (методах), просто необходимы знания математики в объёмах, превышающих общеинженерные курсы математики. В асушных задачах относительно незначительные объёмы простых вычислений, но со значительным объёмом ввода/вывода. Основные используемые технологии работа с базами данных. В большинстве случаев это преобразование одного множества таблиц в другое множество таблиц с тем или иным объёмом ввода данных и вывода. Задачи почти всегда простые, но критичные ко времени выполнения. Системные: реализация модулей операционной системы, трансляторов, программ СУБД (системы управления базами данных), программы взаимодействия в сети и т. д. Как правило, требуются серьёзные знания вычислительной техники и особенностей её функционирования, а также операционных сред. Управляющие: программы, управляющие работой технических устройств или технологией протекания технических процессов. Почти всегда работают в режиме реального времени, чаще всего реализуются на Assemblere (в последнее время используется и C++). Высокие требования по надёжности функционирования. Смешанные: задачи, обладающие характеристиками нескольких ранее выделенных групп, например реализация серьёзной графической среды требует значительных объёмов непростых вычислений и значительного объёма операций по вводу/выводу. 2. Программист. Обычно при рассмотрении абстракций выполняется абстрагирование не только от данных, например, или действий, но и от самого программиста. С одной стороны, это понятно, поскольку строится некая формальная схема абстракции, где нет места такому глубоко неформальному элементу, как программист. Однако в техническом задании алгоритм решения может быть определён достаточно отвлечённо, сортировать данные, например, а конкретный выбор алгоритма переложен на плечи программиста. Не надо объяснять, что программисты бывают разные, и соответственно они по-разному сделают выбор алгоритма и разбиение задачи. Очень важно учитывать тип задачи и склонность программиста к решению именно этого типа задач. 3. Объём данных и соответственно выбираемый алгоритм. 4. Техническая и программная среда решения. Структура программы будет существенно разной в последовательной системе или в системе, управляемой событиями (Unix или Windows). Вы можете работать в многопроцессорной среде с параллельными вычислениями или в однопроцессорной системе; в сети, используемой только для передачи данных, или в существенно распределённой среде. Выбранный алгоритм может допускать параллельную обработку или нет. 5. Условия конфиденциальности. Обратите внимание, что формализованной частью в указанных феноменах будет только пункт 3 объём данных и алгоритм, и тот грешит неформальным определением алгоритма. 93

Лекция 31. Программное обеспечение САПР

Лекция 31. Программное обеспечение САПР Лекция 31 Программное обеспечение САПР Программное обеспечение САПР (ПО) представляет собой совокупность программ, необходимых для обработки исходной информации по проектным алгоритмам, управления вычислительным

Подробнее

Технология программирования

Технология программирования МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ УХТИНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Г.Н. Гатин Технология программирования (практический аспект) Учебное пособие Ухта 2004г. УДК 681.3.06 Г 23

Подробнее

Модуль 1. ОБЩИЕ СВЕДЕНИЯ ОБ ОПЕРАЦИОННЫХ СИСТЕМАХ, СРЕДАХ И ОБОЛОЧКАХ

Модуль 1. ОБЩИЕ СВЕДЕНИЯ ОБ ОПЕРАЦИОННЫХ СИСТЕМАХ, СРЕДАХ И ОБОЛОЧКАХ Модуль 1. ОБЩИЕ СВЕДЕНИЯ ОБ ОПЕРАЦИОННЫХ СИСТЕМАХ, СРЕДАХ И ОБОЛОЧКАХ 1. Операционная система это 1) комплекс управляющих и обрабатывающих программ 2) компоненты вычислительных машин и вычислительных систем

Подробнее

ИССЛЕДОВАТЕЛЬСКАЯ РАБОТА Архитектура ЭВМ. Принципы Джона фон Неймана

ИССЛЕДОВАТЕЛЬСКАЯ РАБОТА Архитектура ЭВМ. Принципы Джона фон Неймана ИССЛЕДОВАТЕЛЬСКАЯ РАБОТА Архитектура ЭВМ. Принципы Джона фон Неймана Архитектура ЭВМ включает в себя как структуру, отражающую состав ПК, так и программно математическое обеспечение. Структура ЭВМ - совокупность

Подробнее

Программное обеспечение. Программное обеспечение компьютера

Программное обеспечение. Программное обеспечение компьютера Программное обеспечение Программное обеспечение компьютера В 50-60-е годы когда компьютер еще назывался ЭВМ (электронно-вычислительная машина), он мог только вычислять. Процесс обработки информации состоял

Подробнее

МОДЕЛИ, РАЗРАБОТКА, РЕАЛИЗАЦИЯ

МОДЕЛИ, РАЗРАБОТКА, РЕАЛИЗАЦИЯ Т. Карпова МОДЕЛИ, РАЗРАБОТКА, РЕАЛИЗАЦИЯ Санкт-Петербург Москва Харьков Минск 2G01 ББК32.973.233-018я7 УДК 681.3.016 (075) К26 К26 Базы данных: модели, разработка, реализация / Т, С. Карпова. СПб.: Питер,

Подробнее

Этапы разработки базы данных

Этапы разработки базы данных Этапы разработки базы данных С базами данных, как правило, работают не профессионалы, поэтому можно сформулировать следующие требования к БД. Разработчики, при создании БД, должны ориентироваться на эти

Подробнее

Архитектура операционной системы. Лекция 8 Информатика

Архитектура операционной системы. Лекция 8 Информатика Архитектура операционной системы Лекция 8 Информатика Ядро и вспомогательные модули операционной системы При функциональной декомпозиции ОС модули разделяются на две группы: ядро модули, выполняющие основные

Подробнее

Лектор к.т.н., доцент Азарченков А.А.

Лектор к.т.н., доцент Азарченков А.А. Лектор к.т.н., доцент Азарченков А.А. Прикладное ПО Системное ПО Служебное ПО Базовое ПО Базовый уровень - программное обеспечение отвечает за взаимодействие с базовыми аппаратными средствами, которые

Подробнее

Внешние источники данных для создания сводной таблицы

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

Подробнее

Задание #1 Вопрос: К системным программам относятся: Выберите несколько из 7 вариантов ответа: 1) BIOS 2) MS Windows 3) MS Word 4) Paint 5) Linux 6)

Задание #1 Вопрос: К системным программам относятся: Выберите несколько из 7 вариантов ответа: 1) BIOS 2) MS Windows 3) MS Word 4) Paint 5) Linux 6) Задание #1 К системным программам относятся: Выберите несколько из 7 вариантов ответа: 1) BIOS 2) MS Windows 3) MS Word 4) Paint 5) Linux 6) Драйверы 7) Антивирусы Задание #2 Назначение операционной системы:

Подробнее

ПРОЕКТИРОВАНИЕ УЧЕБНОГО ПРОЦЕССА ПО КУРСУ «БАЗЫ ДАННЫХ»

ПРОЕКТИРОВАНИЕ УЧЕБНОГО ПРОЦЕССА ПО КУРСУ «БАЗЫ ДАННЫХ» ПРОЕКТИРОВАНИЕ УЧЕБНОГО ПРОЦЕССА ПО КУРСУ «БАЗЫ ДАННЫХ» В. М. Монахов, Д. А. Власов, М. В. Зюзгина Московский государственный открытый педагогический университет имени М. А. Шолохова Москва, Россия E-mail:

Подробнее

при ликвидации аварий и для устранения ошибок пользователей. Это повышает ценность такого специалиста и его конкурентноспособность на рынке труда.

при ликвидации аварий и для устранения ошибок пользователей. Это повышает ценность такого специалиста и его конкурентноспособность на рынке труда. «Офисное программирование», как инструмент подготовки математиковпрограммистов специальности «351500 - Математическое обеспечение и администрирование информационных систем» Алексеев А.Ю., доцент, к.т.н.,

Подробнее

РАЗВИТИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА

РАЗВИТИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА УДК 004:657 РАЗВИТИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА А. А. Ляхманова, студентка III курса направления «Экономика» Саранского кооперативного института (филиала) автономной

Подробнее

Модуль 5. ВВОД-ВЫВОД И ФАЙЛОВАЯ СИСТЕМА

Модуль 5. ВВОД-ВЫВОД И ФАЙЛОВАЯ СИСТЕМА Модуль 5. ВВОД-ВЫВОД И ФАЙЛОВАЯ СИСТЕМА 1. Файл это (несколько ответов) 1) множество данных, объединенных некоторой логической связью 2) совокупность информации, записанная под индивидуальным именем на

Подробнее

Автор Яковлев Роман Николаевич РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ПРАКТИКИ. «ПМ.04 Выполнение работ по профессии "Наладчик технологического оборудования"»

Автор Яковлев Роман Николаевич РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ПРАКТИКИ. «ПМ.04 Выполнение работ по профессии Наладчик технологического оборудования» МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ УЧЕБНО-НАУЧНО-

Подробнее

Лабораторная работа 3 Архитектуры с фиксированным набором устройств

Лабораторная работа 3 Архитектуры с фиксированным набором устройств Лабораторная работа 3 Архитектуры с фиксированным набором устройств Тема программы: Архитектура ЭВМ. Архитектуры с фиксированным набором устройств Цель работы: получить представление об архитектуре с фиксированным

Подробнее

MICROSOFT ACCESS: СВЯЗИ, ВЫЧИСЛЯЕМЫЕ ПОЛЯ, СОЗДАНИЕ КНОПОЧНОЙ ФОРМЫ БД

MICROSOFT ACCESS: СВЯЗИ, ВЫЧИСЛЯЕМЫЕ ПОЛЯ, СОЗДАНИЕ КНОПОЧНОЙ ФОРМЫ БД MICROSOFT ACCESS: СВЯЗИ, ВЫЧИСЛЯЕМЫЕ ПОЛЯ, СОЗДАНИЕ КНОПОЧНОЙ ФОРМЫ БД I. СВЯЗИ ТАБЛИЦ Современные базы данных обычно состоят из многих таблиц, связанных между собой. Одной из целей создания хорошей структуры

Подробнее

Современное программирование на Java

Современное программирование на Java В. В. Кузнецов Современное программирование на Java Учебное пособие Томск 2014 УДК 044.43(075) ББК 32.973.26-018.1 Кузнецов B. В. Современное программирование на Java : Учеб. пособие / В. В. Кузнецов.

Подробнее

Областное государственное бюджетное образовательное учреждение среднего профессионального образования «Иркутский авиационный техникум»

Областное государственное бюджетное образовательное учреждение среднего профессионального образования «Иркутский авиационный техникум» Областное государственное бюджетное образовательное учреждение среднего профессионального образования «Иркутский авиационный техникум» УТВЕРЖДАЮ Директор ОГБОУ СПО «ИАТ» В.Г. Семенов Комплект методический

Подробнее

4. В каком году и где была создана первая ЭВМ на основе электронных ламп? 1) 1945 год, США 2) 1950, СССР 3) 1944 г, Англия 4) 1946 г, Франция

4. В каком году и где была создана первая ЭВМ на основе электронных ламп? 1) 1945 год, США 2) 1950, СССР 3) 1944 г, Англия 4) 1946 г, Франция Итоговая контрольная работа по информатике и информационным технологиям в 7 классе по учебнику Н. Угриновича История развития вычислительной техники: 1. Назовите первое вычислительное устройство. 1) Абак

Подробнее

С самого начала развития вычислительной техники образовались два основных направления ее использования: первое направление применение вычислительной

С самого начала развития вычислительной техники образовались два основных направления ее использования: первое направление применение вычислительной С самого начала развития вычислительной техники образовались два основных направления ее использования: первое направление применение вычислительной техники для выполнения численных расчетов, которые слишком

Подробнее

БАЗЫ ДАННЫХ (БД). СИСТЕМЫ УПРАВЛЕНИЯ БД

БАЗЫ ДАННЫХ (БД). СИСТЕМЫ УПРАВЛЕНИЯ БД БАЗЫ ДАННЫХ (БД). СИСТЕМЫ УПРАВЛЕНИЯ БД Общие положения Цель любой информационной системы - обработка данных об объектах реального мира. В широком смысле слова база данных - это совокупность сведений о

Подробнее

1.1 История ОС пакетной обработки Многозадачность Спулинг Системы разделения времени UNIX. POSIX. CP/M. MS-DOS

1.1 История ОС пакетной обработки Многозадачность Спулинг Системы разделения времени UNIX. POSIX. CP/M. MS-DOS 1.1 История ОС Первые (1945-1955г.г.) компьютеры работали без операционных систем, как правило, на них работала одна программа. Когда скорость выполнения программ и их количество стало увеличиваться, простои

Подробнее

ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)»

ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)» ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)» Курс Экзамен Форма проведения экзамена 2 курс 3 курс 4 курс 5 курс Комплексный

Подробнее

Языки программирование. Лектор Азарченков А.А.

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

Подробнее

Лекция 1 Эволюция устройств внешней памяти и программных систем управления данными

Лекция 1 Эволюция устройств внешней памяти и программных систем управления данными Лекция 1 Эволюция устройств внешней памяти и программных систем управления данными Лекция 1. Эволюция устройств внешней памяти и программных систем управления данными В этой вводной лекции мы, прежде всего,

Подробнее

Содержание программы. Информация и информационнные технологии Сигналы; кодирование и квантование сигналов. Системы счисления Логические основы ЭВМ

Содержание программы. Информация и информационнные технологии Сигналы; кодирование и квантование сигналов. Системы счисления Логические основы ЭВМ Содержание программы 1. Понятие информации. Общая характеристика процессов сбора, передачи, обработки и накопления информации Информатика. Предмет информатики. Основные задачи информатики Понятие информации,

Подробнее

Знакомство с программой Access. Основные цели изучения Access 2007:

Знакомство с программой Access. Основные цели изучения Access 2007: Знакомство с программой Access Access это приложение для работы с базами данных или система управления базами данных (СУБД). Компьютерные базы данных используются почти во всех областях деятельности. Умение

Подробнее

Системы управления базами данных (СУБД)

Системы управления базами данных (СУБД) Системы управления базами данных (СУБД) 1. Общие сведения о СУБД 2. Модели данных 3. СУБД Microsoft Access 1. Общие сведения о системах управления базами данных Два основных направления использования компьютеров:

Подробнее

1 Пензенский Государственный Университет. Факультет вычислительной техники. Кафедра «Системы автоматизации проектирования» ОПЕРАЦИОННЫЕ СИСТЕМЫ

1 Пензенский Государственный Университет. Факультет вычислительной техники. Кафедра «Системы автоматизации проектирования» ОПЕРАЦИОННЫЕ СИСТЕМЫ 1 Пензенский Государственный Университет Факультет вычислительной техники Кафедра «Системы автоматизации проектирования» «Утверждаю» Декан ФВТ, профессор Шашков Б.Д. 2002г. ОПЕРАЦИОННЫЕ СИСТЕМЫ Рабочая

Подробнее

ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 22 Организация доступа к данным по сети

ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 22 Организация доступа к данным по сети ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 22 Организация доступа к данным по сети 1. Классификация сетей по принципу передачи данных и по типу коммуникационной среды, по способу доступа к данным

Подробнее

Глава 1 Знакомство с платформой 1С:Предприятие 8.3

Глава 1 Знакомство с платформой 1С:Предприятие 8.3 Глава 1 Знакомство с платформой 1С:Предприятие 8.3 Учитывая большую популярность программного продукта 1С:Предприятие 8, практически повсеместно растет потребность в специалистах, знакомых с этой информационной

Подробнее

Б. Взаимодействие Л. Романов, Д. объектов Я. Слободецкий в объектно-ориентированной среде выполнения

Б. Взаимодействие Л. Романов, Д. объектов Я. Слободецкий в объектно-ориентированной среде выполнения Труды ИСА РАН 2009. Т. 45 Взаимодействие объектов в объектно-ориентированной среде выполнения Б. Взаимодействие Л. Романов, Д. объектов Я. Слободецкий в объектно-ориентированной среде выполнения Б. Л.

Подробнее

РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ

РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ ПЕРВОЕ ВЫСШЕЕ ТЕХНИЧЕСКОЕ УЧЕБНОЕ ЗАВЕДЕНИЕ РОССИИ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

Подробнее

ОГЛАВЛЕНИЕ. Предисловие... 3

ОГЛАВЛЕНИЕ. Предисловие... 3 ОГЛАВЛЕНИЕ Предисловие..................................... 3 Глава 1. Понятие информации. Общая характеристика процессов сбора, передачи, обработки и накопления информации 1.1. Основные задачи информатики......................

Подробнее

Таблица 1. Содержание разделов дисциплины Наименование Содержание раздела Форма текущего контроля

Таблица 1. Содержание разделов дисциплины Наименование Содержание раздела Форма текущего контроля Методические рекомендации по организации аудиторной работы по дисциплине «Принципы и методы организации системных программных средств» предназначены для студентов второго и третьего курсов, обучающихся

Подробнее

➀ Информационные системы и банки данных.

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

Подробнее

Алгоритмические языки и алгоритмизация

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

Подробнее

Понятия «процесс» и «поток»

Понятия «процесс» и «поток» Процессы и потоки Понятия «процесс» и «поток» Процесс (задача) - программа, находящаяся в режиме выполнения. Потоќ выполне ния (thread нить) наименьшая часть программы, исполнение которой может быть назначено

Подробнее

Основы объектно-ориентированного программирования в Delphi

Основы объектно-ориентированного программирования в Delphi В. В. Кузнецов, И. В. Абдрашитова Основы объектно-ориентированного программирования в Delphi Учебное пособие Под общей редакцией Т. Б. Корнеевой Одобрено Российской академией образования Допущено Департаментом

Подробнее

ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 19 Общие принципы построения сетей

ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 19 Общие принципы построения сетей ТЕХНОЛОГИИ ФИЗИЧЕСКОГО УРОВНЯ ПЕРЕДАЧИ ДАННЫХ Занятие 19 Общие принципы построения сетей 1. Связь компьютера с периферийными устройствами 2. Простейший случай взаимодействия двух компьютеров 3. Сетевые

Подробнее

1. Пояснительная записка

1. Пояснительная записка 2 1. Пояснительная записка Курс «Операционные системы, среды и оболочки» является общепрофессиональной дисциплиной и относится к базовым курсам специальности, т.к. дает основные знания и навыки работы

Подробнее

1.1. Встречайте: Windows 8!

1.1. Встречайте: Windows 8! 14 Глава 1. Знакомство c Windows 8 1.1. Встречайте: Windows 8! Windows 8 это поистине революционная операционная система от Microsoft, никогда еще изменения в системе не были столь значительными. При первом

Подробнее

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ КИБЕРНЕТИКИ, ИНФОРМАТИКИ И СВЯЗИ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ КИБЕРНЕТИКИ, ИНФОРМАТИКИ И СВЯЗИ ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ КИБЕРНЕТИКИ, ИНФОРМАТИКИ

Подробнее

ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНЫЕ, УПРАВЛЯЮЩИЕ И СЕТЕВЫЕ СИСТЕМЫ

ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНЫЕ, УПРАВЛЯЮЩИЕ И СЕТЕВЫЕ СИСТЕМЫ ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНЫЕ, УПРАВЛЯЮЩИЕ И СЕТЕВЫЕ СИСТЕМЫ УДК 519.6 РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ СИСТЕМЫ «УНИВЕРСАЛЬНЫЙ СПРАВОЧНИК ДЛЯ НЕФИНАНСОВЫХ ЗАДАЧ» М. В. Майорова, И. Е. Воронина

Подробнее

1. Планируемые результаты освоения учебного предмета

1. Планируемые результаты освоения учебного предмета 1. Планируемые результаты освоения учебного предмета В результате изучения информатики и информационно-коммуникационных технологий учащиеся должны знать/понимать: связь между информацией и знаниями человека;

Подробнее

СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 2. СТРУКТУРА И СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ 5

СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 2. СТРУКТУРА И СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ 5 2 3 СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ стр. 4 2. СТРУКТУРА И СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ 5 3. УСЛОВИЯ РЕАЛИЗАЦИИ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 4. КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ

Подробнее

Практические занятия Лабораторные работы Самостоятельная работа

Практические занятия Лабораторные работы Самостоятельная работа ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА МТ РФ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ГРАЖДАНСКОЙ АВИАЦИИ Утверждаю Проректор по УМР В. В. Криницин 2005 г. Рабочая программа дисциплины БАЗЫ

Подробнее

Версия 1С:Предприятие это принципиальное изменение архитектуры платформы версии 8, наиболее существенное с момента ее выпуска.

Версия 1С:Предприятие это принципиальное изменение архитектуры платформы версии 8, наиболее существенное с момента ее выпуска. Версия 1С:Предприятие 8.2 - это принципиальное изменение архитектуры платформы версии 8, наиболее существенное с момента ее выпуска. 1С:Предприятие 8.2 полностью меняет весь слой работы с интерфейсом.

Подробнее

Дисциплина «Проектирование баз данных» 3 курс 6 семестр

Дисциплина «Проектирование баз данных» 3 курс 6 семестр Дисциплина «Проектирование баз данных» 3 курс 6 семестр Требования к оформлению контрольной работы Контрольная работа оформляется на листах формата А4 с одной стороны. Все листы обязательно нумеруются.

Подробнее

ГЛАВА 3. МОДЕЛИ ДАННЫХ СУБД КАК ИНСТРУМЕНТ ПРЕДСТАВЛЕНИЯ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ

ГЛАВА 3. МОДЕЛИ ДАННЫХ СУБД КАК ИНСТРУМЕНТ ПРЕДСТАВЛЕНИЯ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ГЛАВА 3. МОДЕЛИ ДАННЫХ СУБД КАК ИНСТРУМЕНТ ПРЕДСТАВЛЕНИЯ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ В соответствии с основными этапами проектирования базы данных после построения концептуальной модели выбирается система управления

Подробнее

РАБОЧАЯ ПРОГРАММА дисциплины

РАБОЧАЯ ПРОГРАММА дисциплины МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ

Подробнее

Шины и прерывания. Маркова В.П., Остапкевич М.Б., Перепелкин В.А.

Шины и прерывания. Маркова В.П., Остапкевич М.Б., Перепелкин В.А. Шины и прерывания Маркова В.П., Остапкевич М.Б., Перепелкин В.А. 2016 Шина это коммуникационное аппаратное обеспечение представляющее собой набор проводников несущих двоичные сигналы Функции шин Синхронизация

Подробнее

РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ

РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У «Б е л Г У» ) ФАКУЛЬТЕТ

Подробнее

ОПЕРАЦИОННЫЕ СИСТЕМЫ И СРЕДЫ, ФАЙЛОВАЯ СИСТЕМА, ПРОГРАММЫ-ОБОЛОЧКИ

ОПЕРАЦИОННЫЕ СИСТЕМЫ И СРЕДЫ, ФАЙЛОВАЯ СИСТЕМА, ПРОГРАММЫ-ОБОЛОЧКИ ОПЕРАЦИОННЫЕ СИСТЕМЫ И СРЕДЫ, ФАЙЛОВАЯ СИСТЕМА, ПРОГРАММЫ-ОБОЛОЧКИ ОПЕРАЦИОННЫЕ СИСТЕМЫ Cреди десятков тысяч системных программ особое место занимают операционные системы, которые обеспечивают управление

Подробнее

2. Место данной дисциплины в учебном процессе: Дисциплина относится к общим математическим и естественнонаучным дисциплинам.

2. Место данной дисциплины в учебном процессе: Дисциплина относится к общим математическим и естественнонаучным дисциплинам. 1. Цели и задачи дисциплины: Цель изучения: Дать необходимые знания по формированию основ для использования современных средств вычислительной техники и пакетов прикладных программ в своей дальнейшей деятельности.

Подробнее

Лекция 1 ВВЕДЕНИЕ В БАЗЫ ДАННЫХ

Лекция 1 ВВЕДЕНИЕ В БАЗЫ ДАННЫХ Специальность 050501.65 «Профессиональное обучение» Учебная дисциплина «Базы данных и управление ими» Лекция 1 ВВЕДЕНИЕ В БАЗЫ ДАННЫХ 1 Основные понятия, используемые в базах данных. Структуризация и представление

Подробнее

Перечень экзаменационных вопросов по дисциплинам специальности 6М «Информационные системы» для поступающих в магистратуру

Перечень экзаменационных вопросов по дисциплинам специальности 6М «Информационные системы» для поступающих в магистратуру Перечень экзаменационных вопросов по дисциплинам специальности 6М070300 - «Информационные системы» для поступающих в магистратуру Вопросы к разделу «СУБД» 1. Дать определение понятия «предметная область».

Подробнее

Информационная технология

Информационная технология Информатика Аппаратное обеспечение информационных технологий Средства информационных технологий Информационная технология Алгоритмические средства (brainware) Аппаратные средства (hardware) Программные

Подробнее

Примерные вопросы теста к экзамену по дисциплине «Основы компьютерных информационных технологий»

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

Подробнее

33. Общее понятие о базах данных. Основные понятия систем управления базами данных. Объекты. Автор: Александр :32

33. Общее понятие о базах данных. Основные понятия систем управления базами данных. Объекты. Автор: Александр :32 База данных это организованная структура, предназначенная для хранения информации. В современных базах данных хранятся не только данные, но и информация. Это определение легко пояснить, если, например,

Подробнее

Вопросы к итоговому мероприятию по дисциплине «Программно-технические средства АБИС»

Вопросы к итоговому мероприятию по дисциплине «Программно-технические средства АБИС» Вопросы к итоговому мероприятию по дисциплине «Программно-технические средства АБИС» 1. Дайте определение понятию «Информационная система». 2. Какими свойствами обладает информационная система? 3. Для

Подробнее

Операционные системы и оболочки

Операционные системы и оболочки Министерство образования и науки Российской Федерации ФГБОУ ВО «Тверской государственный университет» Рабочая программа дисциплины (с аннотацией) Операционные системы и оболочки Направление подготовки

Подробнее

АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ

АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ 1 2 АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ основной профессиональной образовательной программы среднего профессионального образования базового подготовки по специальности среднего профессионального

Подробнее

Системы управления базами данных Microsoft Access 2003

Системы управления базами данных Microsoft Access 2003 Системы управления базами данных Microsoft Access 2003 Приложение Microsoft Access это настольная система управления реляционными базами данных (СУБД), предназначенная для работы на автономном персональном

Подробнее

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ. Б.2.Б.5 Информатика и программирование

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ. Б.2.Б.5 Информатика и программирование АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ Б.2.Б.5 Информатика и программирование Семестр: 2,3 Количество часов: 396 Количество зачетных единиц: 11 Промежуточная аттестация: экзамен Место дисциплины

Подробнее

30 Укажите максимальное количество корневых каталогов на жёстком диске? 31 Что находится на самом низком уровне иерархической структуры ПО?

30 Укажите максимальное количество корневых каталогов на жёстком диске? 31 Что находится на самом низком уровне иерархической структуры ПО? Метаданные теста Автор теста: Исамбаева Гульнар Маметовна Название курса: Операционные системы Название теста: Вопросы типа «выбор» по дисциплине «Операционные системы» Предназначено для студентов специальности:

Подробнее

Операционные системы. Устройства и программное обеспечение ввода-вывода

Операционные системы. Устройства и программное обеспечение ввода-вывода Операционные системы Лекция 9 Устройства и программное обеспечение ввода-вывода 9.1 Принципы аппаратуры ввода-вывода 9.1.1 Устройства ввода-вывода Устройства делят на две категории (некоторые не попадают

Подробнее

БАЗЫ ДАННЫХ часть II. Параллельные архитектуры баз данных

БАЗЫ ДАННЫХ часть II. Параллельные архитектуры баз данных БАЗЫ ДАННЫХ часть II Параллельные архитектуры баз данных Основные параллельные архитектуры Фактически определились три архитектурных направления: 1. Симметричные многопроцессорные системы (SMP) - наиболее

Подробнее

Программирование в. Приборостроении Биотехнических системах

Программирование в. Приборостроении Биотехнических системах Программирование в. Приборостроении Биотехнических системах 1 Управление в сфере производства, на транспорте, в сфере обслуживания, медицине и др. областях сегодня перешло на новый уровень вместо жесткого

Подробнее

Концепции системы 1С:Предприятия. Программная часть, Информационная база и Конфигурация

Концепции системы 1С:Предприятия. Программная часть, Информационная база и Конфигурация В современных условиях при автоматизации предприятий приходится сталкиваться с различными и часто диаметрально противоположными требованиями к учету одних и тех же разделов учета. Согласно документации

Подробнее

Методические рекомендации для самостоятельной работы обучающихся по дисциплине. Информатика

Методические рекомендации для самостоятельной работы обучающихся по дисциплине. Информатика ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ» Методические рекомендации для самостоятельной работы обучающихся

Подробнее

Дорабатывать открытый код самостоятельно или использовать решение российского вендора?

Дорабатывать открытый код самостоятельно или использовать решение российского вендора? Дорабатывать открытый код самостоятельно или использовать решение российского вендора? Почему Р-Виртуализация лучше открытого KVM и как это вам поможет На первый взгляд решения, построенные целиком на

Подробнее

ПРОГРАММИРОВАНИЕ ВИРТУАЛЬНЫХ АРХИТЕКТУР И ОРГАНИЗАЦИЯ СТРУКТУРНО- ПРОЦЕДУРНЫХ ВЫЧИСЛЕНИЙ В МНОГОПРОЦЕССОРНЫХ СИСТЕМАХ С МАССОВЫМ ПАРАЛЛЕЛИЗМОМ 1

ПРОГРАММИРОВАНИЕ ВИРТУАЛЬНЫХ АРХИТЕКТУР И ОРГАНИЗАЦИЯ СТРУКТУРНО- ПРОЦЕДУРНЫХ ВЫЧИСЛЕНИЙ В МНОГОПРОЦЕССОРНЫХ СИСТЕМАХ С МАССОВЫМ ПАРАЛЛЕЛИЗМОМ 1 Каляев А.В. ПРОГРАММИРОВАНИЕ ВИРТУАЛЬНЫХ АРХИТЕКТУР И ОРГАНИЗАЦИЯ СТРУКТУРНО- ПРОЦЕДУРНЫХ ВЫЧИСЛЕНИЙ В МНОГОПРОЦЕССОРНЫХ СИСТЕМАХ С МАССОВЫМ ПАРАЛЛЕЛИЗМОМ 1 Аннотация НИИ многопроцессорных вычислительных

Подробнее

УЧЕБНЫЙ ПЛАН Программы профессиональной переподготовки "Разработка системного программного обеспечения"

УЧЕБНЫЙ ПЛАН Программы профессиональной переподготовки Разработка системного программного обеспечения УЧЕБНЫЙ ПЛАН Программы профессиональной переподготовки "Разработка системного программного обеспечения" Цель обучения: Получение необходимых знаний и практических навыков для выполнения задач разработки

Подробнее

Ââåäåíèå. Для кого эта книга. Как организована книга

Ââåäåíèå. Для кого эта книга. Как организована книга Ââåäåíèå Книга Автоматизация Microsoft Access с помощью VBA поможет вам усовершенствовать навыки, приобретенные при работе с Access, и применять их на принципиально новом уровне --- вы научитесь использовать

Подробнее

1. ЦЕЛИ И ЗАДАЧИ ДИСЦИПЛИНЫ, ЕЕ МЕСТО В УЧЕБНОМ ПРОЦЕССЕ. 1.1 Цель преподавания дисциплины

1. ЦЕЛИ И ЗАДАЧИ ДИСЦИПЛИНЫ, ЕЕ МЕСТО В УЧЕБНОМ ПРОЦЕССЕ. 1.1 Цель преподавания дисциплины 1 1. ЦЕЛИ И ЗАДАЧИ ДИСЦИПЛИНЫ, ЕЕ МЕСТО В УЧЕБНОМ ПРОЦЕССЕ 1.1 Цель преподавания дисциплины Цель изучения: ознакомить студентов с основными методами и инструментальными средствами обработки информации

Подробнее

Конфигурация Переводчик Редакция 2.0 Руководство пользователя

Конфигурация Переводчик Редакция 2.0 Руководство пользователя Конфигурация Переводчик Редакция 2.0 Руководство пользователя Назначение конфигурации Продукт «1С:Переводчик» предназначен для упрощения перевода конфигураций и документации на другие языки, включая тексты

Подробнее

Место дисциплины в структуре образовательной программы

Место дисциплины в структуре образовательной программы Место дисциплины в структуре образовательной программы Дисциплина Операционные системы является обязательной дисциплиной вариативной части ОПОП по направлению подготовки 09.03.02 Информационные системы

Подробнее

ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÒÅÕÍÎËÎÃÈÈ Â ÁÅÇÎÏÀÑÍÎÑÒÈ ÆÈÇÍÅÄÅßÒÅËÜÍÎÑÒÈ

ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÒÅÕÍÎËÎÃÈÈ Â ÁÅÇÎÏÀÑÍÎÑÒÈ ÆÈÇÍÅÄÅßÒÅËÜÍÎÑÒÈ ДЛЯ ВУЗОВ Ý.Ì. Ñîêîëîâ, Â.Ì. Ïàíàðèí, Í.Â. Âîðîíöîâà ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÒÅÕÍÎËÎÃÈÈ Â ÁÅÇÎÏÀÑÍÎÑÒÈ ÆÈÇÍÅÄÅßÒÅËÜÍÎÑÒÈ Äîïóùåíî ÓÌÎ ïî óíèâåðñèòåòñêîìó ïîëèòåõíè åñêîìó îáðàçîâàíèþ â êà åñòâå ó åáíèêà äëÿ ñòóäåíòîâ

Подробнее

Система Управления Базой Данных СУБД Microsoft ACCESS

Система Управления Базой Данных СУБД Microsoft ACCESS ACCESS Система Управления Базой Данных СУБД Microsoft ACCESS Основные вопросы лекции: 1. Базы данных. Основные понятия, классификация 2. СУБД Microsoft ACCESS. Общая характеристика возможностей. Основные

Подробнее

Лекция 29. Характеристика и состав технических средств САПР

Лекция 29. Характеристика и состав технических средств САПР Лекция 29 Характеристика и состав технических средств САПР Необходимым условием всякой автоматизации является наличие соответствующих технических средств. По функциональному назначению средства, составляющие

Подробнее

Аннотации к лекциям Создание ОС Windows. Структура ОС Windows Разработка Win32 приложений. Инструментальные средства изучения системы

Аннотации к лекциям Создание ОС Windows. Структура ОС Windows Разработка Win32 приложений. Инструментальные средства изучения системы Аннотации к лекциям К. Коньков Основы организации операционных систем Microsoft Windows Целью настоящего курса практических занятий является иллюстрация основных положений лекционного курса "Основы операционных

Подробнее

3. К основным функциям CУБД не относится A. определение данных *B. хранение данных C. обработка данных D. управление данными

3. К основным функциям CУБД не относится A. определение данных *B. хранение данных C. обработка данных D. управление данными @БД, CУБД 1. Структура данных, для которой характерна подчиненность объектов нижнего уровня объектам верхнего уровня, называется A. табличной B. реляционной *C. иерархической D. сетевой 2. Отличительная

Подробнее

ЛЕКЦИЯ 9. РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ

ЛЕКЦИЯ 9. РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ ЛЕКЦИЯ 9. РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ 1) Пакетный режим автоматизированной обработки информации 2) Диалоговый режим автоматизированной обработки информации 3) Сетевой режим автоматизированной обработки

Подробнее

Предисловие. Структура данного пособия

Предисловие. Структура данного пособия Предисловие Современная вычислительная система (ВС) состоит из одного или нескольких процессоров, оперативной памяти (ОП) и большого числа разнообразных устройств ввода-вывода (УВВ) дисков, клавиатуры,

Подробнее

Архитектура современных микропроцессоров и мультипроцессоров. Лекция 3

Архитектура современных микропроцессоров и мультипроцессоров. Лекция 3 Архитектура современных микропроцессоров и мультипроцессоров Лекция 3 Вопросы по предыдущей лекции 1. Какова связь между вычислительной моделью, архитектурой и языком программирования? 2. В чём отличие

Подробнее

Внедрение инфраструктуры открытых ключей (PKI) ВОПРОС ОТВЕТ

Внедрение инфраструктуры открытых ключей (PKI) ВОПРОС ОТВЕТ ВОПРОС ОТВЕТ Внедрение инфраструктуры открытых ключей (PKI) Как осуществляется внедрение инфраструктуры открытых ключей (PKI) и какие вопросы нужно решать организации в процессе внедрения и эксплуатации

Подробнее

МИНОБРНАУКИ РОССИИ ФИЛИАЛ ФБГОУ ВПО «ВЛАДИВОСТОКСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ЭКОНОМИКИ И СЕРВИСА» В Г. НАХОДКЕ

МИНОБРНАУКИ РОССИИ ФИЛИАЛ ФБГОУ ВПО «ВЛАДИВОСТОКСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ЭКОНОМИКИ И СЕРВИСА» В Г. НАХОДКЕ МИНОБРНАУКИ РОССИИ ФИЛИАЛ ФБГОУ ВПО «ВЛАДИВОСТОКСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ЭКОНОМИКИ И СЕРВИСА» В Г. НАХОДКЕ Р А Б О Ч А Я П Р О Г Р А М М А По учебной дисциплине Информатика Специальность/направление

Подробнее

Рабочая программа дисциплины «Технологии программирования»

Рабочая программа дисциплины «Технологии программирования» Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" Факультет информационных технологий

Подробнее

Лекция 3 Тема: Классификация информационных систем.

Лекция 3 Тема: Классификация информационных систем. Лекция 3 Тема: Классификация информационных систем. План 1. Разделение информационных систем по техническому уровню 2. Разделение информационных систем по характеру обрабатываемой информации Ключевые слова

Подробнее

Операционная система. Программное обеспечение

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

Подробнее

База нормативной документации: Средства вычислительной техники ЗАЩИТА ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ИНФОРМАЦИИ

База нормативной документации:  Средства вычислительной техники ЗАЩИТА ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ИНФОРМАЦИИ ГОСТ Р 50739-95 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Средства вычислительной техники ЗАЩИТА ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ИНФОРМАЦИИ Общие технические требования ГОССТАНДАРТ РОССИИ Москва

Подробнее

Рабочая программа по информатике и ИКТ для 9 класса. 9 класс Общее число часов 63 ч. Резерв учебного времени 5 ч

Рабочая программа по информатике и ИКТ для 9 класса. 9 класс Общее число часов 63 ч. Резерв учебного времени 5 ч 1 Рабочая программа по информатике и ИКТ для 9 класса Содержание программы согласовано с содержанием Примерной программы основного общего образования по информатике и ИКТ, рекомендованной Министерством

Подробнее

СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 2. СТРУКТУРА И ПРИМЕРНОЕ СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ

СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 2. СТРУКТУРА И ПРИМЕРНОЕ СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ 2 3 СОДЕРЖАНИЕ 1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 2. СТРУКТУРА И ПРИМЕРНОЕ СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ 3. УСЛОВИЯ РЕАЛИЗАЦИИ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ 4. КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ

Подробнее

Цель преподавания дисциплины. Задачи курса

Цель преподавания дисциплины. Задачи курса 1. Цели и задачи дисциплины Цель преподавания дисциплины Дисциплина Информатика преподается на втором и третьем курсах экологического факультета в течение второго семестра второго курса и первого семестра

Подробнее

Презентация по дисциплине:

Презентация по дисциплине: ГАПОУ «ОАТК им. В.Н. Бевзюка» Презентация по дисциплине: «Информатика» на тему: «Программное обеспечение ПК» Преподаватель: Герат Е.А. 2016год Программное обеспечение (Software) - совокупность программ

Подробнее

Возможности использования 1С Web-расширения

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

Подробнее

Интеграция платформы «1С:Предприятие 8»

Интеграция платформы «1С:Предприятие 8» Интеграция и внешних систем «Управляем предприятием» 12 (47), 2014 ИТ-инфраструктура Михаил Киреев Руководитель отдела разработки департамента 1С ГК «КОРУС Консалтинг». Руководил проектами разработки и

Подробнее