Материал: [3 курс] Вопросы к экзамену Программная инженерия

Наблюдая за прогрессом проекта, очень полезно будет использовать метод оценки, основываясь на очках, которые являются значениями, присуждаемыми всем документированным требованиям. Данные очки не составляются из рабочего времени или отображают денежные затраты, которые не отражают продуктивность. Вместо этого данная оценка делается согласно результатам команды относительно уровня сложности их работы, а также их собственной оценки личной продуктивности или опыта. После каждой итерации проектные команды изучают свои результаты и баллы и выполняют необходимые модификации по ходу работы к следующей итерации разработки. Прогресс также измеряется в баллах сценариев использования (use-case points), которые измеряют функциональность системы, а также сложность проекта, относящуюся к окружающей среде и технической стороне. Они позволяют спонсорам получить лучшее представление количества ресурсов, которые необходимо предоставить проектной команде, а также договориться и установить контрольные точки проекта. Показатели качества обозначают соответствие с требованиями и больше работают с проблемами благодаря множеству итераций. Ключевым преимуществом гибкой методологии является раскрытие дефектов на ранних стадиях проекта - поэтому, проверка качества предотвращает последующую переработку на протяжении проекта. Управление проектом, основанным на гибкой методологии, в большей степени заключается в управлении людьми. Исследования показали, что в целом мотивация людей напрямую зависит от индивидуальных качеств. Количество личного вклада, который люди привносят в проект, связано с тем, как они могут справляться со стрессом при подходе к следующей итерации и как проблемы сообщаются во время разработки и при переработке. Стрессовая обстановка в команде вызывает трения, что является основной проблемой в случае с аутсорсингом. Чем выше мораль и мотивация, тем эффективнее будут работать члены команды, тем больше трений вы предотвратите и больше производительности будет отражено на качестве товара.

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель (средний спринт 4-6 дней). Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Спринты могут раздаваться по типу аукциона, т.е. команды разработчиков в буквальном смысле уменьшают количество дней на разработку модуля программы

Характеристики Scrum:

1. Минимизация срока исполнения

2. Максимально частые контакты с Product Owner (заказчиком)

3. Максимальная мотивированность Scrum команды на выполнение задачи (на результат)

4. Конкурная раздача спринтов

5. Коллективное принятие решений и помощь

6. Kanban (доска позора)

7. BYod (Bring Your own device) – принеси с собой свое устройство

Основные роли (Core roles) в методологии скрам:

1. Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.

2. Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

