При описании общей логики функциональности рекомендуется использовать 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.
Фактическая оценка результатов по итогам пилотной эксплуатации.
Если разработанная система использовалась в эксплуатации, то рекомендуется описать фактические результаты и, по возможности, привести оценки экспертов в части финансовых результатов.
Расчет экономической эффективности инвестиций в проект.
Эффективность инвестиций в проект в общем виде сводится к нормированию финансового результата к затратам. Существует большое разнообразие коэффициентов и показателей, формализующих результат. В ВКР можно использовать любые.
Заключение
Заключение – важнейший, наряду с введением, раздел ВКР, который обязательно внимательно изучается членами ГАК. Оно должно показывать выполненную работу объективно и с наилучшей стороны и, при этом, быть максимально кратким.
Рекомендуется следующая формальная структура заключения:
Констатация выполнения задач и достижения цели проекта с указанием наиболее интересных и важных результатов.
Перечисление проблем, не решенных в рамках проекта, на которые автор предполагает направить дальнейшую деятельность.
Не рекомендуется использование в заключении иллюстративного материала и таблиц.
Название темы, реквизиты автора и научного руководителя.
Цель, задачи, методы (1 – 2 слайда).
Краткая характеристика объекта (название, род деятельности).
Модели бизнес-процессов, подлежащих оптимизации (1 – 2 слайда).
Описание предлагаемого решения, позволяющего нейтрализовать негативный эффект от выявленной проблемы.
Экономика проекта: затраты, доходность, срок окупаемости (1 – 2 слайда).
Заключение, наиболее важные выводы.
Рекомендуется строить доклад по одной из двух схем изложения:
Использовать слайды в качестве опорного «скелета», который наращивается устной информацией.
Проговаривать главную линию доклада устно, отсылая слушателей к отдельным слайдам как к иллюстративному материалу.
Не рекомендуется читать текст с экрана.
В силу ограниченности времени и необходимости жесткого контроля за ним со стороны докладчика, не рекомендуется использование сложных мультипликационных презентаций. Допустимо коротких видео-вставок, иллюстрирующих работу программного продукта.