ВОПРОСЫ ГОСУДАРСТВЕННОГО ЭКЗАМЕНА

211

К оглавлению ↑

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

Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. Спринт — итерация, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель.

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

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».

Названия были использованы из-за шутки:

Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Основные роли:

•Скрам-мастер (ScrumMaster) – проводит совещания следит за соблюдением всех принципов, разрешает противоречия и защищает команду от отвлекающих факторов. Только ведет скрампроцесс.

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

•Скрам-команда (Scrum Team) – кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат. Неосновные роли:

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

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

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

•Эксперты-консультанты (Consulting Experts) Ежедневное совещание (Daily Scrum meeting):

•начинается точно вовремя;

•все могут наблюдать, но только основные говорят;

•длится не более 15 минут;

•проводится в одном и том же месте в течение спринта.

Втечение совещания каждый член команды отвечает на 3 вопроса:

4.Что сделано с момента предыдущего ежедневного совещания?

5.Что будет сделано с момента текущего совещания до следующего?

6.Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

212

К оглавлению ↑

Особенности управления проектированием ИС в образовании (ХЗ, но…).

 Понятие Прокудина Д.Е.

Информатизация образования – целенаправленная деятельность по разработке и внедрению ИКТ в:

учебный процесс для подготовки граждан к жизни и деятельности в условиях современного информационного общества; повышения качества общеобразовательной и профессиональной подготовки специалистов на основе широкого использования ИКТ;

управление системой образования для повышения эффективности и качества процессами управления;

методическую и научно-педагогическую деятельность для повышения качества работы педагогов; разработки и внедрению новых образовательных технологий на основе использования ИКТ.

Проект НФПК ИСО

…проект ИСО делает самую масштабную и системную за прошедшие 20 лет попытку решать вопросы информатизации школы в тесной связи с повышением качества учебного процесса, изменением парадигмы образования, обновлением способов педагогической деятельности

Проблемы, решаемые в проекте

1.Растущее неравенство в доступе к образовательным услугам.

2.Неравенство региональных возможностей в сфере образования.

3.Снижение качества преподавания.

4.Недостаточная готовность учащихся использовать свои знания в реальных жизненных ситуациях.

5.Недостаточный уровень подготовки педагогов и других работников сферы образования к использованию ИКТ в учебном процессе.

6.Несоответствие содержания начального профессионального образования требованиям рынка труда.

 Цели проекта:

1.Обеспечение активной учебной работы школьников

2.Поддержка развития творческой работы педагогов и педагогических коллективов

3.Обеспечение доступности качественных образовательных услуг для каждого школьника  Цифры  Два этапа: март 2005 – июнь 2008, июль 2008 – июнь 2010.

 50 регионов страны  6 тыс. школ, 400 тыс. пед. работников

 150 учебно-методических комплектов, 75 тыс. цифровых информационных источников  МБРР $100 млн.+ РФ $33,5 млн. + Федеральный бюджет $10,9 млн. + Регионы $22,6 млн.  Вопросы, подлежащие разрешению

1.Вводимые в компьютер данные должны быть формализованы и однозначно представлены.

2.Введенные в компьютер данные должны быть правильно интерпретированы программами обработки.

3.Машинные массивы (файлы) должны быть организованы так, чтобы можно было эффективно оперировать с ними, с учетом ограниченных технических возможностей компьютера

4.Между состоянием процесса обучения и его отображением в файлах должно быть обеспечено взаимно однозначное соответствие

Литература: [1], [2], [4].

4. Анализ компромиссов и рисков программного проекта

Управление рисками.

213

К оглавлению ↑

Управление рисками

Если какая-нибудь неприятность может случиться, она случится. Закон Мерфи

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

Риски “неизвестные” – те, которые не идентифицированы и не могут быть спрогнозированы. Девиз разработчиков программного обеспечения из Microsoft:

«Мы не боремся с рисками — мы ими управляем».

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

Процедуры управления рисками.

В стандарте Project Management Body of Knowledge, принятом в 2000 году, описаны шесть процедур управления рисками:

1.Планирование управления рисками – выбор подходов и планирование деятельности по управлению рисками проекта.

2.Идентификация рисков – определение рисков, способных повлиять на проект, и документирование их характеристик.

3.Качественная оценка рисков – качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

4.Количественная оценка – количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

6.Мониторинг и контроль рисков - мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.

Треугольник компромиссов.

Треугольник компромиссов

Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов:

214

К оглавлению ↑

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

Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений.

Целевой коридор обозначает приемлемый срок завершения проекта

Соотношение между сроками и затратами Соотношение между качеством и затратами Соотношение между сроками и качеством

Три зоны взаимозависимости между сроками и качеством:

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

Во втором секторе обстоятельства идеальны, а значит, и качество соответствующее.

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

Работа с заказчиком.

216

К оглавлению ↑

•Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл.

•Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время реакции системы Вы ожидаете? Три секунды?

•Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам печатать ответ, отправлять его по электронной почте и факсу? Быть может, пользователю нужна только возможность печати отчета и отправки его по электронной почте, но нет необходимости в факсе.

•На этом этапе, не спрашивайте о деталях реализации. Например: Вы предпочитаете list-box или radio-buttons для выбора метода оплаты?

