Образец лицензионного договора на использование программного продукта, заключаемого между юридическим и физическим лицом
Первым Автором может быть только физическое лицо, творческим трудом которого было создано произведение искусства, литературы или науки, а также любая другая интеллектуальная собственность. Автору принадлежит весь комплекс личных неимущественных прав и исключительное право на любое использование произведения.
Правообладателями могут быть другие лица, которым перешло исключительное право от Автора на основании договора либо в силу закона, например: наследники автора, работодатели, заказчики, если автор работал за их счет.
Правообладатели используют знак охраны авторского права, этот знак представляет из себя букву «С» в окружности.
Условно авторские права могут быть разделены на две взаимосвязанные между собой группы: Первая группа – Личные неимущественные права и имущественные права. Первая группа включает в себя: быть Автором и издаваться под собственным именем, а также обнародовать произведение.
Вторая группа – это исключительное право совершать действия и использовать произведение для извлечения прибыли или без прибыли, а именно: размножение и продажа экземпляров произведения, публичные показы, выступления, импорт оригинала, воспроизведение звуко- и видеозаписей, реализация различных проектов (архитектура, дизайн) и любые иные, не противоречащие закону, действия в средствах массовой информации.
В соответствии со ст.1281 ГК РФ срок действия исключительного права сохраняется в течение всей жизни автора и семидесяти лет после его смерти, после этого срока произведение считается национальным достоянием.
Согласно ст.1259 ГК РФ объектом авторского права являются произведения (части произведения) науки, литературы, искусства, независимо от вида их назначения, достоинства, а также от способа выражения. Произведения могут быть в письменной устной форме, рисунки, картины, все виды записей, танцы, спектакли, географически и топографические карты, программы ЭВМ, аранжировки, сборники и др.
Официальные документы, информационные сообщения, произведения народного творчества не могут быть объектами авторского права.
Авторское право не связано с материальным (вещественным) носителем произведения. Без согласия Автора допускается только цитирование произведения с обязательным указанием Автора. Вознаграждение, в этом случае, Автору не выплачивается.
Регистрация авторского права на произведение необязательна, но желательна, поскольку, в случае плагиата, Автору будет значительно легче доказать свое первоначальное право. Существует организация, которая будет сохранять произведение в своем депозитарии в оригинальном экземпляре.
ЛИЦЕНЗИОННЫЙ ДОГОВОР
1. ПРЕДМЕТ ДОГОВОРА
1.1. По настоящему Договору Лицензиар передает, а Лицензиат принимает неисключительное право использования Программного продукта « » (далее «Программный продукт» или «Модуль»).
1.2. Все положения настоящего Договора относятся к Программному продукту в целом и ко всем его компонентам в отдельности, включая документацию на Программный продукт.
1.3. Лицензиар является автором и обладателем всех прав на Программный продукт, включая документацию и исходный текст, на основании свидетельства о государственной регистрации программы для ЭВМ № от « » 2021 года.
2. СРОК ДОГОВОРА
2.1. Договор вступает в законную силу с даты подписания его обеими Сторонами.
2.3. Передаваемые Лицензиату неисключительные права на Программный продукт действуют до прекращения действия исключительных прав на Программный продукт.
3. ЦЕНА ДОГОВОРА
3.1. Лицензиат обязуется уплатить Лицензиару вознаграждение в сумме рублей до удержания НДФЛ (налога на доходы физических лиц). Передача прав на использование Программного продукта НДС не облагается в соответствии с пп. 26 п.2 ст.149 НК РФ.
3.2. В соответствие со ст. 226 и ст. 224 НК РФ Лицензиар обязуется удержать и перечислить НДФЛ в бюджет.
4. ПОРЯДОК РАСЧЕТОВ
4.1. Лицензиат оплачивает Лицензию в течение календарных дней с даты подписания настоящего Договора путем перевода денежных средств на счет Лицензиара, указанный в п.11 настоящего Договора.
4.2. В течение календарных дней с момента оплаты Лицензиар передает Лицензиату права на использование Программного продукта.
4.3. Право использования Программного продукта предоставляется Лицензиату путем подписания Сторонами Акта приема-передачи прав. С момента подписания право использования Программного продукта считается предоставленным Лицензиату.
4.4. Одновременно с предоставлением прав Лицензиар открывает доступ к использованию Программного продукта путем передачи Лицензиату экземпляров Программного продукта включая документацию по электронной почте, адрес которой указан в п.11 настоящего Договора.
5. УСЛОВИЯ ДОГОВОРА
5.1. Лицензиат получает право:
5.1.1. Использовать Модуль по назначению.
5.1.2. Копировать Модуль и передавать его по каналам связи.
5.1.3. Использовать результаты работы Модуля любым способом.
5.2. Все договоренности между Лицензиаром и Лицензиатом касательно Программного продукта, устные и письменные, предшествовавшие заключению данного Договора, считаются недействительными.
5.3. В случае если суд признает какие-либо положения настоящего Договора недействительными, Договор продолжает действовать в остальной части.
5.4. Лицензиат получает право включать (встраивать) Модуль в состав только тех программных продуктов, исключительные права на которые принадлежат Лицензиату (далее – «ПО»).
5.5. При передаче Лицензиатом своих исключительных прав на программные продукты, в которые встроен Модуль, Лицензиат обязан за календарных дней до предполагаемой даты передачи прав письменно уведомить Лицензиара о своем намерении произвести передачу исключительных прав на соответствующие Программные продукты. Если на момент заключения Договора передача прав уже состоялась или до предполагаемой передачи осталось менее календарных дней, Лицензиат обязан уведомить об этом Лицензиара до заключения данного Договора. Новый правообладатель может использовать Модуль только после заключения нового лицензионного договора с Лицензиаром.
5.6. Лицензиат обязуется не распространять Программный продукт отдельно от принадлежащего Лицензиату ПО. Под распространением Программного продукта понимается предоставление доступа третьим лицам к воспроизведенному в любой форме Программному продукту. Под третьими лицами понимаются все лица, исключая Стороны данного Договора и работников, нанятых Лицензиатом по трудовому договору или договору подряда.
5.8. Лицензиат не имеет права предоставлять функции склонения по падежам, реализованные при помощи Программного продукта в виде программного интерфейса (API), другим программным системам, правообладателем которых он не является. В случае возникновения такой необходимости правообладатели вышеназванных систем должны сначала получить права на использование Программного продукта.
5.9. При передаче Лицензиатом неисключительных прав на программные продукты, в которые встроен Модуль, Лицензиат не обязан уведомлять об этом Лицензиара.
5.10. Лицензиат не обязан предоставлять Лицензиару отчеты по использованию Модуля.
6. ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА И ТЕХНИЧЕСКАЯ ПОДДЕРЖКА
6.1. Лицензиар гарантирует отсутствие в Модуле технических дефектов, приводящих к возникновению недокументированных исключений (exceptions), утечкам памяти или «зависаниям» вызывающей программы.
6.2. В случае обнаружения в Модуле дефектов, перечисленных в п.6.1, Лицензиар обязуется устранить эти дефекты в недельный срок при условии предоставления Лицензиатом способа воспроизведения указанных дефектов.
7. ПРИОБРЕТЕНИЕ НОВЫХ ВЕРСИЙ МОДУЛЯ
7.1. В течение с момента передачи прав на Модуль Лицензиат имеет право получать новые версии Модуля бесплатно. Для этого достаточно направить Лицензиару запрос по электронной почте, указанной в п.11 настоящего Договора. Лицензиар обязуется удовлетворить запрос в течение календарных дней.
7.2. По истечении с момента передачи прав на Модуль Лицензиат имеет право на продление периода получения новых версий за дополнительную плату, равную % от цены данного договора.
8. ОТВЕТСТВЕННОСТЬ
8.1. Лицензиар не несет ответственности за какой-либо ущерб, связанный с использованием или невозможностью использования Модуля.
9. ИЗМЕНЕНИЕ И РАСТОРЖЕНИЕ ДОГОВОРА
9.1. Договор может быть расторгнут по взаимному письменному соглашению Сторон.
9.2. В случае установления факта нарушения Лицензиатом условий данного Договора или законодательства Российской Федерации в отношении Программного продукта, Лицензиар обязуется известить об этом Лицензиата. Лицензиат обязуется в тридцатидневный срок устранить нарушения, либо представить доказательства отсутствия вины Лицензиата в указанном нарушении. Лицензиар в случае отсутствия подобной информации имеет право в любой момент в одностороннем порядке расторгнуть настоящий Договор, уведомив об этом Лицензиата.
9.3. При расторжении настоящего Договора или в случае, если Договор будет признан недействительным, Лицензиат обязан прекратить использование Модуля, удалить все имеющиеся в его распоряжении копии Модуля и известить об этом Лицензиара.
Аннотация
Предметом изучения является технология, методы и средства разработки, тестирования и отладки программного продукта.
Объектом изучения выступает жизненный цикл программного обеспечения.
Курс базируется на стандарте «Информационная технология, системная и программная инженерия». Процессы жизненного цикла программных средств ISO/IEC 12207:2007 System and software engineering. Software life cycle processes.
Место дисциплины в учебном процессе Университета.
Дисциплина «Программная инженерия» относится к вариативной части профессионального цикла основной образовательной программы подготовки по направлению 230700.62 «Прикладная информатика».
Уровень исходных знаний, умений и подготовленности обучающегося, необходимые для освоения данной дисциплины достигается при освоении предшествующих дисциплин: «Информатика и программирование», «Базы данных», «Высокоуровневые методы информатики и программирования», «Проектирование информационных систем».
Цель и задачи дисциплины:
Целью освоения дисциплины «Программная инженерия» является: дать студентам представление о полном жизненном цикле программных средств, стадиях разработки программного обеспечения, получить опыт проектирования информационных систем и программного обеспечения.
· развить способность работать в коллективе, нести ответственность за поддержание партнёрских, доверительных отношений;
· развить способность осознавать социальную значимость своей будущей профессии, обладать высокой мотивацией к выполнению профессиональной деятельности;
· развить способность осуществлять и обосновывать выбор проектных решений по видам обеспечения информационных систем;
· развить способность документировать процессы создания информационных систем на всех стадиях жизненного цикла;
· развить способность использовать технологические и функциональные стандарты, современные модели и методы оценки качества и надежности при проектировании, конструировании и отладке программных средств;
· развить способность применять к решению прикладных задач базовые алгоритмы обработки информации, выполнять оценку сложности алгоритмов, программировать и тестировать программы;
· развить способность принимать участие во внедрении, адаптации и настройке прикладных ИС;
· развить способность готовить обзоры научной литературы и электронных информационно-образовательных ресурсов для профессиональной деятельности.
Процесс изучения дисциплины направлен на формирование профессиональных компетенций (ПК), предусмотренных Федеральным государственным образовательным стандартом высшего профессионального образования по направлению подготовки 230700.62 «Прикладная информатика» (квалификация (степень) «бакалавр»):
· способен использовать основные законы естественнонаучных дисциплин в профессиональной деятельности и эксплуатировать современное электронное оборудование и информационно-коммуникационные технологии в соответствии с целями образовательной программы бакалавра (ПК-З);
· способен осуществлять и обосновывать выбор проектных решений по видам обеспечения информационных систем (ПК-5);
· способен документировать процессы создания информационных систем на всех стадияхжизненного цикла (ПК-6);
· способен использовать технологические и функциональные стандарты, современные модели и методы оценки качества и надежности при проектировании конструировании и отладке программных средств (ПК-7);
· способен проводить обследование организаций, выявлять информационные потребности пользователей, формировать требования к информационной системе, участвовать в реинжиниринге прикладных и информационных процессов (ПК-8);
· способен эксплуатировать и сопровождать информационные системы и сервисы (ПК-12);
· способен принимать участие в реализации профессиональных коммуникаций в рамках проектных групп, презентовать результаты проектов и обучать пользователей ИС (ПК-14);
В результате освоения дисциплины студент должен демонстрировать следующие результаты образования:
· как работать в коллективе, нести ответственность за поддержание партнёрских, доверительных отношений;
· социальную значимость своей будущей профессии, обладать высокой мотивацией к выполнению профессиональной деятельности;
· способы осуществления и обоснования выбора проектных решений по видам обеспечения информационных систем;
· правила документирования процессов создания информационных систем на всех стадиях жизненного цикла;
· способы использования технологических и функциональных стандартов, современных моделей и методов оценки качества и надежности при проектировании, конструировании и отладке программных средств;
· о внедрении, адаптации и настройке прикладных ИС;
· как готовить обзоры научной литературы и электронных информационно-образовательных ресурсов для профессиональной деятельности;
· требования ГОСТ к организации жизненного цикла программного обеспечения;
· ключевые проблемы, возникающие в процессе проектирования информационных систем и ПО, методы их решения.
· организовать процесс разработки проекта;
· выполнять декомпозицию проекта на подзадачи.
· организации выбора разработчика и поставщика программного средства;
· организации выбора способа приобретения программного средства;
· формулирования требований к правам доступа программного средства;
· формулирования требований к интерфейсу (меню) программного средства;
· определения рисков разработки и внедрения программного средства;
· определения оптимальной стратегии внедрения программного средства.
Тема 1. Организация процесса приобретения и поставки программных средств
Цели и задачи изучения темы:
· Понять составляющие, цели, задачи и результаты успешного завершения процессов приобретения и поставки программных средств.
· Освоить процесс выбора оптимального способа приобретения программного средства.
· Освоить процесс выбора оптимального программного средства из решений, представленных на рынке программного обеспечения.
· Научиться составлению соглашения между поставщиком, разработчиком и заказчиком программного средства.
1. Процесс приобретения программного средства.
2. Подготовка к приобретению программного продукта.
3. Выбор поставщика и заключение соглашения.
4. Выполнение соглашения и приемка программного средства.
5. Процесс поставки программного средства.
Вопрос 1. Процесс приобретения программного средства.
Цель процесса приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс начинается с выяснения потребностей заказчика и заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне.
Рис. 1. Процесс автоматизации
В результате успешного осуществления процесса приобретения, представленного на рисунке 2:
1. определяются потребности в приобретении, конечные цели, критерии приемки продукта и (или) услуги и стратегии приобретения;
2. разрабатывается соглашение, которое ясно выражает ожидания, ответственность и обязательства как приобретающей стороны, так и поставщика;
3. выбирается один или несколько поставщиков;
4. приобретается продукт и (или) услуга, которые удовлетворяют заданным потребностям приобретающей стороны;
5. приобретение контролируется таким образом, чтобы удовлетворялись заданные ограничения, такие как, например, по стоимости, срокам и качеству;
6. принимаются продукты и (или) услуги от поставщиков;
7. по всем идентифицированным открытым позициям имеются удовлетворительные заключения, согласованные приобретающей стороной и поставщиком.
Рис. 2. Процесс приобретения программного средства
Согласно общепринятой мировой практике потенциальные поставщики узнают о потребности организации в программном продукте после объявления тендера на поставку или кратко «Объявлении о приобретении программного продукта». В Российской Федерации государственные структуры обязаны объявлять тендер, а коммерческие структуры могут ограничиться отправкой заявки на поставку продукта или услуги идентифицированным поставщикам. Данной процедуре предшествует подготовка к приобретению программного продукта, т.е. формулирование первичных требований и выбор способа приобретения.
Процесс приобретения программного средства можно разделить на следующие подпроцессы: основные, поддерживающие и организационные, как это представлено на рисунке 3.
Рис. 3. Процессы приобретения программного средства
Вопрос 2. Подготовка к приобретению программного продукта.
Процесс подготовки к приобретению состоит из решения следующих задач:
1. Приобретающая сторона начинает процесс приобретения, описывая свое представление или потребность в приобретении, разработке или расширении системы, программного продукта или программной услуги.
2. Приобретающая сторона должна определять и анализировать системные требования. Необходимо, чтобы системные требования охватывали деловые, организационные и пользовательские требования, а также требования к безопасности, защищенности и другим критическим свойствам, наряду со связанными с ними проектированием, тестированием, стандартами и процедурами оценки соответствия.
3. Приобретающая сторона может выполнять определение и анализ требований к программным средствам самостоятельно или может поручить поставщику осуществить эту задачу.
4. Если приобретающая сторона поручает какому-либо поставщику выполнить анализ системных требований или требований к программным средствам, то она должна оставить за собой право утвердить проанализированные требования.
5. Приобретающая сторона может использовать процесс определения требований правообладателей для установления требований заказчиков.
6. Приобретающая сторона должна рассмотреть варианты приобретения на основе анализа соответствующих критериев, учитывающих риски, стоимость и полезность каждого варианта.
Варианты включают в себя:
a. покупку готового программного продукта, удовлетворяющего требованиям;
b. разработку программного продукта или получение программной услуги внутри приобретающей организации;
c. разработку программного продукта или получение программной услуги по контракту;
d. комбинации из a, b и c;
e. расширение свойств существующего программного продукта или услуги.
7. Если приобретается готовый программный продукт, то приобретающая сторона должна гарантировать, что выполнены следующие условия:
a. удовлетворяются требования к программному продукту;
b. имеется в наличии необходимая документация;
c. соблюдаются права собственности, применения, владения, гарантий и лицензирования;
d. предусматривается последующая поддержка программного продукта.
8. Приобретающей стороне следует подготовить, документировать и выполнить план приобретения. План должен содержать:
a. требования к системе;
b. запланированное применение системы;
c. тип используемого контракта;
d. ответственность организаций-участников;
e. концепцию поддержки, которая будет использована;
f. рассмотренные риски, также как и методы менеджмента рисков.
9. Приобретающая сторона должна определить и документировать принятые стратегию и условия (критерии).
10. Приобретающей стороне следует документировать требования к приобретению (например, заявки на условия приобретения), состав которых зависит от вариантов приобретения, В документацию по приобретению следует включать:
a. системные требования;
b. формулировку области применения;
c. инструкции для претендентов;
d. перечень программных продуктов;
f. контроль подрядчиков;
g. технические ограничения (например, со стороны окружающей среды).
11. Приобретающей стороне следует определить, какие процессы стандарта ГОСТ Р ИСО/МЭК 12207 предназначаются для приобретения, и задать свои требования к адаптации этих процессов. Приобретающей стороне следует конкретизировать, не выполняются ли какие-либо процессы сторонами, отличными от поставщика, так чтобы поставщики могли (в своих предложениях) определить свой подход к поддержке работы других сторон. Приобретающая сторона должна установить область применения задач, определенных контрактом.
12. В документации по приобретению должны также указываться контрольные сроки, определенные в контракте, в соответствии с которыми текущая деятельность поставщика должна пересматриваться и подвергаться аудиту в качестве части процесса мониторинга приобретения.
13. Требования к приобретению следует доводить до сведения организации, выбранной для выполнения деятельности по приобретению.
Вопрос 3. Выбор поставщика и заключение соглашения.
Процесс выбора поставщика состоит из решения следующих задач:
1. Приобретающей стороне следует устанавливать процедуру выбора поставщика, включающую предложенные критерии оценки и значимые требований по соответствию.
2. Приобретающей стороне следует выбрать поставщика, основываясь на оценке предложений от поставщиков и их возможностей, в соответствии со стратегией и условиями приемки приобретающей стороны.
Процесс заключения соглашения состоит из решения следующих задач:
1. До заключения контракта приобретающая сторона может привлекать другие стороны, включая потенциальных поставщиков или какие-либо необходимые третьи стороны (такие как, например, регулирующие органы), к определению требований приобретающей стороны с целью адаптации настоящего стандарта к условиям проекта. При определении этих требований приобретающая сторона должна учитывать воздействие процессов, организационно принятых у поставщика, на требования к адаптации. Приобретающая сторона должна включить в контракт требования к адаптации или сослаться на них в тексте контракта.
2. Приобретающая сторона затем должна подготовить и согласовать контракт с поставщиком, который соответствует требованиям к приобретению, включая стоимость и график работ для поставляемого программного продукта или услуги. В контракте должны быть оговорены права собственности, использования, владения, гарантии и лицензирования, связанные с повторно применяемыми готовыми программными продуктами.
3. В ходе реализации контракта приобретающая сторона должна контролировать изменения в контракте через переговоры с поставщиком в качестве части механизма управления изменениями. Изменения в контракте должны быть изучены для внесения изменений в планы проекта, стоимость, полезность, качество и график работ.
4. В соглашении между приобретающей стороной и поставщиком следует явно выразить ожидания, ответственность и обязательства обеих сторон.
5. В механизме управлении изменениями контракта следует отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и повторных переговоров по контракту, а также связи с заинтересованными правообладателями.
Вопрос 4. Выполнение соглашения и приемка программного средства.
В процессе выполнения соглашения может возникнуть необходимость в его корректировке, например, изменении сроков, внесении дополнительных требований и так далее. Для успешной реализации данного процесса выполняются следующие задачи:
Приобретающая сторона должна осуществлять мониторинг деятельности поставщика в соответствии с процессом ревизии программных средств и процессом аудита программных средств. При необходимости приобретающей стороне следует дополнять мониторинг процессом верификации (подтверждением того, что заданные требования полностью выполнены) и процессом валидации (подтверждением того, что требования, предназначенные для конкретного использования или применения, полностью выполнены) программных средств.
Приобретающая сторона должна взаимодействовать с поставщиком для своевременного обеспечения всей необходимой информацией и решения всех отложенных проблем.
После завершения процесса поставки программного продукта приобретающая сторона осуществляет его приемку, включающую следующие задачи:
1. Приобретающей стороне следует приготовиться к приемке, основываясь на стратегии и критериях, установленных для приемки. В подготовку следует включить тестовые примеры и данные, процедуры тестирования и условия проведения тестирований. Следует определить степень участия поставщика в процессе приемки.
2. Приобретающая сторона должна провести приемочный осмотр и приемочное тестирование поставляемого программного продукта или услуги и должна принять их от поставщика, если все условия приемки удовлетворены.
3. После приемки приобретающей стороне следует принять на себя ответственность за менеджмент конфигурации поставленного программного продукта (приобретающая сторона может инсталлировать программный продукт или выполнить программную услугу в соответствии с инструкциями, определенными поставщиком).
После приемки программного продукта приобретающая сторона должна произвести оплату или выполнить другие согласованные расчеты за предоставленные поставщиком продукты или услуги.
Вопрос 5. Процесс поставки программного средства.
Цель процесса поставки заключается в обеспечении приобретающей стороны продукцией или услугой, удовлетворяющим согласованным требованиям.
В результате успешного осуществления процесса поставки:
a. определяется приобретающая сторона для продукта или услуги;
b. дается ответ на заявку приобретающей стороны;
c. заключается соглашение между приобретающей стороной и поставщиком на разработку сопровождение, применение, упаковку, распределение и инсталляцию продукта и (или) услуги;
d. разрабатывается продукт и (или) услуга, удовлетворяющие согласованным требованиям;
e. продукт и (или) услуга поставляется приобретающей стороне в соответствии с согласованными условиями поставок;
f. продукт инсталлируется в соответствии с согласованными требованиями.
Поставщик должен осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса поставки:
1. Идентификация возможностей. Данный вид деятельности заключается в определении существования и идентификации приобретающей стороны, которая представляет организацию или организации, имеющие потребность в продукте или услуге.
2. Представление заявки поставщиком, включающее решение с ледующих задач:
a. Поставщику следует провести рассмотрение требований, изложенных в заявке, принимая во внимание политики, принятые в организации, и другие положения.
b. Поставщику следует решить: предложить или принять контракт.
c. Поставщик должен подготовить предложение в ответ на заявку.
3. Согласование контракта, включающее решение следующих задач:
a. Поставщик должен провести переговоры и заключить контракт с приобретающей стороной на предоставление программного продукта или услуги.
b. Поставщик может предложить внести изменения в текст контракта в качестве части механизма управления изменениями.
4. Выполнение контракта, включающее решение с ледующих задач:
a. Поставщик должен проводить рассмотрение требований по приобретению для определения структуры работ по руководству и обеспечению проекта, а также для обеспечения качества поставляемого программного продукта или услуги.
b. Поставщик должен определять или выбирать модель жизненного цикла (если не оговорено в контракте) в соответствии с областью применения, масштабом и сложностью проекта. Модель жизненного цикла должна содержать стадии, цели и результаты каждой стадии.
c. Поставщик должен установить требования для планов осуществления менеджмента и обеспечения проекта, а также для обеспечения качества поставляемого программного продукта или услуги. В требования для таких планов следует включать необходимые ресурсы и участие приобретающей стороны.
d. После установления запланированных требований поставщик должен рассмотреть варианты разработки программного продукта или предоставления программной услуги, в соответствии с анализом рисков, связанных с каждым вариантом. Варианты включают:
· разработку программного продукта или предоставление программной услуги с использованием внутренних ресурсов;
· разработку программного продукта или предоставление программной услуги путем заключения контрактов с подрядчиками;
· приобретение готовых программных продуктов от внутренних или внешних поставщиков;
· комбинации вышеуказанных вариантов.
5. Поставщик должен разработать и документировать план менеджмента проекта, включающий следующие основные позиции:
a. организационную структуру проекта, полномочия и ответственность каждого подразделения организации, включая внешние организации;
b. инженерную среду (для разработки, применения или сопровождения), включая условия тестирования, библиотеки, оборудование, удобство обслуживания, стандарты, процедуры и инструментарий;
c. структуру распределения работ в рамках процессов и видов деятельности жизненного цикла, включая программные продукты, программные услуги и непоставляемые элементы, с учетом бюджета, состава исполнителей, материальных ресурсов, размеров программных средств и календарных планов, связанных с этими задачами;
d. менеджмент характеристик качества программных продуктов или услуг. Допускается разработка отдельных планов по обеспечению качества;
e. менеджмент безопасности, защиты и других критических требований к программным продуктам или услугам. Допускается разработка отдельных планов по безопасности и защите;
f. менеджмент подрядчиков, включая выбор подрядчиков и взаимоотношения между подрядчиком и приобретающей стороной;
g. обеспечение гарантии качества;
h. верификацию и валидацию, включая подход к взаимоотношениям с организацией, проводящей верификацию и валидацию, при наличии соответствующих требований;
i. участие приобретающей стороны; в первую очередь, через участие в проведении ревизий, аудитов, неформальных встреч, составление отчетов, модификацию и изменения; реализацию, официальные соглашения, приемку и доступ к средствам;
j. участие пользователей, которое реализуется через требования к настройке упражнений, к демонстрации и оценке прототипов;
k. менеджмент рисков; то есть менеджмент областей проекта, которые связаны с потенциальными техническими, финансовыми и плановыми рисками;
l. политику по защите; то есть правила ознакомления и доступа к информации на каждом уровне проекта организации;
m. официальное принятие, требуемое регулирующими положениями, положениями о сертификации, правах собственности, монопольном применении, гарантиях, лицензиях и т.п.;
n. средства для формирования графиков работ, проведения надзора и составления отчетов;
o. обучение персонала.
6. Поставщик должен формировать и исполнять план (планы) менеджмента проекта (проектов), а именно:
a. разработать программный продукт в соответствии с техническими процессами;
b. использовать программный продукт в соответствии с процессом функционирования программных средств;
c. сопровождать программный продукт в соответствии с процессом сопровождения программных средств.
7. Поставщик должен осуществлять мониторинг и управление развитием и качеством программных продуктов или услуг проекта на всем протяжении жизненного цикла, указанном в контракте.Это должно быть постоянной, многократно повторяющейся задачей, которая обеспечивает:
a. мониторинг продвижения в технических характеристиках, расходах, графиках работ и отчетности о состоянии проекта;
b. выявление возникающих проблем, их регистрацию, анализ и решение.
8. Поставщик должен руководить и управлять деятельностью подрядчиков в соответствии с процессом приобретения. Поставщик должен выполнить все установленные контрактом требования, гарантирующие, что поставляемый приобретающей стороне программный продукт или услуга разрабатываются или изготавливаются в соответствии с первостепенными требованиями контракта.
9. Поставщик должен взаимодействовать с независимой организацией, проводящей верификацию, валидацию или тестирование, как определено в контракте и планах проекта.
Поставщик должен взаимодействовать с другими сторонами, как определено в контракте и в планах проекта.
Поставщику следует координировать проведение предусмотренной контрактом ревизии действий, взаимоотношений и коммуникаций с организацией приобретающей стороны.
Поставщик должен проводить или участвовать в неформальных встречах, анализе условий приемки, приемочном тестировании, совместных ревизиях и аудитах вместе с приобретающей стороной, как определено в контракте и планах проекта.
Поставщику следует выполнять верификацию и валидацию для демонстрации того, что программные продукты или услуги и процессы полностью удовлетворяют установленным требованиям.
Поставщик должен сделать доступными для приобретающей стороны отчеты об оценках, ревизиях, аудиторских проверках, тестированиях и решениях возникших проблем, как определено в контракте.
Поставщик должен обеспечивать приобретающей стороне доступ к своим средствам и средствам подрядчиков для проведения ревизий программных продуктов или услуг, как определено в контракте и планах проекта.
Поставщик должен осуществлять деятельность по обеспечению гарантии качества.
После завершения процесса поставки, разработчик программного обеспечения выполняет сопровождение/поддержку программного продукта. Сопровождение от поддержки отличается тем, что в первом случае поставщик берет на себя обязательства по инсталляции и обеспечению работоспособности программного обеспечения, а во втором оказывает содействие приобретающей стороне в решении этих задач.
Завершается процесс поставки программного продукта приемом и подтверждением поставщиком поступления оплаты или иного способа расчета с заказчиком, а также передачей ответственности за продукт или услугу приобретающей стороне или другой стороне в порядке, предусмотренном соглашением.
Вопросы для самопроверки:
1. Из каких этапов состоит процесс автоматизации?
2. Что является результатом успешного осуществления процесса приобретения программного средства?
3. Какие задачи реашаются в процессе приобретения программного средства?
4. Какие задачи реашаются в процессе подготовки к приобретению программного средства?
5. Какие существуют варианты приобретения программного средства?
6. Что должен содержать план приобретения программного средства?
7. Что включает в себя документация по приобретению программного средства?
8. Какие задачи реашаются в процессе выбора поставщика программного средства?
9. Какие задачи реашаются в процессе заключения соглашения с поставщиком программного средства?
10. Каким образом осуществляется приемка программного средства?
11. Что является результатом успешного осуществления процесса поставки программного средства?
12. Каким образом осуществляется приемка программного средства?
13. Какие задачи реашаются в процессе выполнения контракта на поставку программного средства?
14. Какие основные позиции вкдючает в себя план менеджмента проекта?
Литература по теме :
2. Мацяшек Л.А. Практическая программная инженерия на основе учебного примера / Л.А. Мацяшек, Б.Л. Лионг. – М.: БИНОМ. ЛЗ, 2013. – 956с. («Программисту»).
1. А. Якобсон, Г. Буч, Д. Рамбо. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2008. – 496 с.
2. Соммервил И. Инженерия программного обеспечения. 7-е изд. – М. – СПб. – Киев, 2011. – 623 с.
Практические задания :
Определите оптимальный способ приобретения программного средства исходя из следующих условий. ООО «Леда» занимается оптовой продажей одежды различных производителей. ИТ отдел отсутствует (сопровождение ИТ инфраструктуры отдано на аутсорсинг ООО «ИТ комфорт»), в компании для ведения бухгалтерского учета используется 1С Бухгалтерия, компьютерный парк включает один сервер и 7 персональных компьютеров. Необходимо автоматизировать учет взаимоотношений с клиентами.
Провести анализ представленных на рынке систем автоматизации учета взаимоотношений с клиентами, составить сравнительную таблицу и выбрать оптимальное решение для ООО «Леда», описанного в задании 1.
Тема 2. Процессы проекта внедрения программных средств
Цели и задачи изучения темы:
· Понять составляющие, цели, задачи и результаты успешного завершения процесса планирования внедрения программного средства.
· Освоить процесс оценки рисков разработки и внедрения программного средства.
· Освоить процесс выбора оптимальной стратегии внедрения программного средства.
· Сформировать программу действий, которые должен выполнять м енеджер проекта в отношении процесса планирования проекта.
1. Процесс планирования проекта.
2. Оценка проекта и процесс управления.
3. Процесс менеджмента решений.
4. Процесс менеджмента рисков.
5. Процесс менеджмента конфигурации.
Вопрос 1. Процесс планирования проекта.
Цель процесса планирования проекта состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана.
Этот процесс определяет область применения менеджмента проекта и технических мероприятий, определяет результаты процесса, проектные задачи и поставки, устанавливает графики для выполнения задач проекта, включая критерии достижения и ресурсы, необходимые для выполнения задач проекта.
В результате успешного осуществления процесса планирования проекта:
a. определяется область применения работы для проекта;
b. оценивается возможность достижения конечных целей проекта с имеющимися ресурсами и ограничениями;
c. определяются размеры и оцениваются задачи и ресурсы, необходимые для выполнения работы;
d. идентифицируются интерфейсы между элементами в проекте и с другими проектами и подразделениями организации;
e. разрабатываются планы реализации проекта; и активизируются планы реализации проекта.
Менеджер должен выполнять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса планирования проекта.
Менеджер должен определять требования инициируемого проекта. Определение этих требований включает идентификацию целей, мотиваций и ограничений проекта.
После определения требований проекта менеджер должен оценить осуществимость проекта, проверяя, что ресурсы (персонал, материалы, технологии и окружающая среда), необходимые для выполнения и управления проектом, доступны, адекватны и выделены, а также что сроки завершения проекта достижимы.
По мере необходимости и при согласии всех заинтересованных сторон требования проекта могут быть изменены на этом этапе для достижения критериев завершения.
Менеджер должен подготовить планы для выполнения проекта. Планы, связанные с выполнением проекта, должны включать описания связанных действий и задач и идентификацию программных продуктов, которые будут поставляться. Эти планы должны включать по крайней мере следующее:
a. графики работ для своевременного завершения задач;
c. ресурсы, необходимые для выполнения задач;
d. распределение задач;
e. распределение обязанностей;
f. количественное определение рисков, связанных с задачами или самим процессом;
g. мероприятия по гарантии качества для применения в пределах всего проекта;
h. затраты, связанные с выполнением процесса;
i. обеспечение окружающей среды и инфраструктуры;
j. определение и сопровождение модели жизненного цикла, состоящей из стадий; используя определенные модели жизненного цикла для проектов организации.
Менеджер должен представить заявки на необходимые ресурсы для выполнения проекта.
Менеджер должен инициировать выполнение планов проекта для удовлетворения совокупность целей и критериев, осуществление управления проектом.
Вопрос 2. Оценка проекта и процесс управления.
Цель оценки проекта и процесса управления заключается в определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам.
При необходимости этот процесс включает в себя переориентацию деятельности в рамках проекта, корректировку выявленных отклонений и изменений, связанных с менеджментом других проектов или с техническими процессами. Соответственно, переориентация может включать в себя перепланирование.
В результате успешного осуществления оценки проекта и процесса управления:
a. проводится мониторинг и выпускаются отчеты о развитии проекта;
b. осуществляется мониторинг интерфейсов между элементами в проекте и с другими проектами и подразделениями организации;
c. предпринимаются действия по корректировке отклонений от плана и для предотвращения повторения проблем, выявленных в проекте, если проектные задания не достигнуты;
d. цели проекта достигаются и регистрируются.
Менеджер должен осуществлять следующие виды деятельности в соответствии с применяемыми в организации методиками и процедурами в отношении оценки проекта и процесса управления.
Менеджер должен осуществлять мониторинг полного выполнения проекта, обеспечивая как предоставление внутренних отчетов о продвижении проекта, так и предоставление отчетов приобретающей стороне, как определено в контракте.
Менеджер гарантирует, что внутренние интерфейсы элементов проекта так же, как и интерфейсы с другими проектами и организационными подразделениями, постоянно контролируются в течение этого вида деятельности.
Менеджер должен исследовать, проанализировать и принять решения по проблемам, обнаруженным при выполнении проекта. Решение проблем может привести к изменениям в планах. В обязанности менеджера входит обеспечение гарантии того, что воздействие любых изменений определяется, регулируется и контролируется. Проблемы и их решения должны документироваться.
Менеджер должен представлять отчеты в согласованные сроки о развитии проекта, показывая соблюдение планов и решения в случае остановки в развитии проекта. Они включают внутренние и внешние отчеты, как требуется контрактом и процедурами организации.
Менеджер должен гарантировать, что программные продукты и планы оцениваются для определения выполнения требований.
Менеджер должен определять результаты оценки программных продуктов, действий и задач, завершенных в процессе реализации проекта, для достижения целей и завершения выполнения планов.
Менеджер использует результаты оценки, чтобы принять меры для предотвращения будущих повторений проблем, выявленных в проекте.
Когда все программные продукты, действия и задачи завершаются, менеджер должен определить, закончен ли проект, принимая во внимание критерии, указанные в контракте или установленные как часть процедуры организации.
Эти результаты и отчеты должны быть архивированы в соответствующей среде, как определено в контракте.
Вопрос 3 Процесс менеджмента решений.
Цель процесса менеджмента решений заключается в выборе из существующих альтернатив наиболее предпочтительного направления проектных действий как это представлено на рисунке 4.
Рис. 4. Процесс менеджмента решений
Этот процесс является реакцией на возникающие в течение жизненного цикла системы запросы на принятие решений, направленных на достижение заданных, желаемых или оптимальных результатов вне зависимости от происхождения или источника таких запросов. Альтернативные действия анализируются, выбирается и указывается направление действий. Решения и их обоснования документируются для поддержки принятия будущих решений.
В результате успешного осуществления процесса менеджмента решений:
a. определяется стратегия принятия решений;
b. определяются альтернативные направления действий;
c. выбирается наиболее предпочтительное направление действий;
d. принятое решение, его обоснование и допущения документируются и доводятся до сведения заинтересованных сторон.
В проекте должны реализовываться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента решений.
Проект должен определять стратегию принятия решений. К этой задаче относится определение категории решений, схем установления приоритетов и идентификация ответственных сторон. Также определяются лица, принимающие решения, распределяются обязанности и предоставляются полномочия по принятию решений.
Потребность в принятии решений может возникать вследствие оценки результативности, принятия компромиссных технических решений, наличия проблем, требующих решений, необходимости реагировать на риски, когда их уровень выходит за допустимые пределы, появления новых возможностей или перехода проекта на следующую стадию жизненного цикла. Стратегия принятия решений включает в себя установление и распределение ответственности и полномочий при принятии решений.
Проект должен привлекать заинтересованные стороны к принятию решений для использования их опыта и знаний.
Проект должен устанавливать обстоятельства и необходимость принятия решений. Следует документировать, классифицировать, своевременно и объективно сообщать о проблемах или возможностях и альтернативных направлениях деятельности, которые способны разрешить существующие проблемы.
При реализации проекта необходимо выбирать и объявлять стратегию принятия решения для каждой ситуации, в которой необходимо принять решение. Проект должен определять желаемые результаты и измеримые критерии успешного принятия решений.
При реализации проекта необходимо оценивать баланс последствий альтернативных действий, используя определенную стратегию принятия решений с целью оптимизации или улучшения ситуации принятия решений.
При реализации проекта необходимо регистрировать, отслеживать, оценивать и сообщать о результатах принятия решений для подтверждения эффективности решения проблем, устранения отрицательных тенденций и получения возможных преимуществ.
При реализации проекта необходимо поддерживать записи о проблемах и возможностях их решения, а также размещать записи в соответствии с соглашениями или организационными процедурами, таким образом, который позволяет проводить аудит и изучать полученный опыт.
Вопрос 4. Процесс менеджмента рисков.
Цель процесса менеджмента рисков заключается в постоянном определении, анализе, обработке и мониторинге рисков как это представлено на рисунке 5. Процесс менеджмента рисков является непрерывным процессом для систематичной адресации риска по всему жизненному циклу системного или программного продукта или услуги. Это может быть применимо к рискам, связанным с приобретением, разработкой, сопровождением или применением по назначению системы.
Рис. 5. Процесс менеджмента рисков
В результате успешного осуществления процесса менеджмента рисков:
a. определяется область применения выполняемого менеджмента рисков;
b. определяются и выполняются соответствующие стратегии менеджмента рисков;
c. определяются риски по мере их выявления и в течение проведения проекта;
d. риски анализируются и определяются приоритеты использования ресурсов для обработки этих рисков;
e. определяются, применяются и оцениваются степени риска для установления изменений состояния риска и прогресса в действиях по его обработке;
f. предпринимается обработка для исправления или уклонения от воздействия риска, основанная на его приоритете, вероятности и последствиях или другом определенном пороговом значении риска.
В проекте должны реализоваться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента рисков.
Планирование менеджмента рисков.
Должны быть определены политики менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков.
Описание осуществляемого процесса менеджмента рисков должно быть документировано.
Должны быть определены стороны, ответственные за выполнение менеджмента рисков, их роли и обязанности.
Ответственные стороны должны быть обеспечены ресурсами, достаточными для выполнения процесса менеджмента рисков.
Должно быть предоставлено описание процесса оценки и совершенствования процесса менеджмента рисков.
Менеджмент профиля рисков.
Содержание процесса менеджмента рисков должен быть определено и документировано. Эта задача включает описание перспектив правообладателей, категорий риска и описание (возможно посредством ссылки) технических и управленческих целей, допущений и ограничений.
Должны быть документированы пороговые значения риска, определяющие условия, при которых уровень риска может быть принят.
Должен устанавливаться и поддерживаться профиль рисков. Записи профиля рисков включают: содержание менеджмента рисков; запись каждого состояния риска, включая его вероятность, последствия и пороговые значения риска; приоритет каждого риска, основанный на критериях риска, представленных правообладателями; требования по осуществлению действий, связанных с состоянием и обработкой риска. Профиль рисков обновляется, когда имеются изменения в отдельном состоянии риска. Приоритеты в профиле рисков используются для определения применения ресурсов для обработки.
Содержание соответствующего профиля рисков должно периодически доводиться до сведения правообладателей в зависимости от их потребностей.
Риски должны быть идентифицированы в категориях, описанных в контексте менеджмента рисков.
Должна быть оценена вероятность возникновения и последствия каждого идентифицированного риска.
Каждый риск должен быть оценен по отношению к его пороговым значениям.
Для каждого риска, который находится выше его порогового значения, должны быть определены и документированы рекомендуемые стратегии обработки. Измеримые значения показателей, характеризующих результативность альтернативных вариантов обработки, так же должны быть определены и документированы.
Стратегии обработки риска включают по крайней мере: устранение риска, уменьшение вероятности его появления или серьёзности последствий, или принятие риска.
Правообладатели должны предоставлять рекомендованные альтернативы обработки риска в требованиях на действия по отношению к риску.
Если правообладатели посчитают, что следует предпринять действия, чтобы сделать риск приемлемым, то должна быть реализована альтернатива обработки риска.
Если правообладатели принимают риск, который превышает пороговое значение, то этот риск должен рассматриваться как высоко приоритетный и непрерывно контролироваться для определения необходимых будущих действий по его обработке.
Как только обработка риска выбрана, она должна следовать тем же действиям, что и при менеджменте проблем, в соответствии с действиями по аттестации и управлению.
Все риски и содержание менеджмента рисков должны подвергаться мониторингу для выявления изменений. В случае изменения состояния риска должна быть выполнена его оценка.
Для оценки результативности обработки риска должны разрабатываться и контролироваться соответствующие измеримые показатели.
В течение всего жизненного цикла проекта должен осуществляться постоянный мониторинг возникновения новых рисков и их источников.
Оценка процесса менеджмента рисков.
Должна собираться информация в течение всего жизненного цикла проекта для целей улучшения процесса менеджмента рисков и извлечения практических уроков.
Информация о рисках включает идентифицированные риски, их источники, причины, обработку и примеры успешного применения выбранных вариантов обработки.
Процесс менеджмента рисков должен периодически пересматриваться в плане его результативности и эффективности.
Информация об идентифицированных рисках, их обработке и примерах успешной обработки должна периодически пересматриваться с целью выявления системных проектных и организационных рисков.
Вопрос 5. Процесс менеджмента конфигурации.
Цель процесса менеджмента конфигурации состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны.
В результате успешного осуществления процесса менеджмента конфигурации:
a. определяется стратегия менеджмента конфигурации;
b. определяются составные части, нуждающиеся в менеджменте конфигурации;
c. устанавливается базовая линия конфигурации;
d. осуществляется управление изменениями в составных частях, находящихся под менеджментом конфигурации;
e. осуществляется управление конфигурацией составных частей, входящих в выпуск;
f. статус составных частей, на которые распространяется менеджмент конфигурации, становится доступным на протяжении всего жизненного цикла.
В проекте должны осуществляться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента конфигурации.
Планирование менеджмента конфигурации.
В проекте должна быть определена стратегия менеджмента конфигурации.
В проекте должны быть идентифицированы составные части, которые являются предметом управления конфигурацией.
Составные части, где это необходимо, различаются уникальными долговременными идентификаторами или маркировками. Идентификаторы должны соответствовать стандартам и соглашениям производственного сектора таким образом, чтобы составные части, находящиеся под управлением конфигурации, однозначно соответствовали своим спецификациям или их эквивалентам, документированным описаниям.
Осуществление менеджмента конфигурации.
Проект должен поддерживать информацию о конфигурации на приемлемом уровне целостности и защищенности.
При решении этой задачи необходимо учитывать особенности составных частей, находящихся под управлением конфигурацией.
Конфигурация описывает, где это возможно, соответствие с технологическими стандартами или стандартами на продукцию. Необходимо гарантировать, что информация о конфигурации позволяет иметь прямую и обратную прослеживаемость к другим состояниям конфигурации, описываемым базовой линией.
Необходимо объединять развивающиеся состояния составных частей конфигурации для формирования документированной базовой линии на определенные моменты времени или при определенных обстоятельствах.
Необходимо регистрировать обоснования для базовой линии и связанных с этим полномочий по отношению к данным о базовой линии конфигурации.
Необходимо поддерживать записи о конфигурации в течение всего жизненного цикла системы и архивировать их в соответствии с соглашениями, законодательством или передовым производственным опытом.
При реализации проекта необходимо гарантировать, что изменения базовой линии конфигурации соответствующим образом идентифицируются, регистрируются, оцениваются, утверждаются, внедряются и верифицируются.
Эта задача также может включать:
a. объединение в процессе развития конфигурации состояний ее составных частей для формирования документированной базовой линии на определенный момент времени или при определенных обстоятельствах;
b. регистрацию состояний конфигурации, обоснования для базовой линии и связанных с этим полномочий по отношению к данным о базовой линии конфигурации;
c. поддержку записей о конфигурации в течение всего жизненного цикла системы и архивирование в соответствии с соглашениями, законодательством или наилучшей производственной практикой;
d. управление выполнением записей, изменениями и утверждениями текущего статуса конфигурации и статуса всех предыдущих конфигураций для подтверждения корректности, своевременности, целостности и защищенности информации;
e. проведение аудита для проверки соответствия базовой линии чертежам, документам по управлению интерфейсами и другим согласованным требованиям.
Вопросы для самопроверки:
1. Что является результатом успешного осуществления процесса планирования проекта?
2. Кто и как инициирует проект внедрения программного средства?
3. Что включают в себя планы по внедрению программного средства?
4. Что является результатом успешного осуществления процесса оценки проекта?
5. Какие виды деятельности и как должен осуществлять менеджер проекта в отношении оценки проекта и процесса управления проектом?
6. Что является результатом успешного осуществления процесса менеджмента решений проекта?
7. Какие виды деятельности и как должны реализовываться в отношении процесса менеджмента решений проекта?
8. Что является результатом успешного осуществления процесса менеджмента рисков проекта?
9. Какие виды деятельности и как должны реализовываться в отношении процесса менеджмента рисков проекта?
10. Каким образом устанавливается и поддерживается профиль рисков проекта?
11. Что является результатом успешного осуществления процесса менеджмента конфигурации проекта?
12. Какие виды деятельности и как должны реализовываться в отношении процесса менеджмента конфигурации проекта?
Литература по теме :
2. Мацяшек Л.А. Практическая программная инженерия на основе учебного примера / Л.А. Мацяшек, Б.Л. Лионг. – М.: БИНОМ. ЛЗ, 2013. – 956с. («Программисту»).
1. А. Якобсон, Г. Буч, Д. Рамбо. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2008. – 496 с.
2. Соммервил И. Инженерия программного обеспечения. 7-е изд. – М. – СПб. – Киев, 2011. – 623 с.
Практические задания :
Определите возможные риски разработки и внедрения программного средства автоматизации учета продаж и пути их предотвращения для представленной компании. Сформируйте таблицу возможных дефектов программного средства и определите пути снижения вероятности их возникновения.
Разработку программного средства будет осуществлять штатный программист в функции которого также входит системное администрирование и сопровождение как программного, так и аппаратного обеспечения ООО «Компьютерный мир». Компьютерный парк компании включает 1 сервер, 5 персональных компьютеров (к одному из которых подключен кассовый аппарат), 3 принтера, свитч.
Для ООО «Компьютерный мир», описанного в задании 1, определите оптимальную стратегию внедрения разработанного программного средства.
Тема 3. Процессы реализации программных средств
Цели и задачи изучения темы:
· Понять составляющие, цели, задачи и результаты успешного завершения процесса реализации (разработки) программного средства.
· Освоить процесс формулирования требований к определению прав доступа пользователей программного средства.
· Освоить процесс разработки требований к интерфейсу программного средства.
1. Процесс реализации.
2. Процесс анализа требований к программным средствам.
3. Процесс проектирования архитектуры программных средств.
4. Процесс детального проектирования программных средств.
5. Процесс конструирования программных средств.
6. Процесс комплексирования программных средств.
7. Процесс квалификационного тестирования программных средств.
Вопрос 1. Про цесс реализации.
Цель процесса реализации программных средств заключается в создании заданных элементов системы, выполненных в виде программных продуктов или услуг. В ходе этого процесса происходит преобразование заданных поведенческих, интерфейсных и производственных ограничений в действия, которые создают системный элемент, выполненный в виде программного продукта или услуги, иначе известный как «программный элемент».
Результатом процесса является создание программной составной части, удовлетворяющей как требованиям к архитектурным решениям, что подтверждается посредством верификации, так и требованиям правообладателей, что подтверждается посредством валидации.
В результате успешного осуществления процесса реализации программных средств:
a. определяется стратегия реализации;
b. определяются ограничения по технологии реализации проекта;
c. изготавливается программная составная часть;
d. программная составная часть упаковывается и хранится в соответствии с соглашением о ее поставке.
В дополнение к этим действиям, процесс реализации программных средств имеет следующие процессы более низкого уровня:
· Процесс анализа требований к программным средствам.
· Процесс проектирования архитектуры программных средств.
· Процесс детального проектирования программных средств.
· Процесс конструирования программных средств.
· Процесс комплексирования программных средств.
· Процесс квалификационного тестирования программных средств.
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса реализации программных средств.
Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла, соответствующую области применения, размерам и сложности проекта. Модель жизненного цикла должна содержать стадии, цели и выходы каждой стадии. Виды деятельности и задачи процесса реализации программных средств должны быть выбраны и отражены в модели жизненного цикла. Эти виды деятельности и задачи могут пересекаться или взаимодействовать друг с другом, могут выполняться итеративно или рекурсивно.
a. документировать результаты в соответствии с процессом менеджмента программной документации;
b. передавать результаты в процесс менеджмента конфигурации программных средств и выполнять управление изменениями в соответствии с ним;
c. документировать, решать проблемы и снимать несоответствия, найденные в программных продуктах и задачах в соответствии с процессом решения проблем в программных средствах;
d. выполнять поддержку процессов, как определено в контракте;
e. устанавливать базовые линии и соединять элементы конфигурации в сроки, определенные приобретающей стороной и поставщиком.
Исполнитель должен выбирать, адаптировать и применять те стандарты, методы, инструментарий и языки программирования (если не оговорено в контракте), которые документально оформлены, являются подходящими и установлены организацией для выполнения действий процесса реализации программных средств и поддерживающих процессов.
Исполнитель должен разрабатывать планы проведения действий процесса реализации программных средств. Планы должны включать конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту. При необходимости, могут разрабатываться отдельные планы. Эти планы должны документироваться и выполняться.
При разработке или сопровождении программных продуктов могут применяться непоставляемые элементы. Однако, должно гарантироваться, что функционирование и сопровождение поставляемых программных продуктов после поставки приобретающей стороне не зависит от таких элементов; другими словами, эти элементы следует также рассматривать как поставляемые.
Вопрос 2. Процесс анализа требований к программным средствам.
Цель процесса анализа требований к программным средствам заключается в установлении требований к программным элементам системы.
В результате успешного осуществления процесса анализа требований к программным средствам:
a. определяются требования к программным элементам системы и их интерфейсам;
b. требования к программным средствам анализируются на корректность и тестируемость;
c. осознается воздействие требований к программным средствам на среду функционирования;
b. устанавливается совместимость и прослеживаемость между требованиями к программным средствам и требованиями к системе;
a. определяются приоритеты реализации требований к программным средствам;
b. требования к программным средствам принимаются и обновляются по мере необходимости;
c. оцениваются изменения в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям;
d. требования к программным средствам воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон.
При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса анализа требований к программным средствам.
Исполнитель должен установить и документально оформить следующие требования к программным средствам (включая спецификации характеристик качества):
a. спецификации функциональных характеристик и возможностей, включая эксплуатационные,
b. физические характеристики и условия окружающей среды, при которых будет применяться программная составная часть;
c. внешние интерфейсы к программной составной части;
d. квалификационные требования;
e. спецификации по безопасности, включая те спецификации, относящиеся к методам функционирования и сопровождения, влиянию окружающей среды и ущербу для персонала;
f. спецификации по защите, включая спецификации, связанные с угрозами для чувствительной информации;
g. спецификации эргономических факторов, включая спецификации, связанные с ручными операциями, взаимодействием человек-оборудование, ограничениями по персоналу и областям, требующим концентрации внимания и чувствительным к ошибкам человека и уровню его обученности;
h. описание данных и требования к базам данных;
i. инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения;
j. требования к документации пользователя;
k. операции пользователя и требования к их выполнению;
l. пользовательские требования к сопровождению.
Исполнитель должен оценить требования к программным средствам, учитывая критерии, перечисленные ниже. Результаты оценок должны быть документально оформлены:
a. прослеживаемость к системным требованиям и к системному проекту;
b. внешняя согласованность с системными требованиями;
c. внутренняя согласованность;
e. осуществимость программного проекта;
f. осуществимость функционирования и сопровождения.
Исполнитель должен проводить ревизии. Вслед за успешной оценкой и ревизией следует принимать требования к программным средствам, закреплять их в базовой линии и сообщать об этом всем заинтересованным сторонам. Последующие изменения в базовой линии требований к программным средствам следует оценивать по стоимости, графикам исполнения и воздействиям технических решений.
Вопрос 3. Процесс проектирования архитектуры программных средств.
Цель процесса проектирования архитектуры программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований.
В результате успешной реализации процесса проектирования архитектуры программных средств:
a. разрабатывается проект архитектуры программных средств и устанавливается базовая линия, описывающая программные составные части, которые будут реализовывать требования к программным средствам;
b. определяются внутренние и внешние интерфейсы каждой программной составной части;
c. устанавливается согласованность и прослеживаемость между требованиями к программным средствам и программным проектом.
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса проектирования архитектуры программных средств.
Исполнитель должен преобразовать требования к программным составным частям в архитектуру, которая описывает верхний уровень его структуры и идентифицирует программные компоненты. Необходимо гарантировать, что все требования к программным составным частям распределяются по программным компонентам и в дальнейшем уточняются для облегчения детального проектирования. Архитектуру программной составной части необходимо документировать.
Исполнитель должен разработать и документально оформить проект верхнего уровня для внешних интерфейсов программной составной части и интерфейсов между ней и программными компонентами.
Исполнитель должен разработать и документально оформить проект верхнего уровня для базы данных.
Исполнитель должен разработать и документально оформить предварительные версии пользовательской документации.
Исполнитель должен определить и документировать требования к предварительному тестированию и график работ по комплексированию программных средств.
a. прослеживаемость к требованиям программной составной части;
b. внешняя согласованность с требованиями программной составной части;
c. внутренняя согласованность между программными компонентами;
d. приспособленность методов проектирования и используемых стандартов;
e. осуществимость детального проектирования;
f. осуществимость функционирования и сопровождения.
Результаты оценок следует документально оформлять.
Вопрос 4. Процесс детального проектирования программных средств.
Цель процесса детального проектирования программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования.
В результате успешного осуществления процесса детального проектирования программных средств:
a. разрабатывается детальный проект каждого программного компонента, описывающий создаваемые программные модули;
b. определяются внешние интерфейсы каждого программного модуля;
c. устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры.
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса детального проектирования программных средств.
Для каждой программной составной части (или составной части конфигурации, если она определена) данный вид деятельности состоит из решения следующих задач.
Исполнитель должен разработать детальный проект для каждого программного компонента программной составной части. Программные компоненты должны быть детализированы на более низком уровне, включающем программные блоки, которые могут быть закодированы,откомпилированы и проверены. Следует гарантировать, что все требования к программным средствам распределяются от программных компонентов к программным блокам. Детальный проект должен быть документально оформлен.
Исполнитель должен разработать и документально оформить детальный проект для внешних интерфейсов к программным составным частям, между программными компонентами и между программными блоками. Необходимо, чтобы детальный проект для интерфейсов позволял проводить кодирование без потребности в получении дополнительной информации.
Исполнитель должен разработать и документально оформить детальный проект базы данных.
Исполнитель должен совершенствовать пользовательскую документацию по мере необходимости.
Исполнитель должен определять и документировать требования к тестированию и графики работ по тестированию программных блоков. Необходимо, чтобы требования к тестированию включали проведение проверок программных блоков при граничных значениях параметров, установленных в требованиях.
Исполнитель должен обновлять требования к тестированию и графики работ по комплексированию программных средств.
Исполнитель должен оценивать детальный проект для программных средств и требования к тестированию по перечисленным ниже критериям:
a. прослеживаемость к требованиям программной составной части;
b. внешняя согласованность с архитектурным проектом;
c. внутренняя согласованность между программными компонентами и программными блоками;
d. соответствие методов проектирования и используемых стандартов;
e. осуществимость тестирования;
f. осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
Вопрос 5. Процесс конструирования программных средств.
Цель процесса конструирования программных средств заключается в создании исполняемых программных блоков, которые должным образом отражают проектирование программных средств.
В результате успешного осуществления процесса конструирования программных средств:
a. определяются критерии верификации для всех программных блоков относительно требований;
b. изготавливаются программные блоки, определенные проектом;
c. устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом;
d. завершается верификация программных блоков относительно требований и проекта.
При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса конструирования программных средств.
Исполнитель должен разработать и документально оформить:
a. каждый программный блок и базу данных;
b. процедуры тестирования и данные для тестирования каждого программного блока и базы данных.
Исполнитель должен тестировать каждый программный блок и базу данных, гарантируя, что они удовлетворяют требованиям. Результаты тестирования должны быть документально оформлены.
Исполнитель должен улучшать документацию пользователя при необходимости.
Исполнитель должен совершенствовать требования к тестированию и графики работ по комплексированию программных средств.
Исполнитель должен оценивать программный код и результаты испытаний, учитывая следующие критерии:
a. прослеживаемость к требованиям и проекту программных элементов;
b. внешняя согласованность с требованиями и проектом для программных составных частей;
c. внутренняя согласованность между требованиями к блокам;
d. тестовое покрытие блоков;
e. соответствие методов кодирования и используемых стандартов;
f. осуществимость комплексирования и тестирования программных средств;
g. осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
Вопрос 6. Процесс комплексирования программных средств.
Цель процесса комплексирования программных средств заключается в объединении программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с проектом программных средств, которые демонстрируют, что функциональные и нефункциональные требования к программным средствам удовлетворяются на полностью укомплектованной или эквивалентной ей операционной платформе.
В результате успешного осуществления процесса комплексирования программных средств:
a. разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и с расположенными по приоритетам требованиями к программным средствам;
b. разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями;
c. программные составные части верифицируются с использованием определенных критериев;
d. программные составные части, определенные стратегией комплексирования, изготавливаются;
e. регистрируются результаты комплексного тестирования;
f. устанавливается согласованность и прослеживаемость между программным проектом и программными составными частями;
g. разрабатывается и применяется стратегия регрессии для повторной верификации программных составных частей при возникновении изменений в программных блоках (в том числе, в соответствующих требованиях, проекте и кодах).
При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса комплексирования программных средств.
Исполнитель должен разработать план комплексирования для объединения программных блоков и программных компонентов в программную составную часть. План должен включать требования к тестированию, процедуры, данные, обязанности и графики работ. План должен быть документально оформлен.
Исполнитель должен объединить программные блоки, программные компоненты и тесты, поскольку они разрабатываются в соответствии с планом комплексирования. Должны быть гарантии, что каждая такое объединение удовлетворяет требованиям к программной составной части и что она комплексируется при завершении этого действия. Результаты комплексирования и тестирования должны быть документально оформлены.
Должна быть разработана стратегия регрессии для применения повторной верификации программных элементов в случае, когда изменения проводятся в программных блоках, включая соответствующие требования, проект и коды.
Исполнитель должен обновлять пользовательскую документацию по мере необходимости.
Исполнитель должен разработать и документально оформить для каждого квалификационного требования к программной составной части комплект тестов, тестовых примеров (входов, результатов, критериев тестирования) и процедур тестирования для проведения квалификационного тестирования программных средств. Разработчик должен гарантировать, что после комплексирования программная составная часть готова к квалификационному тестированию.
Исполнитель должен оценить план комплексирования, проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая следующие критерии:
a. прослеживаемость к системным требованиям;
b. внешняя согласованность с системными требованиями;
c. внутренняя согласованность;
d. тестовое покрытие требований к программной составной части;
e. приспособленность используемых методов и стандартов тестирования;
f. соответствие с ожидаемыми результатами;
g. осуществимость квалификационного тестирования программных средств;
h. осуществимость функционирования и сопровождения.
Вопрос 7. Процесс квалификационного тестирования программных средств.
Цель процесса квалификационного тестирования программных средств заключается в подтверждении того, что комплексированный программный продукт удовлетворяет установленным требованиям.
В результате успешного осуществления процесса квалификационного тестирования программных средств:
a. определяются критерии для комплексированных программных средств с целью демонстрации соответствия с требованиями к программным средствам;
b. комплексированные программные средства верифицируются с использованием определенных критериев;
c. записываются результаты тестирования;
d. разрабатывается и применяется стратегия регрессии для повторного тестирования комплексированного программного средства при проведении изменений в программных составных частях.
Исполнитель должен проводить квалификационное тестирование в соответствии с квалификационными требованиями к программному элементу. Должна обеспечиваться гарантия того, что реализация каждого требования к программным средствам тестируется на соответствие.
Рис. 6. Процесс квалификационного тестирования
Результаты квалификационного тестирования должны быть документально оформлены.
Исполнитель должен обновлять пользовательскую документацию по мере необходимости.
Исполнитель должен оценивать проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая перечисленные ниже критерии:
a. тестовое покрытие требований к программной составной части;
b. соответствие с ожидаемыми результатами;
c. осуществимость системного комплексирования и тестирования, если они проводятся;
d. осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
Исполнитель должен поддерживать проведение аудитов. Результаты аудитов должны быть документально оформлены. Если и технические и программные средства разрабатываются или комплексируются, то аудиты могут быть отсрочены до тех пор, пока не будет выполнено системное квалификационное тестирование.
После успешного завершения аудитов, если они проводились, исполнитель должен обновить и подготовить поставляемый программный продукт для системного комплексирования, системного квалификационного тестирования, инсталляции программных средств или поддержки приемки программных средств.
Вопросы для самопроверки:
1. Что является результатом успешного осуществления процесса реализации программных средств?
2. Каковы обязанности исполнителя в процессе реализации программных средств?
3. Что является результатом успешного осуществления процесса анализа требований к программным средствам?
4. Какие виды деятельности необходимо осуществлять в отношении процесса анализа требований к программным средствам?
5. Какие требования к программным средствам должен установить и документально оформить исполнитель?
6. Что является результатом успешного осуществления процесса проектирования архитектуры программных средств?
8. Что является результатом успешного осуществления процесса детального проектирования программных средств?
9. Какие виды деятельности необходимо осуществлять в отношении процесса детального проектирования программных средств?
10. Какие существуют критерии оценки детального проекта для программных средств и требований к тестированию?
11. Что является результатом успешного осуществления процесса конструирования программных средств?
12. Какие виды деятельности необходимо осуществлять в отношении процесса конструирования программных средств?
13. Что является результатом успешного осуществления процесса комплексирования программных средств?
14. Каковы обязанности исполнителя в процессе комплексирования программных средств?
15. Что является результатом успешного осуществления процесса квалификационного тестирования программных средств?
16. Какие существуют критерии оценки проекта, программного кода, тестов, результатов тестирования, а также пользовательской документации?
Литература по теме :
2. Мацяшек Л.А. Практическая программная инженерия на основе учебного примера / Л.А. Мацяшек, Б.Л. Лионг. – М.: БИНОМ. ЛЗ, 2013. – 956с. («Программисту»).
1. Орлов С. Технологии разработки программного обеспечения. – СПб.: Питер, 2010. – 480 с.
2. С. Макконнелл. Совершенный код. – СПб: Питер, 2009. – 896 с.
3. С. Канер, Д. Фолк, Е. Нгуен. Тестирование программного обеспечения: – К., Диасофт, 2010. – 544 с.
Практические задания :
Для задачи автоматизации учета продаж в ООО «Компьютерный мир», описанного в задании 1 темы 2 определите требования по ограничению прав доступа к различным областям разрабатываемого программного средства. Результаты оформите в виде таблицы.
Для задачи автоматизации учета продаж в ООО «Компьютерный мир», описанного в задании 1 темы 2 определите требования по интерфейсу (меню) системы. Результаты оформите в виде сценария диалога.