Планирование и управление проектами на предприятии основывается на накопленном опыте, существуют и используются стандарты на разрабатываемое программное обеспечение, соблюдение которых контролируется специальной группой обеспечения качества. Считается, что второй уровень может как обеспечить возможности для дальнейшего совершенствования (перехода на третий уровень), так и не исключает вероятность в критических условиях регрессивного возврата качества процесса создания программного обеспечения на начальный уровень.
Третий, определенный уровень (defined level) характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью задокументирован, начиная от разработки программного обеспечения и заканчивая управлением проектами. Гипотеза внедрения этого уровня состоит в том, что в процессе стандартизации происходит переход предприятия на наиболее эффективные практики и технологии. Для создания и поддержания функционирования стандартов разработки программного обеспечения и управления проектами в организации должна быть создана специальная группа. Обязательным условием для достижения третьего уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Считается, что начиная с этого уровня организация перестает зависеть от качеств конкретных разработчиков и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
На четвертом, управляемом уровне (managed level) на предприятии устанавливаются количественные показатели качества – как на программные продукты, так и на процессы их создания в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных проектных показателей. При этом разделяются осмысленные (сигнальные) вариации реализуемых процессов создания программного обеспечения и случайные (шумовые) вариации процесса.
Пятый (высший), оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к уже существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей предприятия на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов должно способствовать предупреждению возможных ошибок и дефектов. Одновременно должны вестись работы по сокращению себестоимости разработки программного обеспечения.

---

7. Жизненный цикл проекта. Стадии жизненного цикла проекта.

8. Модель «Code & Fix».(Проб и ошибок).

Являлась первой моделью разработки ПО.
Описать правила этого метода просто:

• 
  получаем начальное понимание потребностей заказчика;
  
• 
  начинаем программировать;
  
• 
  когда что-то будет готово, показываем «это» заказчику;
  
• 
  получив отзывы, исправляем наш код;
  
• 
  повторяем цикл до полного удовлетворения заказчика (или пока у него не кончатся деньги, терпение…)
  

Используя Code-and-Fix, мы только пишем код. Здесь все очень просто: нет необходимости что-либо планировать, нет необходимости что-либо документировать. Поэтому Code-and-Fix требует минимальной квалификации разработчиков, соответственно, им можно платить меньше денег.
Но, у всего есть своя цена. Как показал опыт, такой подход очень скоро приводит к коду, который невозможно поддерживать: исправление одной ошибки приводит к появлению нескольких новых; внесение минимальных изменений в одну из частей программы, приводит к разрушению функций, реализуемых другими частями.
Все последующее развитие методик разработки выросло из стремления решить эти проблемы.

9. Модель водопада. Стадии, преимущества, недостатки.

Waterfall, или каскадная модель



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

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

Преимущества каскадной модели

В последние годы модель водопада уступает свои лидирующие позиции более гибким методологиям. Это связано с общей динамикой в IT, когда за разработку ПО отвечают команды из 5-9 человек, а дедлайн может быть легко сдвинут из-за наращивания функциональности.

Тем не менее, каскадная модель всё ещё актуальна для крупных проектов и организаций. И вот почему:

• 
  Устойчива к изменению кадрового состава. Разработчики могут приходить и уходить на протяжении всего жизненного цикла проекта, но благодаря подробному документированию это практически не влияет на сроки исполнения проекта.
  
• 
  Дисциплина. Модель водопада заставляет разработчиков, вовлечённых в проект быть дисциплинированными, оставаться в рамках намеченного плана. При необходимости в общей модели добавляется орган управления, ответственный за принятие решений, исполнители же обязаны работать в рамках системы.
  
• 
  Гибкость на ранних этапах. Изменения в первых трёх фазах могут быть сделаны немедленно и с минимальными усилиями, поскольку они не подкреплены кодом. Таким образом, заказчик и исполнитель имеют значительный временной запас для кардинального изменения концепции работы ПО.
  
• 
  Ориентация на сроки и финансы. Благодаря тому, что каждый этап полностью очерчивает контур будущего ПО, все разработчики понимают свою роль, границы работы и сроки исполнения. Это позволяет оперировать реальными цифрами перед заказчиком, что делает модель проекта привлекательной.
  

---

Недостатки каскадной модели

В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:

• 
  Неадаптивная структура ПО. На первых этапах модель водопада может быть гибкой, но если на фазе тестирования выявляются проблемы в общей структуре – это влечёт за собой плачевные последствия в виде сорванных сроков и даже отказов заказчика. Таким образом, возрастает роль руководителей и ответственных разработчиков, с уровнем компетентности которых в любой компании часто бывают проблемы.
  
• 
  Игнорирует конечного пользователя. Чем ниже продвигается процесс в водопаде, тем меньше в нём роль заказчика, не говоря уже о клиентах, которых он представляет. Внесение каких-либо изменений в функциональность ПО запускает всю цепочку этапов заново, поэтому продукты полученные по каскадной модели далеки от ориентации на массового пользователя.
  