3. Команда Разработки (Development Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Дополнительные роли (Ancillary roles) в методологии скрам:

1. Пользователи (Users)

2. Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

3. Управляющие (Managers) — люди, которые управляют персоналом.

4. Эксперты-консультанты (Consulting Experts)

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

Отличие FDD от Scrum в том, что у команды разработчиков нет общего образа будущего решения. Есть только постоянно обновляемый и дополняемый список функций, который однажды вместе составит решение.

FDD включает в себя пять базовых видов деятельности:

1. разработка общей модели;

2. составление списка необходимых функций системы;

3. планирование работы над каждой функцией;

4. проектирование функции;

5. реализация функции.

Первые два процесса относятся к началу проекта. Последние три осуществляются для каждой функции. Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых предполагает реализацию определенного набора функций.

Разработка общей модели

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

Составление списка возможностей

Информация, собранная при построении общей модели, используется для составления списка функций. Это осуществляется разбиением областей (англ. domain) на подобласти (предметные области, англ. subject areas) с точки зрения функциональности. Каждая отдельная подобласть соответствует какому-либо бизнес-процессу, шаги которого становятся списком функций (свойств). В данном случае функции — это маленькие части понимаемых пользователем функций, представленных в виде «<действие> <результат> <объект>», например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо разбить на несколько подзадач, каждая из которых сможет быть завершена за установленный двухнедельный срок.

План по свойствам (функциям)

После составления списка основных функций, наступает черёд составления плана разработки программного обеспечения. Владение классами распределяется среди ведущих программистов путём упорядочивания и организации свойств (или наборов свойств) в классы.

Проектирование функций

Для каждого свойства создается проектировочный пакет. Ведущий программист выделяет небольшую группу свойств для разработки в течение двух недель. Вместе с разработчиками соответствующего класса ведущий программист составляет подробные диаграммы последовательности для каждого свойства, уточняя общую модель. Далее пишутся «болванки» классов и методов, и происходит критическое рассмотрение дизайна.

Реализация функции

После успешного рассмотрения дизайна, данная видимая клиенту функциональность реализуется до состояния готовности. Для каждого класса пишется программный код. После модульного тестирования каждого блока и проверки кода, завершенная функция включается в основной проект.

План ответа на вопрос 10.

1. Реинжиниринг бизнес-процессов

Reengineering – переосмысление и пересмотр логики проблемного бизнес-процесса с целью повышения его эффективности.

2 подхода реинжиниринга:

1. Когда сюда входит планирование и анализ требований, проектирование, реализация, внедрение, эксплуатация (все 5 фаз ЖЦ).

2. Когда сюда входит только планирование и анализ требований (выяснение требований, подписание контракта)

Реинжиниринг тесно связан с понятием процессного подхода, принятием решений в условиях мини-проектов, нестатичности функции (например, взяли на склад, а вы работаете в другом отделе) и нацеленности на результат.

2. Принципы реинжиниринга

1. Принцип первого руководителя

2. Минимизация мониторинга и контроля (Agile -> Scrum)

3. Работник, ответственный за свою функцию, самостоятельно принимает не решения, а способ ее выполнения

4. Работа выполняется там, где это целесообразно.

KPI – ключевые показатели активности (отображают качество работы)

5. Принцип вертикального/горизонтального сжатия

Объединение нескольких отделов в один по горизонтали, либо убирают сотрудников по вертикали (и распределяют его функции)

6. Принцип минимизации отчетных документов

7. Принцип «у каждого процесса свой владелец»

3. Процессный подход -> работа на результат (функция выполняется всеми сразу и никем одновременно)

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

Люди объединяются в группы, которые работают в рамках бизнес-процесса — т.е. заранее определённых шагов и с ожидаемым результатом. Например, чтобы подготовить коммерческое предложение должны отработать 5 человек — менеджер по продажам, сотрудник производства, маркетолог, юрист и курьер.

К основным понятиям РПБ относятся понятия «фундаментальный», «радикальный», «существенный» и «процессы».

1. Фундаментальный. РБП начинается с «чистого листа» -никаких готовых предложений, ничего заранее заданного. Компания, приступающая к реинжинирингу должна избегать традиционных подходов. РБП прежде всего призван определить, чем компания действительно должна заниматься, и только потом уже – как она должна это делать. При РБП ничего не принимается на веру как нечто само собой разумеющееся. РБП игнорирует то, что есть, он нацелен на то, что должно быть.

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

3. Существенный. РБП не имеет ничего общего с небольшими частичными или приростными улучшениями, он призван обеспечить общий мощный рост результатов. РБП нужен только тогда, когда ощущается потребность осуществить серьезный прорыв. Частичные улучшения требуют тонкого, деликатного подхода; существенные улучшения достигаются только путем решительного отсечения всего старого, отжившего и замены его на новое и жизнеспособное.

4. Процессы. Бизнес-процессы можно определить, как совокупность различных видов деятельности, в рамках которой «на входе» используются один или более видов ресурсов, и в результате этой деятельности на «выходе» создается продукт или услуга, представляющие ценность для потребителя.

В результате успешно проведенного РБП, т.е. быстрого осуществления глубоких и всесторонних коренных изменений системы управления — компания достигает существенного, «прорывного» роста эффективности (в десятки и сотни раз).

К основным свойствам РБП относятся:

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

• Пренебрежение действующими системами, структурами и процедурами компании и радикальное изменение способов хозяйственной деятельности – если невозможно переделать свою деловую среду, то можно переделать свой бизнес;

• Приведение к значительным изменениям показателей деятельности (на порядок отличающихся от предыдущих).

Реинжиниринг необходим в случаях потребности очень существенных улучшений, например, таких как эти 3 основные ситуации, требующие вмешательства:

1. В условиях, когда предприятие находится в состоянии глубокого кризиса. Этот кризис может выражаться в явно неконкурентном уровне издержек, массовом отказе потребителей от продукта предприятия и т.п.

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

3. Реализацией возможностей РБП занимаются благополучные, быстрорастущие и «агрессивные» организации. Их задача состоит в ускоренном наращивании отрыва от ближайших конкурентов и создании уникальных конкурентных преимуществ

Основные приемы проведения РБП (принципы РБП) следующие:

· Несколько работ комбинируются в одну. Определяется конкретный человек, несущий ответственность за все шага процесса от начала до конца. Благодаря этому появляется тот, который может ответить на любые вопросы, возникающие у клиента. Этот человек часто называется менеджером клиентов. В тех случаях, когда один человек не может справиться со всеми работами в процессе, организуется группа с аналогичными функциями и ответственностью.

· Работники сами принимают решения. В отличие от периодических принятий самостоятельных решений, естественных в любой реальной работе, в этом случае принятие решений вводится в функциональные обязанности работника. Такой подход применяется и к рабочим, и к управленцам.

· Шаги в процессе выполняются в их естественном порядке. Этот порядок не фиксируется директивным предписанием. Он определяется работниками по ходу выполнения работ и в соответствии с реальной обстановкой. Многие шаги могут выполняться параллельно.

· Процессы имеют множество версий. Это весьма существенно для условий, отличающихся от массового промышленного производства.

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

· Контрольные проверки и объемы управления сокращаются. Так как управление не создает прямой добавленной потребительной стоимости, оно вводится только на тех участках работ, где это имеет экономический смысл. Уменьшается кол-во документов.

Процессный подход это одна из концепций управления, которая окончательно сформировалась в 80-х годах прошлого века. В соответствии с этой концепцией вся деятельность организации рассматривается как набор процессов. Для того чтобы управлять, необходимо управлять процессами. Он стал одним из ключевых элементов улучшения качества.

Процессный подход основывается на нескольких принципах. Внедрение этих принципов позволяет значительно повысить эффективность работы, однако вместе с тем, требует и высокой корпоративной культуры. Переход от функционального управления к процессному требует от сотрудников постоянной совместной работы, несмотря на то, что они могут относиться к различным подразделениям. От того, насколько удастся обеспечить эту совместную работу, будет зависеть «работоспособность» принципов, заложенных в процессный подход.