Лекция № 2 Тема 1. Технологии разработки программного

Скачать презентацию Лекция № 2 Тема 1. Технологии разработки программного Скачать презентацию Лекция № 2 Тема 1. Технологии разработки программного

agile_lecture_1_2.ppt

  • Размер: 751.0 Кб
  • Автор:
  • Количество слайдов: 28

Описание презентации Лекция № 2 Тема 1. Технологии разработки программного по слайдам

Лекция № 2 Тема 1. Технологии разработки программного обеспечения (ПО).  Часть 2. Лекция № 2 Тема 1. Технологии разработки программного обеспечения (ПО). Часть 2. Гибкие технологии разработки ПО. ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. Гибкие технологии разработки ПО. Основные положения AgileГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. Гибкие технологии разработки ПО. Основные положения Agile Manifesto Гибкая методология разработки (англ. Agile software development )— этоконцептуальныйкаркас, врамкахкотороговыполняется разработкапрограммногообеспечения. Гибкиетехнологииразработкипрограммногообеспечения минимизируютрискиблагодаряразделениюпроцессаразработкина маленькиепромежуткивремени – итерации ( 1 -4 недели). Каждая итерацияможетрассматриватьсякакполноценныйпроектпо разработке. ПО. Так, итерация может включать всебявсеосновные процессыразработки, такие какпланирование, анализтребований, проектирование, реализация, тестированиеидокументирование. Обычно, результатомитерациинеявляетсяпродукт, готовыйквыходу нарынок. Ноцельюкаждойитерацииявляетсяполучениестабильной версиипродукта. Вконцекаждойитерациипроисходитпереоценка приоритетовпроекта, чтозначительносокращаетриски.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные положения Agile Manifesto [ http: //agilemanifesto. org ]ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные положения Agile Manifesto [ http: //agilemanifesto. org ] Agile — семействопроцессовразработки, анеединственныйподход вразработкепрограммногообеспечения, иопределяется Agile Manifesto. Agile невключаетпрактик, аопределяетценностии принципы, которымируководствуютсяуспешныекоманды. Agile. Manifesto разработанипринят11 -13 февраля 2001 годана лыжномкурорте The. Lodgeat. Snowbird вгорах. Юты. Манифест подписалипредставителиследующихметодологий Extreme programming, Scrum, DSDM, Adaptive. Software. Development, Crystal Clear, Feature-Driven. Development, Pragmatic. Programming. Agile Manifesto c одержит 4 основные идеи и 12 принципов. Примечательночто, Agile. Manifesto несодержитпрактических советов.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Люди и взаимодействие важнее процессовиинструментов Работающий продукт важнее исчерпывающейдокументацииГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Люди и взаимодействие важнее процессовиинструментов Работающий продукт важнее исчерпывающейдокументации Сотрудничество с заказчиком важнее согласованияусловийконтракта Готовность к изменениям важнее следованияпервоначальному плану Тоесть, неотрицаяважноститого, чтосправа, мывсётакибольше ценимто, чтослева.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основополагающие принципы Agile-манифеста 1. Наивысшимприоритетомдлянасявляетсяудовлетворение потребностейзаказчика, благодарярегулярнойираннейпоставке ценногопрограммногообеспечения. 2.ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основополагающие принципы Agile-манифеста 1. Наивысшимприоритетомдлянасявляетсяудовлетворение потребностейзаказчика, благодарярегулярнойираннейпоставке ценногопрограммногообеспечения. 2. Изменениетребованийприветствуется, даженапозднихстадиях разработки. Agile-процессыпозволяютиспользоватьизменениядля обеспечениязаказчикуконкурентногопреимущества. 3. Работающийпродуктследуетвыпускатькакможночаще, с периодичностьюотпарынедельдопарымесяцев. 4. Напротяжениивсегопроектаразработчикиипредставителибизнеса должныежедневноработатьвместе. 5. Надпроектомдолжныработатьмотивированныепрофессионалы. Чтобыработабыласделана, создайтеусловия, обеспечьтеподдержкуи полностьюдоверьтесьим. 6. Непосредственноеобщениеявляетсянаиболеепрактичными эффективнымспособомобменаинформациейкакссамойкомандой, такивнутрикоманды.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 7. Работающийпродукт—основнойпоказательпрогресса. 8. Инвесторы, разработчикиипользователидолжныиметь возможностьподдерживатьпостоянныйритмбесконечно. Agile помогаетналадитьтакойустойчивыйпроцессразработки. 9.ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 7. Работающийпродукт—основнойпоказательпрогресса. 8. Инвесторы, разработчикиипользователидолжныиметь возможностьподдерживатьпостоянныйритмбесконечно. Agile помогаетналадитьтакойустойчивыйпроцессразработки. 9. Постоянноевниманиектехническомусовершенствуикачеству проектированияповышаетгибкостьпроекта. 10. Простота—искусствоминимизациилишнейработы—крайне необходима. 11. Самыелучшиетребования, архитектурныеитехнические решениярождаютсяусамоорганизующихсякоманд. 12. Командадолжнасистематическианализироватьвозможные способыулучшенияэффективностиисоответственно корректироватьстильсвоейработы.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Краеугольнымкамнемгибкихтехнологийпрограммирования является разработка через тестирование : автоматическиетестыпишутсядлялюбойчастиреализации, которая гипотетическиГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Краеугольнымкамнемгибкихтехнологийпрограммирования является разработка через тестирование : автоматическиетестыпишутсядлялюбойчастиреализации, которая гипотетически «можетсломаться» ; тестыпишутсянепосредственно перед написанием соответствующегокода; существующийкодникогданеменяетсябезнаписания соответствующихтестов; выполняетсярегулярныйзапусквсехавтоматическихтестов. Все гибкие методологии имеют общие характеристики: итеративнаяразработка; фокуснавзаимодействииикоммуникации; полныйиличастичныйотказотсозданиядорогостоящих промежуточныхартефактовпроекта.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Проектирование в гибких технологиях Отказотдлительногопроектированияпередначаломработыи выполнениепроектированиянапротяжениивсеговыполнения проекта.  ВначалепроектавыполняетсялишьГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Проектирование в гибких технологиях Отказотдлительногопроектированияпередначаломработыи выполнениепроектированиянапротяжениивсеговыполнения проекта. Вначалепроектавыполняетсялишь формирование общего представления. Дляэтогоиспользуются системные метафоры , на основекоторыхформируетсявысокоуровневаясхемапроекта. Процессразработкисостоитизбольшогоколичестваочень короткихциклов. Конечныйрезультатэтапапланирования–список задач, подлежащихреализациинаследующейитерации.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Разработчикиполучаютзадачу, берутсоответствующийфрагмент разрабатываемогокода, выполняютрефакторинг, необходимыйдля упрощениянаписанногокода, составляюттесты, атолькозатем создаютсамкод,ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Разработчикиполучаютзадачу, берутсоответствующийфрагмент разрабатываемогокода, выполняютрефакторинг, необходимыйдля упрощениянаписанногокода, составляюттесты, атолькозатем создаютсамкод, которыйдолженпройтитесты. Посколькуциклы « дизайн–тест–код » непродолжительны, а заказчикчастополучаетработающиеверсиипрограммного продукта, обратнаясвязьосуществляетсянепрерывно ислужитдля контроля, чтопроектированиеикодированиепродвигаютсяв нужномнаправлении. Таккакизменениянакаждомциклемалы, решения, откоторых приходитсяотказываться, невелики, врезультатечегоможно быстрореагироватьнаизмененияснаименьшимизатратами.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 1. Экстремальное программирование (Extreme Programming) Экстрем льноеГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 1. Экстремальное программирование (Extreme Programming) Экстрем льное программ рованиеаа иа (англ. Extreme Programming , XP )—однаизгибкихметодологийразработкипрограммного обеспечения. Авторыметодологии—Кент. Бек, Уорд. Каннингем, Мартин. Фаулеридругие. Экстремальноепрограммирование—являетсянаиболееизвестной изгибкихметодологий.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Экстрем льное программ рование аа иа строитсяна 12 принципах,ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Экстрем льное программ рование аа иа строитсяна 12 принципах, которыеможнообъединитьв 4 группы: Короткийциклобратнойсвязи 1. Разработкачерезтестирование 2. Игравпланирование 3. Заказчиквсегдарядом 4. Парноепрограммирование Непрерывный, анепакетныйпроцесс 5. Непрерывнаяинтеграция 6. Рефакторинг 7. Частыенебольшиерелизы Понимание, разделяемоевсеми 8. Простота 9. Метафорасистемы 10. Коллективноевладениекодомиливыбраннымишаблонами проектирования 11. Стандарткодирования Социальнаязащищенностьпрограммиста 12. 40 -часоваярабочаянеделя

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основная идея экстремального программирования (ХР) — устранитьвысокуюстоимостьизменений, вносимыхв. ПОвпроцессеГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основная идея экстремального программирования (ХР) — устранитьвысокуюстоимостьизменений, вносимыхв. ПОвпроцессе какразработки, такиэксплуатации. Циклразработкив. ХРсостоитизоченькороткихитераций. Четырьмябазовымидействиямивциклеявляются: • выслушиваниезаказчика • проектирование • кодирование • тестирование. Заказчикпостоянноприсутствуетвгрупперазработчиков. Припринятиирешенийвсегдастремятсявыбратьсамоепростое, тестыпишутсяещедонаписаниякода. Сборкасистемывыполняетсяежедневно.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Тестирование в ХР Тестирование модулей (unit testing):  позволяетразработчикамубедиться,ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Тестирование в ХР Тестирование модулей (unit testing): позволяетразработчикамубедиться, чтокодработаеткорректно, и безопасенийвыполнятьрефакторинг(refactoring); помогаетнеавторамкодапонять, зачемнужентотилииной фрагменткодаикаконфункционирует. Приемочное тестирование (acceptance testing): позволяетубедитьсявтом, чтосистемадействительнообладает заявленнымивозможностямиифункционируеткорректно. TDD (Test Driven Development): пишетсятест(непроходит); пишетсякод, чтобытестпрошел; выполняетсярефакторингкода.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 2. Scrum Подходвпервыеописали. Хиротака. Такеутии. Икудзиро. НонакавГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 2. Scrum Подходвпервыеописали. Хиротака. Такеутии. Икудзиро. Нонакав статье The New Product Development Game ( Гарвардский Деловой Обзор , январь-февраль 1986 ). Впервыеметод. Scrumбылпредставленнаобщееобозрение задокументированным, чёткосформированнымиописанным совместно. Сазерлендоми. Шваберомна. OOPSLA’ 96 в. Остине. Шваберобъединилусилияс. Майком. Бидломв 2001 году, чтобы детальноописатьметодвкниге «Agile. Software. Developmentwith SCRUM» .

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Scrum —этонаборпринципов, накоторыхстроитсяпроцесс разработки, позволяющийвжёсткофиксированныенебольшие промежуткивремени( спринты от2 доГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Scrum —этонаборпринципов, накоторыхстроитсяпроцесс разработки, позволяющийвжёсткофиксированныенебольшие промежуткивремени( спринты от2 до 4 недель)предоставлять конечномупользователюработающее. ПОсновымивозможностями, длякоторыхопределённаибольшийприоритет. Возможности. ПОк реализациивочередномспринтеопределяютсявначалеспринтана этапепланированияинемогутизменятьсянавсёмегопротяжении. Приэтомстрого-фиксированнаянебольшаядлительностьспринта придаётпроцессуразработкипредсказуемостьигибкость.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Общие положения Scrum 3 роли:  владелец продукта (ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Общие положения Scrum 3 роли: владелец продукта ( Product Owner )-отвечаетзаопределение требованийкпродукту команда ( Team ) -группасамостоятельныхиинициативных разработчиков, ответственныхзареализациюпроекта скрам-мастер ( Scrum. Master ) -отвечаетзарешениевсех организационныхпроблемисоблюдениеметодологии Scrum. 3 фазы проекта: Подготовка ( Pregame ) : общийпланпроекта, списокосновных требованийкпродукту, высокоуровневаяархитектурапродукта. Реализация ( Game ) : итеративноеразвитиепродукта. Завершение ( Postgame ) : действия, необходимыедляподготовки продуктаквыходунарынок.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Реализация проекта в Scrum Фазареализацииразбитанапоследовательностьитераций - спринтов ( SprintГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Реализация проекта в Scrum Фазареализацииразбитанапоследовательностьитераций — спринтов ( Sprint ). Врезультатекаждогоспринтавпродуктереализуетсяновый, заметныйдлявладельцапродукта, объемфункциональности. Вконцекаждогоспринтапродуктостаетсявработоспособном состоянии. Спринтначинаетсяссессиипланирования( Sprint Planning Meeting ) -определяетсяобъемфункциональности, котораябудетреализована втечениеспринта. Ежедневнопроводитсясобраниеучастниковпроекта- скрам-сессия ( Daily Scrum Meeting ). Позавершениюспринтапроводитсядемонстрационнаясессия ( Sprint Review Meeting ).

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Документация в Scrum Всего 3 документа: журнал продукта (ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Документация в Scrum Всего 3 документа: журнал продукта ( Product Backlog ) высокоуровневыйсписокфункциональныхитехнических требований, необходимыхдляреализациипродукта журнал спринта ( Sprint Backlog ) детализированныйсписокфункциональныхитехнических требований, необходимыхдляуспешногозавершенияитерации график спринта ( Burndown Chart ). показываетежедневноеизменениеобщегообъемаработ, оставшегосядозавершенияитерации.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 3. Microsoft Solutions Framework В 1994 году,ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 3. Microsoft Solutions Framework В 1994 году, стремясьдостичьмаксимальнойотдачиот. IT-проектов, Microsoftвыпустилавсветпакетруководствпоэффективному проектированию, разработке, внедрениюисопровождениюрешений, построенныхнаосновесвоихтехнологий. Microsoft Solutions Framework —концепцияразработки программногообеспеченияот. Microsoft. MSFпредлагаетметодики дляпланирования, проектирования, разработкиивнедрения IT-решений. MSFобладаетвысокойгибкостью, масштабируемостью, отсутствиемжесткихинструкцийиспособенудовлетворитьнужды организацииилипроектнойгруппылюбогоразмера.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Командасостоитизролей, каждаяизкоторыхориентированана достижениеопределенныхцелей:  Управлениепродуктом Управлениепрограммой Разработка Тестирование УдовлетворениепотребителяГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Командасостоитизролей, каждаяизкоторыхориентированана достижениеопределенныхцелей: Управлениепродуктом Управлениепрограммой Разработка Тестирование Удовлетворениепотребителя Управлениевыпуском

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Процессразработкипо. MSF являетсяитеративнымивключаетв себяследующие основныефазы :  Выработкаконцепции ПланированиеГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Процессразработкипо. MSF являетсяитеративнымивключаетв себяследующие основныефазы : Выработкаконцепции Планирование Разработка Стабилизация Внедрение Модельпроцессов. MSFсодержитвесьжизненныйциклсоздания решения, включаяеговнедрение—вплотьдомомента, когда решениеначинаетдаватьотдачу.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ  1. 3. 4. Feature Driven Development FDDразработана. Джеффом.ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 3. 4. Feature Driven Development FDDразработана. Джеффом. Де. Люка(Jeff. De. Luca)дляпроекта, рассчитанногона 15 месяцевивкоторомучаствовали 50 человек, по разработкипрограммногообеспечениядляодногокрупного Сингапурскогобанкав 1997. Джефф. Де. Люкавыделил 5 процессов, охватывающиеразвитиеобщеймодели, листиниг, планирование, проектированиеипостроениефункций. FDD (Feature Driven Development) – функционально-ориентированнаяразработка. Используемоев. FDD понятиефункцииилисвойства(feature)системыдостаточноблизкок понятиюпрецедентаиспользования, используемомув. RUP, существенноеотличие—этодополнительноеограничение: «каждая функциядолжнадопускатьреализациюнеболее, чемзадве недели» . Тоестьеслисценарийиспользованиядостаточномал, его можносчитатьфункцией. Еслижевелик, тоегонадоразбитьна несколькоотносительнонезависимыхфункций.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ FDDвключаетпятьпроцессов, последниедваизкоторых повторяютсядлякаждойфункции:  Разработкаобщеймодели Составлениесписканеобходимыхфункцийсистемы Планированиеработынадкаждойфункцией Проектированиефункции КонструированиефункцииГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ FDDвключаетпятьпроцессов, последниедваизкоторых повторяютсядлякаждойфункции: Разработкаобщеймодели Составлениесписканеобходимыхфункцийсистемы Планированиеработынадкаждойфункцией Проектированиефункции Конструированиефункции

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Разработчикив. FDDделятсяна «хозяевклассов» и «главных программистов» . Главныепрограммистыпривлекаютхозяев задействованныхклассовкработенадочереднымсвойством.ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Разработчикив. FDDделятсяна «хозяевклассов» и «главных программистов» . Главныепрограммистыпривлекаютхозяев задействованныхклассовкработенадочереднымсвойством. Работанадпроектомпредполагаетчастыесборкииделитсяна итерации, каждаяизкоторыхпредполагаетреализацию определенногонаборафункций. Ксожалению, такиеобласти, какобеспечениекачества, оценка рисковданнаямодельобходитстороной. FDDподходитдля небольшихпроектов, срокреализациикоторыхсоставляетнесколько месяцев. Длядолгосрочныхпроектов, сосрокомпроизводствагод илиболее, предпочтительновыбратьдругую, более формализованнуюмодель.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 4. Сравнение традиционных и гибких технологий разработки ПОГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1. 4. Сравнение традиционных и гибких технологий разработки ПО Подготовить реферат

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Краткие выводы по гибким методологиям Гибкиеметодологиииспользуютитеративныйподход, прикотором детальнопланируетсятолькоограниченныйобъемработ, связанныйсГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Краткие выводы по гибким методологиям Гибкиеметодологиииспользуютитеративныйподход, прикотором детальнопланируетсятолькоограниченныйобъемработ, связанныйс выпускомочередногорелиза. Практическивсегибкиеметодологииориентированынамаксимально неформальныйподходкразработке. Еслипроблемуможнорешитьв разговоре, толучшеименнотакисделать. Оформлятьпринятое решениеввидебумажногоилиэлектронногодокументанужнотолько тогда, когдабезэтогоневозможнообойтись. Такжебольшинствометодологийиспользуютдовольноограниченный набордокументов, моделейиработдляописанияпроцессаразработки. Этоделаетихдостаточнопростыми(покрайнеймере, напервыйвзгляд) длявнедрения. Хотячастоэтапростотадостигаетсязасчеттого, что многие, безусловно, необходимыеработытолькоупоминаются, ане описываютсявметодологии. Ипрактическивсеонинепредусматриваютспецифическихусилий, которыхтребуетразработкапринципиальноновойархитектурысистемы, например, есликомандапереходитсклиент-сервернойархитектурына использованиеинтернет-технологий.

Спасибо за внимание КОМПЬЮТЕРНЫЕ СЕТИ Спасибо за внимание КОМПЬЮТЕРНЫЕ СЕТИ