•Не используйте слишком длинные и сложные вопросы.

•Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.

•Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в сценарии интервью.

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

•Фиксируйте каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным.

•Спросите пользователей о дополнительной информации (экранные формы системы).

•При разговоре с заказчиками не говорите о том, будет ли их требование выполнено или нет. Это будет решено позже.

•В конце разговора спросите вопрос для получения дополнительной информации, например «Что еще я должен знать?».

•Выясните у заинтересованного лица приоритет для каждого требования.

•Делайте примечания или используйте записывающее устройство.

•Вопросы должны быть контекстно-свободными, т.е. не содержать желаемый ответ.

•Все требования заносятся в «архив требований», т.е. должны документироваться.

Анкетирование

•Анкеты наиболее полезны, когда есть возможность задать одни и те же вопросы многим заинтересованным лицам, и не надо задавать дополнительные вопросы в процессе беседы.

•Меньше расходов.

•Анкеты структурированные и не интерактивны, получается меньший контроль над результатами.

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

Семинар

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

•Системный аналитик выступает в качестве организатора семинара.

Использование сценариев

•Идея сценариев – применение визуальных или графических инструментов для иллюстрирования желаемого поведения системы.

•Организатор семинара показывает первоначальные сценарии группе.

•На основании полученных комментариев от участников, сценарии корректируются и показываются вновь.

218

К оглавлению ↑

«Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки» и т.п.

В дальнейшем возврат к приоритетам может сильно помочь при нахождении компромисса внутри проектной группы Внимание: представитель заказчика тоже является членом проектной группы.

Проявляйте гибкость – будьте готовы к переменам!

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

Проектная группа должна быть готова к переменам и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.

Основные риски при реализации ИТ-проекта и ИТ-проекта в образовании.

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

•несоблюдении сроков реализации проекта,

•превышения стоимости и

•несоблюдения параметров качества.

•Основные риски реализации ИТ–проекта

•Отсутствие системного аналитика для постановки задачи управления на предприятии.

•Сопротивление сотрудников.

•Увеличение нагрузки во время реализации проекта.

•Отсутствие лидера и квалифицированной команды.

•Изменение целей в ходе реализации проекта.

Барии Боэм приводит список 10 наиболее распространенных рисков программного проекта:

1.Дефицит специалистов.

2.Нереалистичные сроки и бюджет.

3.Реализация несоответствующей функциональности.

4.Разработка неправильного пользовательского интерфейса.

5."Золотая сервировка", перфекционизм, ненужная оптимизация и оттачивание деталей.

6.Непрекращающийся поток изменений.

7.Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8.Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9.Недостаточная производительность получаемой системы.

10."Разрыв" в квалификации специалистов разных областей знаний.

Таблица оценки рисков. Примеры.

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

В качестве основных мероприятий, направленных на избежание возникновения этих рисковых ситуаций в ИТ–проектах, являются:

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

•Повышение мотивации рядовых сотрудников путем материального стимулирования

•Привлечение сторонних квалифицированных специалистов

•Обучение членов команды и топ–менеджмента методологии управления проектами.

219

К оглавлению ↑

•Для сбора информации о рисках могут применяться подходы:

•Опрос экспертов

•Мозговой штурм

•Метод Дельфи

•Карточки Кроуфорда Все риски оцениваются в матрице компромиссов

Таблица 9

•Риск – событие. Формулировка должна быть конкретная и однозначная. Например, погодные условия.

•Последствия наступления риска – что будет плохого.

•Анализ и управление рисками проекта.

•Меры по минимизации - действия, если событие уже произошло.

Литература: [1], [2].

5. UML как язык объектно-ориентированного проектирования

Возможности UML для проектирования информационных систем.

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт,

использующий

графические обозначения для создания абстрактной модели системы, называемой UMLмоделью.

UML был создан для определения, визуализации, проектирования и документирования, в основном,

программных систем. UML не является языком программирования, но на основании UMLмоделей

возможна генерация кода.

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), агрегация (aggregation) и поведение) и больше сконцентрироваться

на

проектировании и архитектуре.

UML позволяет описывать систему следующими моделями:

• Модель функционирования (показывает, как описывается функциональность системы с

точки

зрения пользователя).

•Объектная модель (показывает, как выглядит проект системы с точки зрения объектного подхода).

•Динамическая модель (показывает, как взаимодействуют друг с другом компоненты системы

в

динамике, с течением времени). Демонстрирует, какие процессы происходят в системе.

Взаимосвязь и рекомендуемая последовательность диаграмм языка.

Диаграммы UML предназначены для визуального отображения моделей и их компонентов.

220

К оглавлению ↑

UML 2.0 содержит 13 типов диаграмм. В том числе:

•Структурные диаграммы (6).

•Диаграммы поведения (3).

•Диаграммы взаимодействия (4).

Структурные диаграммы: диаграммы классов, компонентов, коопераций.

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

Классы - это строительные блоки любой объектно-ориентированной системы. Они представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

Диаграмма классов - это набор статических, декларативных элементов модели.

Могут применяться и при прямом проектировании, то есть в процессе разработки новой системы,

и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++).

Конечный результат проектирования и отправная точка процесса разработки.