![]() КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Описание функциональных требований проекта· Описание методологии и техник выявления требований. Рекомендуется охарактеризовать методики выявления и спецификации требований в рамках дипломного проектирования. Как правило, используются: - различного рода анкетирования специалистов (желательно привести в приложениях разработанные анкеты), подразумевающие статистическую или неформальную обработку результатов; - круглые столы и мозговые штурмы (привести протоколы проведения мероприятий); - интервьюирования специалистов; - согласования промежуточных моделей и сценариев. Практически всегда используется большое количество нотаций для представления результатов 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.
· Анализ рисков, определение метрик для мониторинга риска. Основными документами данного раздела, как правило, являются: - главная таблица рисков; - паспорта основных рисков (включая планы мероприятий по предотвращению важнейших рисков и по устранению последствий).
|