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

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

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

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

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

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

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

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

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

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

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

Обслуживание

Поддержка заказчиков обсуждается в стандарте ISO 9000-2. Сопровождение системы, как правило, включает в себя обнаружение и анализ несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию программных ошибок; модификацию интерфейсов, что необходимо в случае внесения добавлений или изменений в аппаратуру; функциональное расширение или улучшение производительности Все действия по сопровождению должны проводиться и контролироваться в соответствии с планом сопровождения, который заранее определяется и согласовывается поставщиком и заказчиком. В заключение нам остается лишь добавить, что технология разработки программного обеспечения - это целая наука, которой в России, увы, почти не учат. Отсюда явный дефицит хороших менеджеров и специалистов по комплексным проектам. Общие положения стандарта по обеспечению качества - лишь верхушка айсберга. За пределами нашей статьи остались детали тех процессов, которые реально обеспечивают качество конечного продукта. Но это, как правило, "ноу хау" компании.

2. АВТОРСКОЕ ПРАВО НА ПРОГРАММНЫЙ ПРОДУКТ

КАК ОБЪЕКТ СТОИМОСТНОЙ ОЦЕНКИ

Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программные продукты. Стоит сразу же отметить разницу понятий " программный продукт " (ПП) и "программа для ЭВМ", которая полностью определена.

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

Наиболее сложной, но интересной в теоретическом и практическом плане является такая обязательная процедура введения в хозяйственный оборот как стоимостная оценка имущественных прав на ПП. Еще далеко не разрешены все проблемы, связанные со стоимостной оценкой объектов промышленной собственности, а оценка стоимости авторских прав на ПП тем более затруднена, т.к. ПП является сложным синтетическим и часто составным объектом интеллектуальной собственности (ОИС) .

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

Стоимостная оценка ПП с целью включения в НМА (капитализации) называется балансовой стоимостью и носит явно выраженный затратный характер.

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

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

- приватизация или превращение фирмы в акционерное общество;

- оценка имущества фирмы в случае ее разделения;

- организация на основе фирмы обособленного нового производства;

- оценка имущества фирмы в случае ее продажи;

- оценка имущества фирмы при страховании;

- оценка имущества фирмы при банкротстве.

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