Технология создания программного обеспечения

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

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

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

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

Так, по данным американских исследователей, в 80-е годы только 14% проектов по созданию ПО завершались успешно (имеется в виду не только удовлетворение требований заказчика, но и завершение в срок с соблюдением бюджета (Chaos Report)). Сегодня, после нескольких десятилетий эволюции языков программирования, инструментальных средств разработки, практически неограниченной доступности машинного времени (по сравнению с 70 и 80ми годами) процент успешно завершенных проектов составляет всего 26% (данные были приведены на одном из семинаров Г. Бучем.).

В СССР в производстве ПО результаты были значительно лучше и объективными предпосылками этого были следующие моменты:

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

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

В любом производстве используется технология определяет лучшие достижимые показатели. В силу специфичности производства ПО (практически нулевая стоимость тиражирования, очень быстрый процесс старения и т. Д.) Технология его создания очень сильно завязана на человеческий ресурс и поэтому должна включать в себя организационный и управленческий аспекты. На сегодняшний день в мире существует огромное количество раз личных процессов для создания ПО. Тем не менее, именно технологий, рассматривающих полный жизненный цикл проекта разработки ПО, сочетающие в себе научный подход, серьезную базу исследований и имеют историю реального использования и адаптации, относительно немного. С методологий и технологий, которые получили определенное признание на данный момент, можно назвать следующие: Datarun, CMM, Microsoft Solution Framework (MSF), Oracle Method, Rational Unified Process (RUP), SADT (IDEFx).

Особое место в этом списке занимает технология компании Rational Software. В методологии, которая является составной частью технологии Rational, применен наиболее современный процессно-ориентированный подход: так как разработка ПО является производством, то, как и на всяком производстве, при выявлении проблем в продукции (симптомов) необходимо в обязательном порядке корректировать процесс ( устранять причины). Особенностью технологии является то, что в ее создании принимают участие ведущие методисты в области разработки ПО, такие как Г. Буч (ООАП), Дж. Рамбо (OMT), А. Джекобсон (Objectory), которые внесли весомый вклад в теорию и практику разработки современного ПО. Кроме того, эта технология развивалась и проходила проверку с участием военного ведомства США.

Симптомы и причины проблем

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

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

Перечислим некоторые причины проблем:

Недостаточное управление требованиями делает неконтролируемым изменение объемов работы и ставит под угрозу возможность реализации проекта в срок.
Хрупкая архитектура, которая легко ломается под влиянием изменений в требованиях или технологиях. Одним из примеров является архитектура, которая строится на одноразовых компонентах в рамках технологии, не предусматривает повторного использования, что делает саму архитектуру негибкой, так как существенное изменение программы можно рассматривать как составление новой программы с повторным использованием ранее созданных компонентов.
Субъективное определение статуса проекта известно, как правило "90% сделано, и еще 90% осталось". Иными словами, разработчики считают, что сделано 90% работы, но ее завершения требует такого же количества ресурсов и времени для достижения 100% готовности.

Причины проблем и лучшие практики

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

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

Лучшие практики - это комплекс подходов к разработке ПО, проверенных на многих реальных проектах, которые при совместном использовании направленные на устранение причин возникновения проблем при разработке ПО. Об этом говорит сайт https://intellect.icu . Интересен тот факт, что "лучшие практики" названы так не потому, что легко можно идентифицировать их вклад в успех проекта, а скорее по той причине, что они применяются в каждой организации достигла стабильного успеха в области разработки ПО.
 

Практика № 1. Итерационный процесс разработки

Суть итеративной практики может быть лучше всего прокомментировано визуально (рис. 2).
 

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

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

Практика № 2. Управление требованиями

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

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

Говоря об управлении требованиями в подходе Rational нельзя не упомянуть о сценарии использования (Use Case). Сценарий является основным структурирующим элементом текстового описания проектируемой системы, организованного в соответствии с целями, преследуемыми пользователем при использовании этой системы.

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

Практика № 3. Использование компонентной архитектуры

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

Согласно мнению авторов Software Architecture in Practice: "архитектура ПО - это такая составляющая результатов разработки, которая дает наивысшую отдачу от вложений".

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

Наиболее распространенными платформами для построения компонентной архитектуры являются:

Microsoft СОМ,
Sun Enterprise Java Beans,
CORBA

Практика № 4. Визуальное моделирование

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

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

