Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном Страница 2

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

По определению, предложенному Фондом за свободную информационную инфраструктуру, программный патент – это «патент на что-либо, выполняемое компьютером посредством программного обеспечения».

Защитники программных патентов считают, что они позволяют:

– защитить сложное ПО от подражателей, которым не нужно тратить время и деньги на проектные работы;

– защитить изобретателей-одиночек от крупных компаний;

– труднодоступность запатентованных технологий стимулирует создание более совершенных технологий.

Документация – печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие как пользоваться программой.

Документация состоит из отдельных документов.

Документ как элемент документации – это целевая информация, предназначенная для конкретной аудитории, размещённая на конкретном носителе в заданном формате.

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

Разработка программного обеспечения (software development) – это процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения.

Как и традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы строк исходного кода, которые должны правильно исполняться в изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее совершенных из современных машин, таких как самолёты.

Накопленный к настоящему времени опыт создания программных систем (ПС) показывает, что это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени создание таких систем нередко выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ПО. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок).

Проблемы создания ПО следуют из его свойств. Еще в 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость.

Современные крупномасштабные проекты создания и развития ПС характеризуются следующими особенностями.

Характеристики объекта внедрения:

– структурная сложность (многоуровневая иерархическая структура организации) и территориальная распределенность;

– функциональная сложность (многоуровневая иерархия и большое количество функций, выполняемых организацией; сложные взаимосвязи между ними);

– информационная сложность (большое количество источников и потребителей информации (министерства и ведомства, местные органы власти, организации-партнеры), разнообразные формы и форматы представления информации, сложная информационная модель объекта – большое количество информационных сущностей и сложные взаимосвязи между ними), сложная технология прохождения документов;

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

Технические характеристики проектов создания ПО:

– различная степень унифицированности проектных решений в рамках одного проекта;

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

– отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем, высокая доля вновь разрабатываемого ПО;

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

– большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

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

Организационные характеристики проектов создания ПО:

– различные формы организации и управления проектом: централизованно управляемая разработка тиражируемого ПО, экспериментальные пилотные проекты, инициативные разработки, проекты с участием как собственных разработчиков, так и сторонних компаний на контрактной основе;

– большое количество участников проекта как со стороны заказчиков (с разнородными требованиями), так и со стороны разработчиков (более 100 человек), разобщенность и разнородность отдельных групп разработчиков по уровню квалификации, сложившимся традициям и опыту использования тех или иных инструментальных средств;

– значительная длительность жизненного цикла системы, в том числе значительная временная протяженность проекта, обусловленная масштабами организации-заказчика, различной степенью готовности отдельных ее подразделений к внедрению ПО и нестабильностью финансирования проекта;

– высокие требования со стороны заказчика к уровню технологической зрелости организаций-разработчиков (наличие сертификации в соответствии с международными и отечественными стандартами).

Уже в конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, выглядели следующим образом:

– только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

– 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

– 31,1% проектов были аннулированы до завершения;

– для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%.

В соответствии с исследованиями 1998 года процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

– нечеткая и неполная формулировка требований к ПО;

– недостаточное вовлечение пользователей в работу над проектом;

– отсутствие необходимых ресурсов;

– неудовлетворительное управление проектом;

– частое изменение требований и спецификаций;

– новизна и несовершенство используемой технологии;

– недостаточная поддержка со стороны высшего руководства;