Файл: Методические указания.doc

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

Заинтересованные лица проекта (stakeholders) – это, например, юридические и физические лица, финансирующие проект, предоставляющие временные трудовые ресурсы. В рамках ВКР достаточно их перечислить с указанием конкретных степеней заинтересованности.

2.2. Описание функциональных требований проекта

• Описание методологии и техник выявления требований.

Рекомендуется охарактеризовать методики выявления и спецификации требований в рамках дипломного проектирования. Как правило, используются:

• различного рода анкетирования специалистов (желательно привести в приложениях разработанные анкеты), подразумевающие статистическую или неформальную обработку результатов;

• круглые столы и мозговые штурмы (привести протоколы проведения мероприятий);

• интервьюирования специалистов;

• согласования промежуточных моделей и сценариев.

Практически всегда используется большое количество нотаций для представления результатов as-is: группа диаграмм IDEF, различные виды диаграмм UML, бизнес-моделирование BPMN и др. Желательно кратко обосновать выбор тех или иных средств.

• Описание бизнес-логики и функциональных требований.

Постановка задачи на разработку информационного продукта или на адаптацию и внедрение существующего многотиражной системы обязательно подразумевает максимально полное и однозначное описание функциональных требований. Рекомендуется разбить их на блоки по важности: абсолютно необходимая функциональность, желательная функциональность, возможная функциональность и исключенные из рассмотрения функции (модель MoSCoW – Mast Have, Should Have, Could Have и Would’t Have). Обобщенно такой набор требований считается бизнес-логикой проектируемой системы.

Наиболее важные направления бизнес-логики:

• Сценарные модели и схемы взаимодействия с разрабатываемой системой бизнес-пользователей.

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

• Требования к хранилищам данных и серверной логике (максимально полное описание баз данных в ERD-формате, требования к целостности данных, распределение функциональности между «клиентом» и «сервером», необходимость и спецификация организации витрин данных (Data Marts) и т.д.).

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

• Форматы и интерфейсы обмена данными между программами и в сетевой среде (основные протоколы, необходимость подключения стандартных программ, OLE-механизмы, необходимость XML-формата и т.д.).

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

---

При описании общей логики функциональности рекомендуется использовать UseCase и SwimLane (SADT).

При описании отдельных функций системы рекомендуется использовать инструментарий UML: диаграммы активности, диаграммы последовательностей и диаграммы состояний.

• Анализ нефункциональных требований.

Существенным элементом бизнес-логики являются нефункциональные требования:

• Требования к производительности: рекомендуется определить количество транзакций в секунду, время ожидания и отклика, характеристики пиковых нагрузок и количества одновременно работающих в системе (особенно важно для OLTP-систем).

• Требования к операционной среде (локальная, сетевая, Интернет) и пропускной способности каналов связи с серверами.

• Требования к точности вычислений.

• Требования к оперативной и долговременной памяти.

• Требования к технической безопасности и надежности системы (наработки на отказ, необходимость резервирования данных и т.д.).

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

• Анализ проектных ограничений.

Рекомендуется описать факторы, которые ограничивают возможности проектирования и программирования. Ограничения могут быть:

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

• ограничения, налагаемые операционной средой продукта, например типы и версии установленных Web-браузеров;

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

• совместимость с продуктами, выпущенными ранее;

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

2.3. Цели и бизнес-требования проекта, описание критериев успеха:

• Технико-экономическое обоснование проекта (ТЭО).

Задача ТЭО – обосновать перспективы развития бизнеса после внедрения предлагаемых проектом информационных технологий. Возможно как качественное описание результатов, так и оценка финансового результата. Рекомендуется методология BSC (Balanced Scorecard, метод сбалансированных показателей) и KPI (Key Performance Indicators, метод ключевых показателей).

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

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

Финансовые цели:

• Освоить Х% рынка за Y месяцев;

• Увеличить сектор рынка в стране X на Y% за Z месяцев;

• Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев;

• Получить Х% прибыли или дохода по инвестициям в течение Y месяцев;

• Достигнуть положительного баланса по этому продукту в течение Y месяцев;

• Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы;

• Уменьшить затраты на поддержку на Х% за Z месяцев;

• Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара;

• Увеличить валовую прибыль для существующего бизнеса с Х до Y%.

---

Нефинансовые цели:

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

• Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%

• Достигнуть определенного времени для достижения доминирующего положения на рынке

• Разработать надежную платформу для семьи связанных продуктов

• Разработать специальную базовую технологическую основу для организации

• Получить X положительных отзывов в отраслевых журналов к определенной дате

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

• Соответствовать определенным федеральным и государственным постановлениям

• Уменьшить время обработки до X часов на Y% звонков покупателей в службу поддержки

• Календарно-ресурсное планирование проекта (включая управление командой).

Рекомендуется в качестве базового документа для планирования и управления проектом составить и проанализировать ресурсно-календарный план в формате диаграммы Ганта или сетевого графика (оптимальный инструмент – Ms Project). Особый интерес представляют события-вехи проекта, которые желательно охарактеризовать в терминах отчетных промежуточных документов и артефактов. Также рекомендуется описать критерии достижения конкретных вех.

Обязательными рабочими документами дипломного проекта, которые также должны быть приведены в данном разделе и которые во многом могут быть получены из программы Ms Project, являются:

• матрица ролевых кластеров участников проекта (даже для случаев, когда на проекте один исполнитель эта матрица будет не пустой – автор ВКР в разных фазах участвует в разных ролях);

• бюджет проекта.

При описании управления проектом рекомендуется использовать один из стандартов PMBOK, SWEBOK, MSF.

• Анализ рисков, определение метрик для мониторинга риска.

Основными документами данного раздела, как правило, являются:

• главная таблица рисков;

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

Глава 3. Архитектура проекта и оценка экономической эффективности

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

3.1. Системная архитектура проекта

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

3.3. Расчет затрат на реализацию проекта и описание ожидаемого экономического эффекта от использования результатов проекта/автоматизации

---

• Анализ затрат на оплату труда.

В небольших проектах затраты на заработную плату составляют наибольшую часть расходов.

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

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

• Анализ затрат на ресурсное обеспечение.

Наиболее существенные затраты, помимо стоимости рабочей силы:

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

• Стоимость расходных материалов.

• Стоимость энергии и аренды помещения.

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

• Анализ качественных и количественных факторов воздействия проекта на бизнес-архитектуру организации.

Разработанная информационная система должна рассматриваться как средство оптимизации (реинжиниринга) бизнес-процессов предприятия, а ее использование (фактическое или подразумевающееся) должно оказывать существенное влияние на бизнес в моделях «как должно быть». Как правило, внедрение ИС приводит к результатам следующего вида:

• улучшение производительности процесса;

• меньшее количество ошибок;

• лучшая управляемость процесса;

• снижение себестоимости итогового продукта (результата);

• ускорение бизнес-процесса;

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

• соответствие соответствующим стандартам и правилам (в том числе лучшим практикам);

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

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

• Фактическая оценка результатов по итогам пилотной эксплуатации.

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

• Расчет экономической эффективности инвестиций в проект.

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

---

Заключение

Заключение – важнейший, наряду с введением, раздел ВКР, который обязательно внимательно изучается членами ГАК. Оно должно показывать выполненную работу объективно и с наилучшей стороны и, при этом, быть максимально кратким.

Рекомендуется следующая формальная структура заключения:

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

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

Не рекомендуется использование в заключении иллюстративного материала и таблиц.

---