sdt-book-2006 (1133574), страница 12
Текст из файла (страница 12)
ИТ. Процессы жизненного цикла программных средств.[3] ISO/IEC 15288:2002, Systems engineering — System life cycle processes, 2002.[4] ISO/IEC 15504-1-9, Information technology — Process assessment, Parts 1-9.15504-1,3,4:2004, 15504-2:2003/Cor 1:2004, TR 15504-5:2004.[5] IEEE 1074-1997 IEEE Standard for Developing Software Life Cycle Processes, 1997.[6] IEEE/EIA 12207.0-1996 Industry Implementation of International Standard ISO/IEC 12207:1995,New York, Mar. 1998.33[7] IEEE/EIA 12207.1-1997 Industry Implementation of International Standard ISO/IEC 12207:1995Software Life Cycle Processes — Life Cycle Data, New York, Apr.
1998.[8] IEEE/EIA 12207.2-1997 Industry Implementation of Int'l Standard ISO/IEC 12207:1995 SoftwareLife Cycle Processes — Implementation Considerations, New York, Apr. 1998.[9] M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber. Capability Maturity Model for Software,Version 1.1, SEI Technical Report CMU/SEI-93-TR-024, Software Engineering Institute,Pittsburgh, Feb. 1993.http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf[10] M. C. Paulk, C.
V. Weber, S. M. Garcia, M. B. Chrissis, and M. Bush. Key Practices of theCapability Maturity Model, Version 1.1, SEI Technical Report CMU/SEI-93-TR-025, SoftwareEngineering Institute, Pittsburgh, Feb. 1993.http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf[11] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems Engineering,Software Engineering, Integrated Product and Process Development, and Supplier Sourcing(CMMI-SE/SW/IPPD/SS, V1.1). Continuous Representation. SEI Technical Report CMU/SEI2002-TR-011, Software Engineering Institute, Pittsburgh, March 2002.http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf[12] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems Engineering,Software Engineering, Integrated Product and Process Development, and Supplier Sourcing(CMMI-SE/SW/IPPD/SS, V1.1).
Staged Representation. SEI Technical Report CMU/SEI-2002TR-012, Software Engineering Institute, Pittsburgh, March 2002.http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf[13] W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEEWESCON, pp. 1–9, August 1970.Переиздана: Proceedings of the 9th International Software Engineering Conference, ComputerSociety Press, pp. 328–338, 1987.[14] B. Randell, F. W. Zurcher. Iterative Multi-Level Modeling: A Methodology for ComputerSystem Design. Proc.
IFIP, IEEE CS Press, 1968.[15] B. Boehm. A Spiral Model of Software Development and Enhancement. Computer, May 1988,pp. 61-72.[16] И. Соммервилл. Инженерия программного обеспечения. М.: Вильямс, 2002.[17] У. Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.[18] Э. Дж. Брауде.
Технология разработки программного обеспечения. СПб.: Питер, 2004.34Лекция 3. Унифицированный процесс разработки и экстремальноепрограммированиеАннотацияРассматриваются в деталях модели разработки ПО, предлагаемые в рамках унифицированногопроцесса разработки Rational (RUP) и экстремального программирования (XP).Ключевые слова«Тяжелые» процессы разработки, «живые» методы разработки, унифицированный процессRational, экстремальное программирование, модели ПО.Текст лекции«Тяжелые» и «легкие» процессы разработкиВ этой лекции мы рассмотрим детально два процесса разработки — унифицированный процессRational (Rational Unified Process, RUP) и экстремальное программирование (ExtremeProgramming, XP).
Оба они являются примерами итеративных процессов, но построены на основеразличных предположений о природе разработки программного обеспечения и, соответственно,достаточно сильно отличаются.RUP является примером так называемого «тяжелого» процесса, детально описанного ипредполагающего поддержку собственно разработки исходного кода ПО большим количествомвспомогательных действий. Примерами подобных действий являются разработка планов,технических заданий, многочисленных проектных моделей, проектной документации, и пр.Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПОот конкретных людей, умеющих их применять. Многочисленные вспомогательные действия даютнадежду сделать возможным успешное решение задач по конструированию и поддержке сложныхсистем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.Для достижения этого выполняется иерархическое пошаговое детальное описаниепредпринимаемых в той или иной ситуации действий, чтобы можно было научить обычногоработника действовать аналогичным образом.
В ходе проекта создается много промежуточныхдокументов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачина более простые. Эти же документы служат для проверки правильности решений, принимаемыхна каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов,необходимых для получения желаемых результатов.Экстремальное программирование, наоборот, представляет так называемые «живые» (agile)методы разработки, называемые также «легкими» процессами. Они делают упор на использованиихороших разработчиков, а не хорошо отлаженных процессов разработки.
Живые методы избегаютфиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретномпроекте, а также выступают против разработки дополнительных документов, не вносящихнепосредственного вклада в получение готовой работающей программы.Унифицированный процесс RationalRUP [1,2] является довольно сложной, детально проработанной итеративной модельюжизненного цикла ПО.Исторически RUP является развитием модели процесса разработки, принятой в компанииEricsson в 70-х–80-х годах XX века.
Эта модель была создана Джекобсоном (Ivar Jacobson),впоследствии, в 1987, основавшим собственную компанию Objectory AB именно для развитиятехнологического процесса разработки ПО как отдельного продукта, который можно было быпереносить в другие организации. После вливания Objectory в Rational в 1995 разработкиДжекобсона были интегрированы с работами Ройса (Walker Royce, сын автора «классической»каскадной модели), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимсяпараллельно универсальным языком моделирования (Unified Modeling Language, UML).35RUP основан на трех ключевых идеях.• Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантовиспользования (use cases) — сценариев взаимодействия результирующей программнойсистемы с пользователями или другими системами, при выполнении которых пользователиполучают значимые для них результаты и услуги.
Разработка начинается с выделениявариантов использования и на каждом шаге контролируется степенью приближения к ихреализации.• Основным решением, принимаемым в ходе проекта, является архитектурарезультирующей программной системы. Архитектура устанавливает набор компонентов, изкоторых будет построено ПО, ответственность каждого из компонентов (т.е. решаемые имподзадачи в рамках общих задач системы), четко определяет интерфейсы, через которыеони могут взаимодействовать, а также способы взаимодействия компонентов друг сдругом.Архитектура является одновременно основой для получения качественного ПО и базой дляпланирования работ и оценок проекта в терминах времени и ресурсов, необходимых длядостижения определенных результатов.
Она оформляется в виде набора графическихмоделей на языке UML.• Основой процесса разработки являются планируемые и управляемые итерации, объемкоторых (реализуемая в рамках итерации функциональность и набор компонентов)определяется на основе архитектуры.РуководительпроектаСтарт проектаПодготовка средыпроекта и итерацийКонтроль иуправлениеИнженер попроцессуПланированиепроекта и итерацийРуководительпроектаАнализ задачпроектаАнализ потребностейзаинтересованных лицОпределениеконцепции системыРуководительпроектаОценка результатовитерацийСистемныйаналитикСистемныйаналитикСистемныйаналитикОпределениевозможных архитектурАрхитектор ПООпределение методовтестированияТестировщикиРисунок 7. Пример хода работ на фазе начала проекта.RUP выделяет в жизненном цикле на 4 основные фазы, в рамках каждой из которых возможнопроведение нескольких итераций.
Кроме того, разработка системы может пройти через несколькоциклов, включающих все 4 фазы.1. Фаза начала проекта (Inception)Основная цель этой фазы — достичь компромисса между всеми заинтересованнымилицами относительно задач проекта и выделяемых на него ресурсов.На этой стадии определяются основные цели проекта, руководитель и бюджет, основныесредства выполнения — технологии, инструменты, ключевые исполнители.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
