Тема 1. Программные средства и информационные технологии, их современное состояние и перспективы развития
Рассматриваются основные понятия об отчуждаемом от разработчика и тиражируемом программном изделии (ПИ), как средстве реализации информационных технологий экономического назначения. Состояние рынка программных продуктов, тенденции его развития, проблемы использования ПО. Нормативно-правовое и стандартное обеспечение процессов производства и использования ПО и информационных технологий. Рассматривается современное состояние отрасли, связанной с разработкой и сопровождением программной продукции. Обращается внимание на современные технологии разработок ПО, организационные особенности предприятий отрасли, существующее положение дел по управлению работами по созданию ПО. Модель СММ. Происходит знакомство с основной отраслевой терминологией: программа, программное средство (ПС), программное изделие (ПИ), программный комплекс (ПК) и др. Из рекомендуемой литературы следует обратить внимание на материалы источников [2,4,10,11,18,21].
Программное обеспечение – совокупность программ, ЭВМ, процедур и правил вместе со всей, связанной с этими компонентами, документацией позволяющей использовать ВТ для решения конкретных задач.
Становление индустрии ПО, как отрасли проходило в несколько этапов:
1–вый этап: Разработка ПО для собственных нужд;
2–ой этап: Становление товарного производства программной продукции. Появление и распространение отчуждаемого и тиражируемого продукта;
3–ий этап: Экстенсивное производство ПО;
4–ый этап: Переход к интенсивному производству ПО. Появляется технологическая обработка ПО. Использование автоматизированных и типовых средств обработки (исходных прототипов).
Основные термины определяются: стандартом ЕСПД (19.004) и ряд терминов определяется законом «О правовой охране программ для ЭВМ и баз данных» 1992 год, соответствующими стандартами ISO.
Программное изделие (ПИ) – программа на носителе данных, являющаяся продуктом программного производства.
Программа – объективная форма представления совокупности данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств с целью получения определенного результата. Программа для ЭВМ – подготовительные материалы, полученные в ходе ее разработки и порождаемые ею аудио-визуальные изображения.
ПИ – универсальное изделие, предназначенное для широкого круга пользователей.
ПИ – изделие, предназначенное для широкого употребления, оно должно быть тщательно документировано, чтобы его могли использовать не только разработчики.
Программный продукт – любая программная разработка, которая может быть получена не только как результат промышленного производства.
Программное средство (ПС) – программа, предназначенная для многократного применения на различных объектах и разработанная любым способом (чаще всего имеют в виду – средства производства ПИ, и инструментарий для разработки ПИ).
Индустрия ПО начала зарождаться в середине 50-х годов XIX в., однако почти до конца 60-х ей не уделялось серьезного внимания, поскольку ее доля в компьютерном бизнесе была слишком мала. В 1970 г. годовой оборот всех фирм-разработчиков ПО в США не превышал 1/2 млрд. долл. - около 3,7% всего оборота компьютерного бизнеса. Серьезный рост начался в 70-х годах XX в., начиная с принятого фирмой 1ВМ в 1969 г. решения о развязывании цен (раздельном назначении цен на аппаратуру, ПО и услуги), и продолжился до конца декады и появления персонального компьютера. К 1979 г. годовой объем продаж фирм-разработчиков ПО в США составлял около $2 млрд. В 80-х годах рост составлял 20% в год и более. Таким образом, годовые доходы фирм выросли до $10 млрд. к 1982 г. и $25 млрд. к 1985 г. Сегодня общий объем продаж ПО превышает $100 млрд. Производство ПО сегодня - крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов, называющих себя программистами, разработчиками ПО и т.п. Еще несколько миллионов человек занимают рабочие места, напрямую зависящие от благополучия корпоративных информационных подразделений либо от производителей ПО.
Накопленный к настоящему времени опыт создания систем ПО показывает, что это логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени создание таких систем нередко выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ПО. Кроме того, в процессе создания и функционирования ПО потребности пользователей постоянно изменяются или уточняются, что еще более усложняет разработку и сопровождение таких систем.
Чтобы понять принципиальные отличия сложного ПО от обычной программы, рассмотрим рис.1.1.
В левом верхнем углу рисунка находится программа. Она является завершенным продуктом, пригодным для запуска только своим автором и только в той системе, где она была разработана.
При перемещении вниз через горизонтальную границу программа превращается в программный продукт. Это программа, которую любой человек может использовать и, возможно, при наличии программистской квалификации, сопровождать, т.е. вносить в нее различные изменения. Она может использоваться в различных операционных системах и с различными данными.
Рис.1.1.
Такую программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных, обработать эти примеры и зафиксировать результаты. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее. Опыт говорит, что программный продукт стоит, по крайней мере, втрое дороже, чем просто отлаженная программа с такой же функциональностью.
При пересечении вертикальной границы программа становится компонентом программного комплекса. Он представляет собой набор взаимодействующих программ, согласованных по функциям и форматам данных, предназначенный для решения крупномасштабных задач. Чтобы стать частью программного комплекса, входные и выходные данные и сообщения программы должны удовлетворять точно определенным интерфейсам. Программа должна быть спроектирована таким образом, чтобы использовать точно определенные ресурсы - объем памяти, внешние устройства, процессорное время. Наконец, программу нужно протестировать вместе с прочими системными компонентами во всех сочетаниях, которые могут встретиться. Это тестирование может оказаться большим по объему, поскольку количество тестируемых случаев растет экспоненциально. Оно также занимает много времени, так как скрытые ошибки выявляются при неожиданных взаимодействиях отлаживаемых компонентов. Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов.
В правом нижнем углу находится комплексный программный продукт. От обычной программы он отличается во всех перечисленных выше отношениях и стоит соответственно, как минимум, в девять раз дороже. Именно такой продукт представляет собой сложную систему ПО, которая является целью большинства программных проектов. Современные крупномасштабные проекты ПО характеризуются особенностями, представленными на рис.1.2.
Рис. 1.2.
В конце 60-х годов прошлого века в США было отмечено явление под названием кризис ПО. Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполняемые в последние годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Например, результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, выглядели следующим образом:
только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
31,1% проектов были аннулированы до завершения;
• для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения на 122%.
В 1998 г. процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).
В последние годы процентное соотношение трех перечисленных категорий проектов также незначительно меняется в лучшую сторону, однако, по оценкам ведущих аналитиков, это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет повышения управляемости и качества проектирования.
В числе причин возможных неудач, по мнению разработчиков, фигурируют:
нечеткая и неполная формулировка требований к ПО;
недостаточное вовлечение пользователей в работу над проектом;
отсутствие необходимых ресурсов;
неудовлетворительное планирование и отсутствие грамотного управления проектом;
частое изменение требований и спецификаций;
новизна и несовершенство используемой технологии;
недостаточная поддержка со стороны высшего руководства;
недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Однако основная причина всех проблем заключается в ответе на вопрос: является ли проектирование ПО ремеслом, инженерной дисциплиной или чем-то средним? Многие разработчики ПО, вероятно, заявят, что программирование хотя и не сложилось в установившуюся инженерную дисциплину, но уже близко подошло к этому.
Можно утверждать, что разработка ПО на сегодняшний день перестает быть чистым ремеслом. Со времени зарождения программирования сообщество программистов добилось некоторых успехов. Признанные корифеи программирования изобрели в помощь разработчикам ПО успешные методы и правила. Но, подобно средневековым архитекторам, разработчики ПО изучили и испытали эти методы путем проб и ошибок. Современным разработчикам не хватает внедрения в практику системы основных принципов, на основе которых можно было бы строить свои правила и методы, сопоставимые с методами промышленного производства.
Организации, работающие в области разработки, поставки, внедрения и сопровождения ПО и системной интеграции, все больше ощущают, что в основе их конкурентоспособности лежат качество и низкий уровень себестоимости, технологичность производства.
Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.
Сегодня компания-разработчик практически испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что исполнитель не может оказать некачественную услугу.
По мере повышения технологической зрелости организации процессы создания и сопровождения ПО становятся более стандартизованными и согласованными. При этом формализация процессов позволяет стандартизовать ожидаемые результаты их выполнения и обеспечить предсказуемость результатов выполнения проектов.
Зрелость процессов — это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать, а организация производства программной продукции выходит на промышленный уровень.
На каждом уровне устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов. Выход на каждый уровень технологической зрелости является результатом появления определенного количества компонентов в процессах создания ПО, что в свою очередь приводит к повышению их производительности и качества. На рис. 1.3 показаны пять уровней технологической зрелости СММ.
Рис. 1.3
Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.
Уровни со второго по пятый могут характеризоваться через операции, направленные на стандартизацию и (или) модернизацию процессов создания ПО, и через операции, составляющие сами процессы его создания. При этом первый уровень является как бы базой, фундаментом для сравнительного анализа верхних уровней.
На уровне 1 (начальном) основные процессы создания и сопровождения ПО носят случайный характер и выполняются хаотично. Успех выполнения проекта всецело зависит от индивидуальных усилий персонала. На этом уровне, как правило, в организации не существует стабильной среды, необходимой для создания и сопровождения ПО.
Успех проекта при этом, как правило, полностью зависит от степени энергичности и опыта руководства и профессионального уровня исполнителей. Может случиться, что энергичный руководитель преодолеет все препятствия в процессе выполнения проекта и добьется выпуска действительно жизнеспособного программного продукта. Но после того, как такой руководитель оставит свой пост, исчезнет и гарантия того, что следующий подобный проект будет успешным. При отсутствии необходимого уровня управления проектом положение не сумеет спасти даже передовая технология.
На уровне 2 (уровне повторяемых процессов) процессы управления проектом позволяют обеспечивать текущий контроль стоимости проекта, графика его выполнения и выполняемых функций. Дисциплина выполнения проекта такова, что существует возможность прогнозирования успешности выполнения проектов по созданию аналогичных программных продуктов.
На этом уровне планирование проектных работ и управление новыми проектами базируется на опыте успешно выполненных аналогичных проектов. Основной особенностью второго уровня является наличие формализованных и документированных эффективных процессов управления проектами, что позволяет использовать положительный опыт успешно завершенных проектов. Эффективными могут называться процессы, которые документированы, реально используются, поддаются количественной оценке и пригодны для модернизации. Необходимо, чтобы персонал был обучен их применению.
Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов. Модель СММ содержит 18 таких групп, последняя версия модели СММI — 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют СММI):
управление требованиями;
управление конфигурацией;
планирование проекта;
мониторинг и контроль проекта;
управление контрактами;
измерения и анализ;
обеспечение качества процесса и продукта.
Процессы на втором уровне можно охарактеризовать как упорядоченные в связи с тем, что они заранее планируются, и их выполнение строго контролируется, за счет чего достигается предсказуемость результатов выполнения проекта. С увеличением и усложнением проектов внимание смещается с технических аспектов их выполнения на организационные и управленческие аспекты. Выполнение процессов требует от персонала более эффективной и слаженной работы, что, в свою очередь, требует изучения документированного передового опыта в целях повышения профессионального мастерства.
На уровне 3 (уровне стандартизованных процессов) процессы создания ПО документированы, стандартизованы и представляют собой единую технологическую систему, обязательную для всех подразделений организации. Во всех проектах используется опробованная, утвержденная и возведенная в статус стандарта единая технология создания и сопровождения ПО.
На данном уровне к процессам уровня 2 добавляются следующие процессы:
спецификация требований;
интеграция продукта;
верификация;
аттестация;
стандартизация процессов организации;
обучение;
интегрированное управление проектом;
управление рисками;
анализ и принятие решений.
Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, — группа по разработке процессов создания.
На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО».
Описание каждого процесса включает в себя условия его выполнения, входные данные, стандарты и процедуры выполнения, механизмы проверки (например, экспертные оценки), выходные данные и условия завершения. В описание процесса также включаются сведения об инструментальных средствах, необходимых для его выполнения, и указание на роль, ответственную за его выполнение.
Главное назначение уровня 4 (уровня управляемых процессов) — текущий контроль над процессами. Управление должно обеспечивать выполнение процессов в рамках заданного качества. Могут быть неизбежные потери и временные пики в измеряемых результатах, которые требуют вмешательства, но в целом система должна быть стабильна.
На уровне 4 добавляются следующие процессы:
управление производительностью и продуктивностью;
количественное управление проектом.
На этом уровне на практике применяется детальная оценка качества как процессов создания, так и самого создаваемого программного продукта. При этом применяются количественные критерии оценки.
В рамках всей организации разрабатывается единая программа количественного контроля производительности создания ПО и его качества. Для облегчения анализа процессов создается единая база данных процессов создания и сопровождения ПО для всех проектов, выполняемых в организации. Разрабатываются универсальные методики количественной оценки производительности процессов и качества их выполнения. Это позволяет проводить количественный анализ и оценку процессов создания и сопровождения ПО.
Результаты выполнения процессов на четвертом уровне становятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных ограничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.
Основное назначение уровня 5 (уровня оптимизируемых процессов) — последовательное усовершенствование и модернизация процессов создания и сопровождения ПО. В целях плановой модернизации технологии создания ПО в организации создается специальное подразделение, основными обязанностями которого являются сбор данных по выполнению процессов, их анализ, модернизация имеющихся и создание новых процессов, их проверка на пилотных проектах и придание им статуса стандартов предприятия.
На уровне 5 добавляются следующие процессы:
внедрение технологических и организационных инноваций;
причинно-следственный анализ и разрешение проблем.
Процессы создания и сопровождения ПО характеризуются
как последовательно совершенствуемые, поскольку организация прилагает постоянные усилия по их модернизации.
Таким образом, основным перспективным направлением развития индустрии программного обеспечения является поэтапный переход предприятий-разработчиков на более высокие уровни зрелости.
Контрольные вопросы:
Что включает в себя понятие прикладной программы?
Дайте определение понятию «Программное обеспечение».
Для чего предназначена модель СММ?
Чем отличается программный продукт от прикладной программы?
Перечислите основные направления развития индустрии производства ПО.