Договоры на разработку программного обеспечения. Неочевидные риски и способы их избежать

Основные риски в процессах разработки программного обеспечения

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

На основе изучения «ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств» были выявлены основные процессы разработки программного обеспечения:

• выявление и анализ требований;
• проектирование программного обеспечения;
• программирование;
• тестирование программного обеспечения.

Выявление и анализ требований

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

Это связано с природой разработки программного обеспечения: выполняемая работа базируется на ранее выполненной.

Например, проектирование выполняется на основе требований, программирование реализуется на основе модели проектирования, а тестирование производится на основе написанного текста программы.

1. Двусмысленные требования

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

Проектирование

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

1. Сложность архитектуры программного обеспечения

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

2. Неудобный пользовательский интерфейс

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

Именно через интерфейс пользователь судит о программе в целом; более того, часто решение об использовании программного обеспечения пользователь принимает по тому, насколько ему удобен и понятен пользовательский интерфейс.

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

3. Неправильная структура базы данных

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

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

4. Неоптимальный выбор структур данных

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

5. Неоптимальный выбор языка программирования

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

• целевая платформа;
• гибкость языка;
• время реализации;
• производительность;
• сопровождение программного обеспечения;
• предметная область разрабатываемой системы;
• необходимость в использовании библиотек;
• опыт разработчиков.

Программирование

Основные риски на этапе программирования описаны ниже.

1. Изобретение «велосипеда»

Написание кода без использования возможностей языка и существующих библиотек.

2. Нечитаемый код

Последствие этого риска – трудность в изменении и сопровождении программного обеспечения.

3. Создание программных закладок

Программная закладка – это внесенные в программное обеспечение функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций, позволяющих осуществлять несанкционированные воздействия на информацию [1].

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

В большинстве случаев закладки успешно использовались злоумышленниками и были обнаружены уже после активации.

4. Нерегулярное резервное копирование кода

Последствие этого риска очень масштабно.

Тестирование

На этапе тестирования возможны следующие риски:

• неэффективный выбор методов тестирования;
• требования не ранжированы по приоритетам;
• не используются протоколы тестирования.

Список литературы

1. ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. — Москва: Изд-во стандартов, 2003. – 12 с.
2. ДеМарко Т., Листер Т. Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения. — М.: Компания p.m.Office, 2005. – 208 с.

Источник: https://habr.com/sandbox/105470/

Основные пять рисков проектов разработки программного обеспечения

Управление рисками (точнее, избегание рисков) является критической темой, но зачастую ею пренебрегают и опускают.

Одной из немногих полезных и интересных книг на данную тему является книга “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения”, написанная Томом ДеМарко и Тимоти Листером.

Данная статья предоставляет краткое описание пяти основных рисков проектов по разработке ПО, обсуждаемых в книге.

Притом , что книга не фокусируется на гибкой методологии разработки (Agile), стоит отметить, что основные пять определенных рисков, сопровождающих проекты по разработке ПО, в данной  книге имеют решения, корни которых находятся именно в гибкой методологии. ДеМарко и Листер описывают следующие пять основных рисков и стратегий, позволяющих их избежать:

Риск 1: ошибки, присущие расписанию  

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

Решение из книги: все больше вовлекайте команду в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком.

Гибкий метод: в проектах, использующих гибкую методологию, команда активно вовлечена в планирование  и оценку посредством таких действий, как  экстремальное программирование (Extreme Programming, XP) и семинары Wideband Delphi. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто  на данный момент более вовлечен в проект. Вкратце, настоящий прогресс сложно скрыть от владельцев.

Риск 2: появление новых требований

Описание: по ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.

Решение из книги: постоянное вовлечение клиентов и разработчиков.

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

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

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

Риск 3: смена сотрудников

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

Решение из книги: высокий уровень сотрудничества и обмена информацией в команде.

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

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

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

Риск 4: декомпозиция спецификации

Описание: при старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.

Решение из книги: наймите преданного менеджера по продукции для осуществления критических договоров и решений.

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

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

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

Риск 5: низкая продуктивность

Описание:наличие впереди длительных сроков приводит к тому, что на ранних стадиях зачастую отсутствует  чувство срочности в работе, а это  в результате дает в начале проекта  потерю времени, которое уже нельзя вернуть .

Решение из книги : короткие итерации, нужные люди в команде, лидерство и развитие команды.

Гибкий метод:гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах.

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

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

Заметка по гибкой методологии

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

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

Mike Griffiths

Newer news items:

Older news items:

Источник: http://www.pmtoday.ru/project-management/risks/top-five-risks.html

