Software developer

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:48, 2 июня 2017.

Разработка программного обеспечения (Software developer [Источник 1])- деятельность связанная с созданием нового программного обеспечения. Разработка программного обеспечения как инженерная дисциплина является областью программной инженерии, на ряду с которой выступают дисциплины, отвечающими за функционирование и поддержку программных продуктов.

Разработка программного обеспечения
  • Процесс разработки ПО
Модели
Методологии
  • Agile (XP, Lean, Scrum, FDD и др.)
  • Cleanroom
  • OpenUP
  • RAD
  • RUP
  • MSF
  • DSDM
  • TDD
Сопутствующие дисциплины
  • Конфигурационное управление
  • Управление проектами
  • Управление требованиями
  • Обеспечение качества

Процесс разработки ПО

В первую очередь это структура, согласно которой построена разработка программного обеспечения [Источник 2] (ПО). Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.

Шаги процесса

Процесс разработки [Источник 3] состоит из множества подпроцессов, или дисциплин, некоторые из которых показаны ниже. В модели водопада они идут одна за другой, в других аналогичных процессах их порядок или состав изменяется.

  • Анализ требований → Спецификация программного обеспечения
  • Проектирование программного обеспечения
  • Программирование
  • Тестирование программного обеспечения
  • Системная интеграция (System integration)
  • Внедрение программного обеспечения (или Установка программного обеспечения)
  • Сопровождение программного обеспечения

Модели процесса

Водопадная (каскадная, последовательная) Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Этапы проекта в соответствии с каскадной моделью;

  1. Формирование требований;
  2. Проектирование;
  3. Реализация;
  4. Тестирование;
  5. Внедрение;
  6. Эксплуатация и сопровождение.

Преимущества:

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

Недостатки: [Источник 4] В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем

Итерационная модель Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью. Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция — приём, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже». Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP). Спиральная модель. Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации оцениваются:

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

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

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

  1. Дефицит специалистов.
  2. Нереалистичные сроки и бюджет.
  3. Реализация несоответствующей функциональности.
  4. Разработка неправильного пользовательского интерфейса.
  5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
  6. Непрекращающийся поток изменений.
  7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
  8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
  9. Недостаточная производительность получаемой системы.
  10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек:

  1. Concept of Operations (COO) — концепция (использования) системы;
  2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
  3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
  4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
  5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Сложность разработки ПО

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

Методологии

Методология — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Конкретные вещи реализуется через выбранную методологию[Источник 5] Именно она определяет, как будет выполняться разработка. Существует много успешных методологий создания программного обеспечения. Выбор конкретной методологии зависит от размера команды, от специфики и сложности проекта, от стабильности и зрелости процессов в компании и от личных качеств сотрудников. Методологии представляют собой ядро теории управления разработкой программного обеспечения. К существующей классификации в зависимости от используемой в ней модели жизненного цикла (водопадные и итерационные методологии) добавилась более общая классификация на прогнозируемы и адаптивные методологии. Прогнозируемые методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по «управлению изменениями», чтобы в проекте учитывались только самые важные требования. Адаптивные методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах.

SCRUM

SCRUM - методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течение следующего спринта. Самые важные условия — неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют — scrum, результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать.

KANBAN

KANBAN - гибкая методология разработки программного обеспечения, ориентированная на задачи. Основные правила:

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

Преимущества KANBAN:

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

DYNAMIC SYSTEM DEVELOPMENT METHOD

DYNAMIC SYSTEM DEVELOPMENT METHOD - появился в результате работы консорциум из 17 английских компаний. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент.

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

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

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

MICROSOFT SOLUTIONS FRAMEWORK

MICROSOFT SOLUTIONS FRAMEWORK - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

Базовые концепции и принципы модели процессов MSF:

  1. единое видение проекта — все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта;
  2. управление компромиссами — поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями;
  3. гибкость – готовность к изменяющимся проектным условиям;
  4. концентрация на бизнес-приоритетах — сосредоточенность на той отдаче и выгоде, которую ожидает получить потребитель решения;
  5. поощрение свободного общения внутри проекта;
  6. создание базовых версии — фиксация состояния любого проектного артефакта, в том числе программного кода, плана проекта, руководства пользователя, настройки серверов и последующее эффективное управление изменениями, аналитика проекта.

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

RATIONAL UNIFIED PROCESS

RATIONAL UNIFIED PROCESS - методология разработки программного обеспечения, созданная компанией Rational Software. В основе методологии лежат 6 основных принципов:

  1. компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта;
  2. работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам;
  3. ранняя идентификация и непрерывное устранение возможных рисков;
  4. концентрация на выполнении требований заказчиков к исполняемой программе;
  5. ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки;
  6. постоянное обеспечение качества на всех этапах разработки проекта.

Использование методологии RUP направлено на итеративную модель разработки. Особенность методологии состоит в том, что степень формализации может меняться в зависимости от потребностей проекта. Можно по окончании каждого этапа и каждой итерации создавать все требуемые документы и достигнуть максимального уровня формализации, а можно создавать только необходимые для работы документы, вплоть до полного их отсутствия. За счет такого подхода к формализации процессов методология является достаточно гибкой и широко популярной. Данная методология применима как в небольших и быстрых проектах, где за счет отсутствия формализации требуется сократить время выполнения проекта и расходы, так и в больших и сложных проектах, где требуется высокий уровень формализма, например, с целью дальнейшей сертификации продукта. Это преимущество дает возможность использовать одну и ту же команду разработчиков для реализации различных по объему и требованиям.

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

Проблемы разработки ПО

Основными проблемами являются:

  1. Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения. Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, при планировании необходимо учесть, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
  2. Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы.
  3. Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени.
  4. Неконтролируемые изменения. У заказчика постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные исполнителем. Данная проблема возникает вследствие того, что заказчик не продумал хорошо, на этапе проектирования программы, её функциональное назначения (операции, которые она будет выполнять и т.д).
  5. Самый сложный этап — поиск и исправление ошибок в программах, которые обязательно должны быть. Этот этап называется - отладка программы. Данная проблема возникает со стороны исполнителя - в случае допущенных ошибок при разработке программы.

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

Источники

  1. Software development // Wikipedia. [2017—2017]. Дата обновления: 21.04.2017. URL: https://en.wikipedia.org/wiki/Software_development
  2. Разработка программного обеспечения // Википедия. [2017—2017]. Дата обновления: 02.06.2017. URL: http://ru.wikipedia.org/?oldid=84972174
  3. Правила разработки и создания программ // Avk-tv. [2017-2017]. Дата обращения: 02.06.2017. URL: http://avk-tv.ru/Linux1U_avk.php
  4. Проблемы разработки ПО // Cmcons [2017-2017]. Дата обращения: 02.06.2017. URL: http://cmcons.com/software_dev_problems.htm
  5. Методологии разработки программного обеспечения // Habrahabr [2017-2017]. Дата обращения: 02.06.2017. URL: https://habrahabr.ru/sandbox/43802/.

Ссылки/Литература

  1. Иан Соммервилл. Инженерия программного обеспечения. — Москва : Вильямс, 2002. — С. 642. — ISBN 5-8459-0330-0. - URL: http://www.tajfan.com/wp-content/uploads/2015/03/Инженерия-программного-обеспечения-Иан-Соммервилл.pdf
  2. Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи. Фабрики разработки программ: потоковая сборка типовых приложений, моделирование, структуры и инструменты — Москва. : Диалектика, 2006. — С. 592. — ISBN 978-5-8459-1181-0.