Merge branch 'master' of http://213.155.192.79:3001/ypv/ISRPO

Лекции/ЖЦПО/ЖЦПО_Петров.md

@@ -0,0 +1,105 @@
+**Модель жизненного цикла программного обеспечения**
+
+Структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
+Эти модели можно разделить на 3 основных группы:
+1)Инженерный подход
+2)С учетом специфики задачи
+3)Современные технологии быстрой разработки
+Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.
+
+**Модель кодирования и устранения ошибок**
+
+Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.
+
+Данная модель имеет следующий алгоритм:
+
+1)Постановка задачи
+
+2)Выполнение
+
+3)Проверка результата
+
+4)При необходимости переход к первому пункту
+
+Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.
+
+**Каскадная модель жизненного цикла программного обеспечения (водопад)**
+
+Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.
+
+![Каскадная.gif](Каскадная.gif)
+
+**Преимущества:**
+
+1)Последовательное выполнение этапов проекта в строгом фиксированном порядке
+
+2)Позволяет оценивать качество продукта на каждом этапе
+
+**Недостатки:**
+
+1)Отсутствие обратных связей между этапами
+
+2)Не соответствует реальным условиям разработки программного продукта
+
+Относится к первой группе моделей.
+
+**Каскадная модель с промежуточным контролем (водоворот)**
+
+Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку. Относится к первой группе моделей.
+
+**V модель (разработка через тестирование)**
+
+Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.
+
+![V модель.png](V модель.png)
+
+**Модель на основе разработки прототипа**
+
+Данная модель основывается на разработки прототипов и прототипирования продукта.
+**Прототипирование** используется на ранних стадиях жизненного цикла программного обеспечения:
+
+1)Прояснить не ясные требования (прототип UI)
+
+2)Выбрать одно из ряда концептуальных решений (реализация сцинариев)
+
+3)Проанализировать осуществимость проекта
+
+**Классификация протопипов:**
+
+1)Горизонтальные и вертикальные
+
+2)Одноразовые и эволюционные
+
+3)бумажные и раскадровки
+
+**Горизонтальные прототипы** — моделирует исключительно UI не затрагивая логику обработки и базу данных.
+
+**Вертикальные прототипы** — проверка архитектурных решений.
+
+**Одноразовые прототипы** — для быстрой разработки.
+
+**Эволюционные прототипы** — первое приближение эволюционной системы.
+
+Модель принадлежит второй группе.
+
+**Спиральная модель жизненного цикла программного обеспечения**
+
+Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
+
+![Спиральная модель.gif](Спиральная модель.gif)
+
+**Преимущества:**
+
+1)Быстрое получение результата
+
+2)Повышение конкурентоспособности
+
+3)Изменяющиеся требования — не проблема
+
+**Недостатки:**
+
+1)Отсутствие регламентации стадий
+
+Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.
+
+**Большое спасибо за внимание!**

Лекции/ЖЦПО/Итерационная_модель_Петров.md

