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

Дата добавления: 28 Октября 2013 в 13:43
Автор: k*********@gmail.com
Тип работы: реферат
Скачать полностью (39.58 Кб)
Работа содержит 1 файл
Скачать  Открыть 

Коллективная разработка ПО.doc

  —  160.50 Кб

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

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

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

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

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

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

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

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

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

XP ориентирована  на:

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

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

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

  • Планирование процесса
  • Частые релизы
  • Метафора системы
  • Простая архитектура
  • Тестирование
  • Рефакторинг
  • Парное программирование
  • Коллективное владение кодом
  • Частая интеграция
  • 40-часовая рабочая неделя
  • Стандарты кодирования
  • Тесное взаимодействие с заказчиком

 

 

Сравнение технологий MSF, RUP и XP

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

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

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

 

CASE-технологии


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

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

В 1970-80-х годах  при разработке информационных систем широко применялась структурная  методология, предоставляющая в  распоряжение разработчиков строгие  формализованные методы описания ИС и принимаемых технических решений. Эта методология основывалась на наглядной графической технике, иначе говоря, для описания проекта использовались различного рода схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке конкретных проектов встречалось достаточно редко, поскольку ее практически невозможно реализовать на должном уровне ручным, неавтоматизированным, способом. Вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Если участники проекта пытались прибегнуть к ручной разработке, то перед ними возникали следующие проблемы:

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

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

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

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

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

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

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

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

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

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

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

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

Описание работы
Авторская разработка — принцип создания программных продуктов, при котором весь жизненный цикл разработки поддерживается одним — единственным человеком.
Этот принцип был достаточно широко распространен в 70 — 80-е годы ХХ века. Сейчас он применяется редко. Примерами авторских разработок являются операционная система Диспак (В. Ф. Тюрин), текстовый редактор Лексикон (Е. М. Веселов), трансляторы с языков Algol – 68 (П. Наур) и Pascal (H. Вирт).
Содержание
содержание отсутствует