Реферат по предмету "Информатика"


Разработка и внедрение собственного программного продукта

--PAGE_BREAK--Глава 1.  Выбор методологии разработки


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

Существует множество различных методологий. Среди них выделяют тяжеловесные и гибкие методологии. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, большой объем документации, и такой подход работает — однако до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих. Наиболее известными и популярными гибкими методологиями в настоящее время является RUP(Rational Unified Process) и XP(eXtreme Programming).

RUPи XP исходят из различных философских основ. RUP — это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP — более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. RUP– это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.

У RUPи XPмножество различий, но решающим фактором при выборе методологии стал подход к архитектуре проектируемых систем. RUP советует уделять внимание архитектуре во избежание рисков, связанных с превышением времени на разработку, излишним объемом проекта и введением новых технологий. В XP предполагается либо наличие архитектуры, либо архитектура настолько проста и понятна, что может быть выведена непосредственно из кода. XP советует не проектировать на будущее, а реализовывать то, что нужно сегодня. Предполагается, что будущее сможет позаботиться о себе само, если вы будете сохранять проект настолько простым, насколько это возможно. Если даже система или ее часть будут переписываться в будущем, XP отмечает, что это все равно лучше, и зачастую дешевле, чем планировать такую возможность изначально. Для некоторых систем это действительно так, и при использовании RUP рассмотрение риска во время проработки проекта может привести вас к такому выводу. RUP не считает это истинным для всех систем и, как показывает опыт больших, более сложных систем, этот фактор может оказаться катастрофическим.

Учитывая сложность разрабатываемой системы, а также требования к адаптивности, мы выбрали в качестве методологии разработки RUP. Создатели RUP определяют его как итеративный, архитектурно-ориентированный и управляемый прецедентами использования процесс разработки программного обеспечения [9]. Основа RUP: разработка концепции; управление по плану; снижение рисков и отслеживание их последствий; тщательная проверка экономического обоснования; использование компонентной архитектуры; прототипирование, инкрементное создание и тестирование продукта; регулярные оценки результатов; управление изменениями; создание продукта, пригодного к употреблению; адаптация RUP под нужды своего проекта.

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

·                     определение требований (Requirements);

·                     проектирование и анализ (Design & Analysis);

·                     разработка (Development);

·                     тестирование (Testing);

·                     развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

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

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

·                     повысить производительность труда (разработчики получают возможность делиться передовым опытом разработки и внедрения);

·                     ускорить разработку благодаря интеграции инструментов;

·                     уменьшить затраты на сопровождение, постоянно поддерживая соответствие между приложением и его проектной документацией;

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

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


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

Поделись с друзьями, за репост + 100 мильонов к студенческой карме :

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

Читайте также:
Виды рефератов Какими бывают рефераты по своему назначению и структуре.