@@ -0,0 +1,47 @@
+**Итерационная модель имплементации информационных систем**
+
+Попытаемся устранить недостаток однопроходной модели. Для этого каждый из этапов схемы дополним контуром обратной связи, тем самым добавив возможность возврата на предыдущие стадии. Если внимательно проанализировать полученный результат, окажется, что каждый из этапов может выполняться несколько раз. Именно поэтому полученную модель (рис. 4) называют итерационной. Впервые применённая в США ещё в 1957 году, многопроходная итерационная модель основана на концепции IID (Iterative and Incremental Development), включающей принципы итеративности (уточнение и детализация разрабатываемого программного обеспечения шаг за шагом), инкрементальности (увеличение функциональности ПО для каждой итерации) и эволюционности (максимальное использование наработок предыдущих итераций для последующих).
+
+![Итерационныа модель.png](Итерационныа модель.png)
+
+**Рис.4.** Переход от каскадной и итерационной модели внедрения КИС
+
+Разработка ПО согласно концепции IDD сводится к разбиению этапа реализации на серию быстрых, лёгких и адаптивных итераций, оперативно приносящих результаты. Каждая итерация основана на PDCA-цикле Деминга (Plan-Do-Check-Act) и завершается демонстрацией потребителю полученного промежуточного продукта с целью скорейшего выявления потенциальных ошибок. Более того, в ходе выполнения итераций представление о конечном продукте изменяется, поэтому добавляются новые функциональные возможности. Продолжительность каждой итерации варьируется в пределах 1-6 недель, а начальный список требований к ПО вообще может отсутствовать.
+
+**Отметим плюсы итерационной модели:**
+
+1)оперативная разработка и демонстрация ПО для устранения ошибок;
+
+2)допускается отсутствие требований к ПО,
+
+**А также минусы:**
+
+1)отсутствие понимания объёма работ для завершения проекта;
+
+2)ориентированность на разработку, но не кастомизацию ПО.
+
+**Рассмотрим проект имплементации КИС согласно предлагаемой модели:**
+
+1)идентификация и анализ требований, предъявляемых к КИС, а также приоритезация найденных требований (опционально);
+
+2)определение числа и продолжительности итераций разработки КИС, в случае наличия приоритезированных требований их распределение по итерациям разработки;
+
+3)доработка и кастомизация КИС, функциональное и интеграционное тестирование с последующей демонстрацией полученного продукта заказчику для уточнения требований (для всех итераций);
+
+4)проведение приёмочного тестирования;
+
+5)документирование реализованного программного решения;
+
+6)переход к продуктивной эксплуатации и поддержка.
+
+Выполнение итераций подразумевает демонстрацию продукта заказчику, в результате чего выявляются дефекты и идентифицируются новые требования к ПО. Первый минус многопроходной модели формулируется достаточно просто: вновь появляющиеся требования и пожелания клиента могут выйти за временные рамки изначально обсуждённых итераций. Таким образом, необходимо некое мерило требований для отсекания маловажных, что в принципе противоречит самой концепции IID. 
+
+Второй минус выглядит куда более серьёзно: раньше речь шла исключительно о доработке КИС, теперь же непонятно, как быть с кастомизацией и интеграцией. Сначала разберёмся с кастомизацией. Настройке в КИС подлежат уровни данных и бизнес-процессов: организационная структура, процессы, основные и переменные данные. Невозможно выполнить настройку, например, бизнес-процесса в КИС, следуя принципу итеративности. Разумнее всего применить инкрементальный подход: разбить процесс на части и настроить одну часть бизнес-процесса в заданной итерации, а остальные – в следующих. Данный подход применим также к оргструктуре и данным. В итоге получается некий аналог требований: процессы, организационная структура и данные должны быть декомпозированы на объекты и распределены по итерациям. Дальше необходимо понять, полученные объекты включать в начальные или завершающие итерации? Ответ связан с вопросом интеграции.
+
+Интеграцию КИС можно разделить на внутреннюю и внешнюю. Под внутренней интеграцией подразумевается взаимодействие объектов и модулей КИС между собой, например, приход товара на склад должен порождать бухгалтерские проводки. В данном примере присутствуют две сущности различных модулей: приход и проводка, относящиеся к функциональности логистики закупки и финансам соответственно. Второй вид интеграции подразумевает взаимодействие КИС с внешними подсистемами, например, SRM, CRM, WMS и др. Если внутреннюю интеграцию в большей степени можно отнести к кастомизации КИС, то внешнюю – к настройке и доработке. Никакая доработка КИС не может вестись без наличия базовых компонентов системы, которые преимущественно заводятся путём настройки. Тем самым логично в начальные итерации включить кастомизацию КИС и интеграцию, и лишь затем доработку. Поэтому каждая итерация должна включать как функционально-модульное, так и интеграционное тестирование. Суммируя, видится следующая картина реализации итераций:
+
+1)начальные итерации должны включать настройку системы и внутреннюю интеграцию по инкрементальному принципу с целью подготовки основополагающего ядра КИС;
+
+2)последующие итерации содержат доработки КИС, использующие ранее подготовленные функции КИС путём кастомизации.
+
+Резюмируя вышесказанное, применение итерационной модели вполне логично для доработки КИС, настройка же потребует дополнительных манипуляций. Не смотря на статистику, гласящую, что порядка 70% функционала иностранных КИС требуют доработки, пока многопроходная модель применяется в России достаточно редко. Возможно, причина кроется в том, что предпочтение отдаётся максимальному использованию стандартного функционала КИС, то есть кастомизации, против его доработки.

Лекции/ЖЦПО/Каскадная_модель_Петров.md