• 
  Позднее тестирование. Из описания выше легко выявить самый проблемный этап методологии – тестирование. Именно здесь чаще всего выявляются ошибки, допущенные на каждом из этапов. Более гибкие методологии используют тестирование в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же допускает низкую квалификацию сотрудников на каждом этапе и плохое качество исполнения, ведь при запоздалом тестировании проблемы невозможно решить фундаментально, только при помощи «заплаток».
  

Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только в трёх случаях:

1. 
   При ориентации ПО на заказчика, требующего прозрачность работ и исполнение в назначенные сроки.
   
2. 
   При наличии в штате руководителей соответствующей квалификации.
   
3. 
   При исполнении проекта, не имеющего конкуренции на рынке.
   

https://geekbrains.ru/posts/waterfall

https://makhmetov.ru/articles/agile.html#id6

10. V-образная модель.

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

---

11. Итеративная модель. Стадии, преимущества, недостатки.

https://qalight.com.ua/baza-znaniy/iterativnaya-model-iterative-model/

12. Основные отличия итеративного подхода от модели водопада.

	Agile	Waterfall
Суть	Гибкая модель разработки, основанная на итеративных принципах	Каскадная система разработки, основанная на жесткой последовательности процесса разработки
Принципы применения	наивысший приоритет в удовлетворении потребностей заказчика на протяжении всего проекта команда и заказчик ежедневно взаимодействуют между собой и друг с другом работающий продукт — главный показатель прогресса работу можно доверить только самоорганизованной, мотивированной команде оптимальные сроки выпуска рабочего продукта — от 2 недель до 2 месяцев.	жёсткая последовательность этапов разработки переход к новому этапу — только после успешного завершения предыдущего фиксированная стоимость продукта заказчик не привлекается к непосредственному процессу разработки изменения могут быть внесены только после завершения всего процесса разработки.
Плюсы	высокий уровень взаимодействия между членами команды проекта быстрый результат (рабочий код) в итоге «спринтов» стимулирование изменения и улучшений продукта во время его разработки непосредственное вовлечение заказчика к рабочему процессу.	понятная и чёткая схема рабочего процесса возможность просчёта точного количества затраченных на проект ресурсов не требует затрат по налаживанию коммуникаций между всеми членами команды.
Минусы	риск бесконечных изменений продукта большая зависимость от уровня квалификации и опыта команды практически невозможно точно подсчитать итоговую стоимость проекта.	приоритет формального подхода к последовательности процесса работы невозможность внесения изменений заказчиком до окончания разработки продукта в случае нехватки ресурсов страдает качество проекта из-за сокращения этапа тестирования.
Подойдёт вам, если...	над проектом работает опытная команда вы работаете над стартапом нужно быстро получить рабочую версию продукта заказчик выступает в качестве партнёра, а не инвестора продукт создается в сфере, подверженной постоянным изменениям.	большая часть или вся работа над проектом проводится на аутсорсе у вас есть чёткая концепция продукта, который хотите получить вы не ограничены во времени и ресурсах создания продукта создание продукта или бизнеса построено на соблюдении строгой последовательности выполнения задач.
Не подойдёт, если...	вы не готовы тратить дополнительные ресурсы на налаживание ежедневной стабильной коммуникации между всеми участниками процесса продукт должен быть создан к конкретному сроку бюджет проекта строго ограничен вам нужна детальная документация по всем процессам разработки.	вы хотите создать инновационный продукт или крупный проект вы не уверены в концепции предлагаемого проекта финансовые ресурсы не являются ключевым ограничителем в вашем проекте.

---

13. Методология RUP

RUP (Rational Unified Process) – методология разработки ПО, созданная компанией Rational Software

Основные принципы:

1 — ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков

2 — концентрация на выполнении требований заказчиков к исполняемой программе

3 — ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки

4 — компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта

5 — постоянное обеспечение качества на всех этапах разработки проекта (продукта)

6 — работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам

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

Полный жизненный цикл разработки ПО состоит из 4 этапов:


1. Начальная стадия (Inception)

В фазе начальной стадии:

• 
  Формируются видение и границы проекта.
  
• 
  Создается экономическое обоснование (business case).
  
• 
  Определяются основные требования, ограничения и ключевая функциональность продукта.
  
• 
  Создается базовая версия модели прецедентов.
  
• 
  Оцениваются риски.
  

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

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

Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

---

Смотрите также файлы

• Реферат курсовая работа "Ресурсосбережение и определение оптимального соотношения ресурсов для конкретного предприятия".doc

• Н. П. Бахарев (И. О. Фамилия) Тольятти 2023 г.docx

• Ревизия финансово хозяйственной деятельности бюджетных учреждений.doc

• Жанры кино.docx

• Повышение духовной культуры народа в современных условиях очень актуально.doc