Догоовр на разработку программного обеспеченпия

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

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

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

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

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

Риск возникновения исключительного права у третьих лиц.

Как выбрать договор на разработку ПО

Таким образом, при выборе конструкции договора необходимо обращать внимание на следующие моменты: 1) что является непосредственным предметом заказа, и 2) кто выступает на стороне исполнителя. Если предмет заказа – конкретное программное обеспечение, договор на услуги не подходит, т.к.

последний направлен на деятельность определенного рода, в которой результат имеет вторичную роль.

Какие риски несут стороны в случае ошибки при заключении договора?

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

Договор разработки программного обеспечения

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

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

Договор на разработку программы по свое правовой природе является взаимным, консенсуальным, возмездным. Договор на разработку программного обеспечения является одним из видов договора подряда и к нему применяют общие нормы главы 37 Гражданского Кодекса РФ.

Заказчиком может стать любое физическое лицо, индивидуальный предприниматель, юридическое лицо. Исполнителем может выступать какие-либо индивидуальный предприниматель, физическое лицо, юридическое лицо. В согласии с пунктом 1 статьи 1228 Гражданского Кодекса РФ изначально исключительное право на программный продукт принадлежит автору, которым может стать лишь физическое лицо.

Однако исключительное право на программное обеспечение можно передать другим лицам (индивидуальному предпринимателю, юридическому лицу) по основаниям, которые установлены законом РФ (пункт 3 статьи 1228), а именно лицензионным договором и договором об отчуждении исключительного права (статья 1233 Гражданского Кодекса РФ). Согласно статьи 1297 Гражданского Кодекса РФ, когда по соглашению сторон исключительное право на программное обеспечение принадлежит:

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

Договор на программное обеспечение имеет такие существенные условия: 1. Предметом является список работ по разработке программного обеспечения на основании технического задания.

Еще в образце договора на создание программного обеспечения можно указать другие условия – ответственность сторон, срок действия соглашения, порядок расторжения и изменения договора, форс-мажор и так далее.

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

Источник: http://ros-trud.ru/dogoovr-na-razrabotku-programmnogo-obespechenpija-67493/

Проблемы качества программного обеспечения и практические рекомендации

Айя Элгебели
28.11.2013

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

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

Софтверные компании, стремящиеся к достижению удовлетворенности клиентов, часто сталкиваются со сложными проблемами поставки высококачественных продуктов.

Качество программного обеспечения как необходимость

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

Поэтому очень важно вовлечь группы контроля качества в процесс планирования и реализации проектов с самого начала.

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

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

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

Сегодня софтверным компаниям необходимо заботиться о качестве своей продукции как никогда ранее.

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

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

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

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

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

Следует отметить, что компании не обязаны следовать каким-либо конкретным стандартам разработки ПО или определенным процессам.

Существуют различные стандарты типичного цикла разработки ПО (software development life cycle – SLDC), такие как IEEE, ISO – 12207 и CMMI.

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

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

Игнорирование стандартов не равноценно снижению качества программного обеспечения и уменьшению спроса на конечный продукт (если это не жизненно важные программы, такие как медицинское ПО, которое требует одобрения FDA внутри США и должно соответствовать одному из стандартов).

Проблема не в следовании стандартам. Проблема в игнорировании или принижении значения качества ПО.

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

Методики обеспечения качества ПО в рамках всего жизненного цикла разработки

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

Анализ требований

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

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

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

Анализ и сквозной контроль кода

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

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

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

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

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

Сессионное тестирование

Методика сессионного тестирования, разработанная Джеймсом Бахом (James Bach), заключается в разделении тестовой нагрузки на сеансы, каждый из которых решает свою задачу (получение четко определенных результатов, ожидаемых от данного сеанса). Каждый сеанс имеет определенную продолжительность (от 20 до 40 минут), и тестировщик должен работать непрерывно в течение сеанса.

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

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

После завершения сеанса его стенограмма обсуждается с руководителем группы или техническим менеджером.

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

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

Рисунок 1. Процесс сессионного тестирования

Кликните, чтобы увидеть увеличенное изображение

Тестирование, основанное на рисках

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

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

Исправление ошибки в каком-нибудь фрагменте может нарушить в коде что-нибудь еще.

Компромиссным вариантом является тестирование, основанное на рисках.

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

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

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

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

Низкое качество проявляется только когда программное обеспечение перестает работать.

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

Ресурсы для скачивания

Источник: https://www.ibm.com/developerworks/ru/library/r-software-quality-challenges-practice-recommendations/