@@ -0,0 +1,40 @@
+**Каскадная модель внедрения корпоративных информационных систем**
+Воспользуемся типовыми этапами ЖЦ проекта внедрения. Преобразуем линейную последовательность следующим образом: каждый предыдущий этап сместим влево вверх, а каждый последующий – вправо вниз, тем самым получим схему, следующую слева направо и сверху вниз. Каскадная модель внедрения КИС образуется путём соединения полученных этапов между собой (рис. 3). Данная модель или, как часто ее называют, модель водопад (Waterfall) была предложена в 1970 году У. Ройсом.Реализация проекта, согласно данной модели, ведётся путём строгого выполнения задач каждого из этапов (типовые этапы внедрения КИС), при этом переход к последующему этапу возможен лишь в случае успешного завершения предыдущей стадии. Пропуск какого-либо из этапов, возврат к предыдущим стадиям и повторение этапов запрещены, именно по этой причине модель часто именуют последовательной или однопроходной. Следуя рис. 3, очевидны достоинства и недостатки водопадной модели.
+
+**К плюсам можно отнести:**
+
+1)прозрачность определения сроков, работ и затрат;
+
+2)наличие согласованной процедуры перехода между этапами;
+
+3)независимость выполнения этапов,
+
+**Минусами являются:**
+
+1)невозможность устранения ошибок предыдущих этапов;
+
+2)отсутствие гибкости.
+
+![Каскадная модель.png](Каскадная модель.png)
+
+**Рис. 3.** Переход от типовых этапов к каскадной модели внедрения КИС
+
+**Проект внедрения КИС на основе данной модели состоит из активностей:**
+
+1)подготовка проекта, заключающаяся в формировании основных концепций, стратегий и подходов к реализации функционала КИС;
+
+2)идентификация и анализ требований, предъявляемых к КИС и их приоритезация;
+
+3)формирование проектных решений и спецификаций, описывающих способ реализации ранее сформированных требований к КИС;
+
+4)кастомизация и доработка КИС на основе ранее подготовленных решений и спецификаций, описывающих реализацию требований;
+
+5)функционально-модульное, интеграционное и приёмочное тестирование выполненных настроек и доработок КИС;
+
+6)переход к продуктивной эксплуатации и поддержка.
+
+Кроме того, каждый из этапов заканчивается валидацией и согласованием активностей следующей стадии, а также подтверждением возможности перехода к последующему этапу. Вышеприведённый список демонстрирует закономерность: проектирование, реализация и тестирование КИС ведутся на основе требований, идентифицированных на ранних этапах. Тем самым, если изначальные требования были сформированы неверно, вся информационная система будет подготовлена некорректно (ранее отмеченный минус о невозможности устранения ошибок предыдущих этапов), что вероятнее всего потребует доделывания КИС. Отсутствие гибкости модели можно отнести как к минусу, так и плюсу: если ведётся частичное внедрение КИС незначительного по объёму функционала, возможные изменения требований по сравнению с начальными желательно включить в проект. Однако, когда имплементируется многофункциональная КИС, интегрированная с множеством как внешних, так и внутренних подсистем, незначительная корректировка требований может привести к значительным изменениям сроков, работ и затрат.
+
+Именно поэтому каскадную модель часто применяют на проектах внедрения КИС «с нуля» и «тиражирования», когда объём выполняемых работ и их трудозатраты достигают внушительных величин. На подобных проектах возникает конфликт интересов между различными заинтересованными сторонами, поэтому результаты каждого из этапов тщательно документируются и согласуются во избежание разночтений и увеличения объёма работ. Невозможно запустить КИС в масштабах предприятия с учётом требований и пожеланий каждого из сотрудников. Поэтому объём задач фиксируется списком наиболее важных и подтверждённых требований ключевыми, но не конечными пользователями. В случае появления новых или изменения существующих требований предлагается регистрировать запрос на изменение. Суть последнего состоит в следующем: необходимые доработки КИС будут выполнены вне рамок проекта в отдельные сроки и бюджет.
+
+Резюмируя вышесказанное, применение итерационной модели вполне логично для доработки КИС, настройка же потребует дополнительных манипуляций. Не смотря на статистику, гласящую, что порядка 70% функционала иностранных КИС требуют доработки, пока многопроходная модель применяется в России достаточно редко. Возможно, причина кроется в том, что предпочтение отдаётся максимальному использованию стандартного функционала КИС, то есть кастомизации, против его доработки.