- •Практикум 2: Программное средство структурного моделирования процессов ramus.
- •Практикум 3: Создание диаграммы dfd
- •Практикум 4: Выполнение учебного проекта (структурный анализ)
- •4.1.1. Краткая информация о компании "мед"
- •4.1.2. Видение выполнения проекта и границы проекта
- •4.1.3. Отчет об обследовании
- •Практикум 6: Разработка технического задания. Разработка технического задания на создание ис. Источники информации для формирования технического задания. Примеры заполнения разделов документа.
- •6.1.6. Сведения об источниках и порядке финансирования работ
- •6.1.7. Порядок оформления и предъявления заказчику результатов работ
- •6.1. Общие положения
- •6.1.5. Плановые сроки начала и окончания работы по созданию системы
- •6.1.8. Состав используемой нормативно-технической документации
- •6.2. Назначение и цели создания (развития) системы
- •6.2.1. Назначение
- •6.2.2. Основными целями создания аис "Кадры" являются
- •6.3. Характеристика объекта автоматизации
- •6.3.1. Объект автоматизации
- •6.3.2. Существующее программное обеспечение
- •6.3.3. Существующее техническое обеспечение
- •6.3.4. Существующее нормативно-правовое обеспечение
- •6.4. Требования к системе
- •6.4.1. Требования к системе в целом
- •6.4.1.1. Требования к структуре и функционированию системы
- •6.4.1.2. Требования к численности и квалификации персонала системы
- •6.4.1.3. Показатели назначения
- •6.4.1.4. Требования к надежности
- •6.4.1.5. Требования к безопасности
- •6.4.1.6. Требования к эргономике и технической эстетике
- •6.4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
- •6.4.1.8. Требования к защите информации от несанкционированного доступа
- •6.4.1.9. Требования по сохранности информации при авариях
- •6.4.1.10. Требования к защите от влияния внешних воздействий
- •6.4.1.11. Требования к патентной чистоте
- •6.4.1.12. Требования по стандартизации и унификации
- •6.4.2. Требования к функциям (задачам), выполняемым системой
- •6.4.2.1. Подсистема хранения данных
- •6.4.2.2. Подсистема управления нормативно-справочной информацией
- •6.4.3. Требования к видам обеспечения
- •6.4.3.1. Требования к математическому обеспечению системы
- •6.4.3.2. Требования к информационному обеспечению системы
- •6.4.3.3. Требования к лингвистическому обеспечению системы
- •6.4.3.4. Требования к программному обеспечению системы
- •6.4.3.5. Требования к техническому обеспечению
- •6.4.3.6. Требования к метрологическому обеспечению
- •6.4.3.7. Требования к организационному обеспечению
- •6.4.3.8. Требования к методическому обеспечению
- •6.5. Состав и содержание работ по созданию (развитию) системы
- •6.6. Порядок контроля и приемки системы
- •6.6.1. Виды, состав, объем и методы испытаний системы
- •6.6.2. Общие требования к приемке работ по стадиям
- •6.6.3. Статус приемочной комиссии
- •6.7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •6 .8. Требования к документированию
- •6.9. Источники разработки
- •Практикум 7: Спецификации настроек типовой ис
- •7.1. Бизнес-процесс "Планирование закупок и размещение заказов поставщикам"
- •7.2. Бизнес-процесс "Запасы-склад (приходование товара)"
- •7.3. Бизнес-процесс "Продажи"
- •7.4. Бизнес-процесс "Взаиморасчеты с клиентами и поставщиками"
- •Практикум 8: Варианты домашних заданий
- •8.1. Требования к выполнению домашнего задания
- •8.2. Описание бизнес-процесса "План закупок, отгрузок поставщиков"
- •8.3. Описание бизнес-процесса - "Производство собственное"
- •8.4. Описание бизнес-процесса "Закупка сырья и комплектующих в соответствии с планом"
- •8.5. Описание бизнес-процесса "Фасовка на стороне"
- •8.6. Описание бизнес-процесса "Приемка, отгрузка, выписка"
- •8.7. Описание бизнес-процесса "Платежи. Взаиморасчеты с кредиторами"
- •8.8. Описание бизнес-процесса "Поступления. Взаиморасчеты с дебиторами"
- •1. Общие сведения
- •2. Назначение и цели создания системы
- •3. Характеристика объекта автоматизации
- •4. Требования к системе
- •5. Состав и содержание работ по созданию системы
- •6. Порядок контроля и приемки системы
- •7. Требования к документированию
- •8. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •9. Порядок внесения изменений
- •Практикум 10: Пример методики для оценки программных продуктов
- •22.1. Общие положения
- •22.2. Пример оценки программного продукта
- •22.2.1. Оценка существующей функциональности программного продукта
- •22.2.2. Оценка прочих аспектов
- •22.2.3. Система весовых коэффициентов
- •22.3. Основные выводы по результатам анализа программных продуктов
- •Практикум 11: Перечень типовых бизнес-процессов
- •23.1. Перечень типовых бизнес-процессов предприятия
- •1. Анализировать рынок и потребности потребителей
- •2. Разрабатывать видение и стратегию
- •3. Разрабатывать продукты или услуги
- •4. Продавать продукты/услуги
Практикум 6: Разработка технического задания. Разработка технического задания на создание ис. Источники информации для формирования технического задания. Примеры заполнения разделов документа.
Основные принципы работы с требованиями
Требование - это условие или возможность, которой должна соответствовать система. Жизненно важной частью проектирования ИС является формирование требований к создаваемому решению, т.е. разработка технического задания.
Требования отражают потребности достаточно широкой аудитории (заинтересованных сторон, будущих пользователей, заказчиков ИТ - решения и пр.), на удовлетворение которых направлен проект. Однако требования обычно претерпевают существенные изменения по мере реализации проекта: дополняются, модифицируются, сокращаются.
Состав процедур управления требованиями:
"Анализ проблем" - разработка и согласование правильного описания проблемы, решить которую призвана новая система.
"Выявление потребностей пользователей" - сбор информации о действительных потребностях пользователей создаваемого решения и других заинтересованных лиц; идентификация функций системы.
"Определение системы" - преобразование понимания проблемы и потребностей пользователя в обобщенное описание системы, которая будет удовлетворять эти потребности.
"Управление масштабом" - согласование определения системы и ограничений проекта.
"Уточнение определения системы" - разработка детальных требований к системе.
"Построение правильной системы" - методики верификации создаваемого ИТ -решения и управления изменениями.
Задачей процесса анализа проблем является осознание реальных проблем и потребностей заказчика, и предложение решения для удовлетворения этих потребностей.
Процесс включает в себя следующие этапы: 1) Достижение соглашения об определении проблемы; 2) Выделение основных причин; 3) Выявление заинтересованных лиц и пользователей; 4) Определение границ системы, предлагаемой в качестве решения; 5) Выявление ограничений.
Выявление потребностей пользователей
Потребность - это отражение некоей личной, рабочей или бизнес-проблемы (или возможности), решение которой оправдывает замысел создания, приобретение или модернизацию системы.
Выявление потребностей сопряжено с выполнением следующих задач: интервьюирование и анкетирование; совещания, посвященные требованиям; мозговой штурм; применение "раскадровок"; анализ прецедентов; обыгрывание ролей; создание прототипов.
Определение системы
Требования к системе редко удаётся зафиксировать в едином документе. Причины кроются в сложности системы, в организации выявления и документирования требований, система может быть членом семейства родственных продуктов, проектируемая система может удовлетворять только часть выявленных требований и пр. Поэтому на этапе определения системы выбирается формат представления требований. Это может быть иерархическая структура, когда требования задаются для отдельных подсистем. Или один документ может содержать общие определения функций системы, другой - конкретные требования. (Первый обычно называется концепцией, второй - спецификацией требований).
Завершается этап разработкой и согласованием концепции системы, отражающей на верхнем уровне абстракции как проблему, так и решение.
Управление масштабом проекта
Управление масштабом проекта осуществляется с целью выявления реальных рамок проекта. При этом решаются следующие основные задачи: Оценка приоритетов требований; Оценка трудоёмкости выполнения требований; Оценка рисков.
С точки зрения приоритетов функции делятся на критические (без которых система не может существовать), важные и полезные. Трудоемкость и риск оценивается по шкале "низкий - средний - высокий". После этого применяются эвристические правила принятия решений по организации проекта. Например: 1) если функция является критической и имеет высокий риск, то нужно реализовать эффективную стратегию снижения риска; 2) если функция является важной и имеет высокий риск она может разрабатываться "по возможности" или переносится в следующую версию; 3) если функция является полезной и имеет высокий риск, следует рассмотреть возможность её полного удаления.
Таким образом, появляется возможность объективно выделить те функции, которые, с одной стороны, необходимы заказчику, а с другой стороны, могут быть действительно реализованы в рамках проекта.
Уточнение определения системы
На этапе уточнения определения системы осуществляется детализация требований к технической реализации системы, т.е. выявляются разнообразные условия или возможности, которым должна соответствовать система. Таки образом, осуществляется переход от требований в области проблем (определённых на предыдущих этапах) к требованиям в области решений.
Требования в области решений делятся на две группы: функциональные требования и нефункциональные.
Функциональные требования определяют действия, которые должна быть способна выполнить система (без рассмотрения физических связей между её элементами). Они определяют внешнее поведение системы. Функциональные требования используются для выражения поведения системы путем задания предпосылок и возможностей, ожидаемых в качестве результата.
Нефункциональные требования описывают только атрибуты системы или среды. Нефункциональные требования служат для создания системы с приемлемым качеством.
Создание правильной системы
В процессе создания системы осуществляются два вида контроля её правильности: верификация и валидация.
Верификация - постоянно выполняемый процесс оценивания системы с целью определить, удовлетворяют ли результаты некой фазы условиям, наложенным в начале данной фазы, т.е. удовлетворяют ли они потребностям последующей деятельности.
Как минимум, подлежит верификации: соответствие функций потребностям; соответствие функциям производных от них прецедентов и требований; полнота реализация прецедентов при проектировании; поддержка при проектировании функциональных и нефункциональных аспектов поведения системы; соответствие программного продукта результатам и целям проектирования; полнота покрытия тестами требований и прецедентов.
Валидация - процесс оценивания системы (или компонента) во время или по окончании процесса разработки с целью определить, удовлетворяет ли она указанным требованиям.
Сведения о проекте
Заказчик разработки |
Федеральное агентство "Государственные Кадры". |
Структура: центральное агентство, региональные отделения. |
|
Исполнитель разработки |
ООО "Софт" |
Фрагмент иерархии функций агентства
Функции агентства (уровень 1): учет персонала государственных организаций; управление персоналом; анализ; взаимодействие с населением.
Учет персонала государственных организаций (уровень 2): ведение НСИ; сбор и хранение информации о структуре гос. организаций; ведение архивов данных.
Управление персоналом (уровень 2): планирование структуры организаций, штатных расписаний и кадровых политик; расчет заработной платы; оперативный учет движения кадров; ведение административного документооборота по персоналу и учету труда, аттестации и определению потребностей (обучение, повышение квалификации) работников.
Анализ (уровень 2): анализ кадровых процессов; подготовка по запросам аналитических и статистических отчетов; рекрутинг персонала на вакантные должности.
Планирование структуры организаций, штатных расписаний и кадровых политик (уровень 3): создание и ведение корпоративной структуры предприятия или холдинга любой сложности; поддержка множественных иерархических структур, объединяющих персонал: организационных, функциональных, проектных, бюджетных; ведение и планирование штатного расписания (ШР); т.п.
Поддержка множественных иерархических структур (уровень 4): добавление новых типов структур; редактирование существующих типов; создание шаблонов структур; хранение истории изменений;
Таблица 6.1. Структура ТЗ |
|
№ |
Раздел |
1 |
Общие положения |
2 |
Назначение и цели создания (развития) системы |
3 |
Характеристика объекта автоматизации |
4 |
Требования к системе |
5 |
Состав и содержание работ по созданию системы |
6 |
Порядок контроля и приемки системы |
7 |
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие |
8 |
Требования к документированию |
9 |
Источники разработки |