Совместно с итерационным подходом визуальное моделирование позволяет эффективно отслеживать и распространять внутри коллектива разработчиков "межитерационние" изменения в проектируемом приложении. Многие коллективы пытались осуществить подобное и раньше, но объемы работы по отражению в моделях неизбежных изменений, в архитектуре и дизайне (вносятся на этапах реализации и тестирования), оказывались слишком велики. Только использование инструмента, который осуществляет прямое и обратное преобразование модель <-> код, позволяет снизить объем трудозатрат при этих операциях.

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

Практика № 5. Контроль качества

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

Во многих организациях тестирование отнимает 30 - 50% ресурсов на разработку. Тем не менее, количество ошибок в ПО, обнаруженных заказчиком, свидетельствует о том, что ПО недостаточно тестируется до его поставки.

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

Данные, полученные Rational в результате автоматизации процесса тестирования в реальной заказчика, следующие: к автоматизации выполнялось 13000 тестов с помощью шести человек за две недели, после автоматизации были выполнены те же тесты по 6:00 с помощью одного человека.

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

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

Практика № 6. Управление изменениями

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

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

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

Управление запросами на изменение (Change Request Management) соответствует инфраструктуре, необходимой для контроля над воздействием на стоимость и сроки от необходимых исправлений для существующего продукта.

В правление конфигурацией (Configuration Management) представляет собой деятельность по определению конфигураций, построения, маркировки и хранения версий артефактов.

Измерения (Measurement) описывает состояние продукта, опираясь на типы, количество и значимость выявленных недостатков в течение разработки.

Безусловно, столь краткое рассмотрение не может осветить все аспекты применения лучших практики показать все взаимосвязи между ними. Как видно из таблицы 2, для устранения одной причины проблемы задействуется несколько практик. Лучшие практики формируют основу для подисциплинного рассмотрения технологии разработки ПО, представленного в Rational Unified Process (RUP).
 

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

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

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

Для успешного применения методологии необходимо установление адекватного процесса разработки. И именно развернутый шаблон процесса вместе с достаточным для его реализации комплексом инструментария предлагает Rational. Описанные шесть лучших практик легли в основу Rational Unified Process (RUP).

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

Описание RUP

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

На высоком уровне абстракции RUP содержит три аспекта: фазы, дисциплины, и лучшие практики. Первый аспект представляет собой динамичный вид системы и описывает процесс с точки зрения фаз, итераций и вех разработки, второй аспект представляет собой статический вид процесса и описывает процесс с точки зрения ролей, артефактов и дисциплин, третий аспект представляет собой косой срез концепций, которые легли в основу процесса (лучших практик).

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

Фазы

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

Кого-то может удивить отсутствие стадии поддержки системы, однако это естественно, потому что, по сути, она совпадает со стадией Transition. В зависимости от типа и сложности продукта стадии могут отличаться по времени и количеству итераций.

Модели

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

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

В подходе Rational для отображения моделей используется Unified Modeling Language (UML). С точки зрения процесса UML является стандартом описания для артефактов разработки и моделирования (семантических моделей, синтаксических нотаций и диаграмм), то есть той информации, которая необходима для обеспечения взаимодействия в процессе разработки и поддержки программного обеспечения. UML не определяет, каким образом использовать его возможности для получения результата, какие модели должны быть построены и в какой последовательности.

Дисциплины

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

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

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

Реализация. В рамках этой дисциплины проводится определение организации кода в терминах реализуемых подсистем, организованных в слои (layers), реализуются классы и объекты, проводится объединение разработанных компонентов в рабочие элементы.

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

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

Управление конфигурациями и изменениями. Эта дисциплина контролирует изменение и целостность всех артефактов проекта. Для этой цели осуществляется идентификация элементов конфигурации, осуществляется ограничение и аудирование изменений на этих элементов, определяются и управляются конфигурации этих элементов.

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

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

Среда (Environment). Эта дисциплина фиксирует внимание на действиях, необходимых для построения процесса разработки в рамках проекта и организации, с учетом таких параметров среды, как процессы и инструменты. Именно по изучению этой дисциплины необходимо начинать планирование внедрения тех или иных элементов RUP. Кроме того, в последней версии RUP появился отдельный комплекс пособий для построения индивидуальных процессов разработки ПО, основанных на RUP.

Люди

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

Для достижения этой цели доступны следующие возможности:

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

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

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

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