Автор работы: Пользователь скрыл имя, 05 Марта 2013 в 17:19, контрольная работа
Предприятие НПО «Криста» занимается проектированием и разработкой программного обеспечения. Отдел разработки информационных систем занимается созданием программного обеспечения по автоматизации учреждений различной сферы деятельности.
Для комплексной автоматизации финансовых органов субъектов федерации и муниципальных образований разработана АС «Бюджет». Использование системы «Бюджет» обеспечивает автоматизацию деятельности всех участников бюджетного процесса от регионального и муниципального финансово-казначейских органов до конечного бюджетополучателя. Организуется полностью контролируемый, автоматизированный, электронный документооборот в бюджетной сфере региона.
1 Описание области деятельности организации или процесса 3
2 Подробная характеристика процесса 6
2.1 Анализ и определение требований 6
2.2 Определение спецификаций 7
2.3 Проектирование 8
2.4 Кодирование 9
2.5 Тестирование 10
2.6 Сопровождение и эксплуатация 10
3 Цели и задачи разработки процессной модели 11
5 Детализированное описание одного процесса, более низкого уровня 13
Выводы 27
Список использованных источников 28
1. Исправление, которое
представляет собой
2. Обновление системы,
предполагающее изменение
Цели и задачи разработки процессной модели показаны на рисунке 1.
Рисунок 1 - Цели и задачи разработки процессной модели
3. Программное обеспечение
4. Правила кодирования
5. Правила тестирования
6. Договор на сопровождение программного продукта
Контроль системы
Человеческие ресурсы, которые используются в процессе разработки программного продукта, представлены следующими отделами:
На выходе системы управления – программный продукт.
Детализированная диаграмма процесса создания программного продукта показана на рисунке 3.
Рисунок 3 - Детализированная диаграмма процесса создания программного продукта
На основе требований к программному продукту определяются анализ и требования к системе в целом.
На основе анализа характеристики предметной области и требований к системе, определенных ранее, разрабатывается структура входных и выходных данных, определяются алгоритмы обработки данных, формулируются условия эксплуатации системы, определяется круг специалистов, которые будут работать с данным программным продуктом, разрабатываются тесты для тестирования программного продукта, определяются типы и количество необходимых документов.
Когда определены требования к системе и спецификации, осуществляется постановка реализации программного продукта, а затем кодирование.
После создания программного продукта, до предложения пользователям его необходимо протестировать, по ранее разработанным тестам. Внедрение программного продукта осуществляется работниками отдела внедрения. Если у пользователей есть какие-то дополнительные требования к программному продукту, вопросы по его работе, или, например, министерством изменены требования к формированию отчетности, пользователи обращаются в отдел сопровождения. Отдел сопровождения, в свою очередь ставит задачу для реализации отделу программистов. Изменения тестируются и при отсутствии ошибок вновь рассылаются пользователям.
Приложение 1
Для построения контрольных карт измерим количество ошибок, выявленных в программном модуле при тестировании.
Данные для построения контрольных карт даны в таблице 1.
Проведём отбор значений для построения контрольных границ (таблица 1). Рассчитаем средние значения и размахи для каждой из выборок по формулам:
(1)
(2)
Таблица 1
Рисунок 4
Рисунок 5
Определяем контрольные
Проводим сплошные горизонтальные линии для среднего размаха и среднего процесса. Контрольные границы проводим штриховыми горизонтальными линиями. Обозначим наименование линий. На период начального обследования они рассматриваются как пробные контрольные границы.
Рисунок 6
На рисунке 6 размах стабилен, среднее стабильно.
Рисунок 7
На рисунке 7 размах стабилен, среднее стабильно.
Проведем анализ контрольных карт.
Цель анализа контрольных карт – распознавание указаний на то, что изменчивость или среднее значение не остаются на постоянном уровне, что одно из них или оба вышли из управляемого состояния и что необходимо соответствующее действие.
Можно сделать вывод, что среднее управляемо, а размах стабилен, так как точки данных среднего внутри границ управляемости, а точки данных размаха вне границах контролируемого процесса.
При первоначальном обследовании
процесса или переоценке его воспроизводимости контрольные границы
должны пересчитываться, чтобы исключить
влияние периодов статистической неуправляемости,
для которых причины были четко идентифицированы
и устранены или применены в процессе.
Для этого необходимо исключить все выборки,
на которые повлияли такие причины, и пересчитать
и нанести на карты новые значения среднего
размаха и контрольных границ. Если не
все точки размахов указывают на управляемость
в новых границах, то следует повторить
идентификацию-коррекцию-
Наличие необычного хода точек или особых структур, даже если все размахи находятся в контрольных границах, могут быть свидетельствами неуправляемости или изменения разброса процесса в течение данного интервала времени или тренда. Это может быть первое предостережение о неблагоприятных условиях, которые должны быть скорректированы. Напротив, некоторые варианты поведения или тренды могут быть благоприятными и должны быть изучены для возможного постоянного усовершенствования процесса. Сравнение поведения точек между картами размахов и средних может дать дополнительную информацию.
На рисунках 8 и 9 рассмотрим контрольные карты с учетом разбивки по зонам с целью, чтобы выделить закономерности, характеризующие его статистическую управляемость.
Рисунок 8 – Контрольная карта для размаха
Рисунок 9 - Контрольная карта для среднего R
На карте размахов есть резкие скачки через одну и две зоны. Причиной такого хода точек является неподготовленность к выполнению процесса. Прежде всего, это относится к персоналу, так как он выполняет процесс.
На карте средних значений R так же наблюдаются скачки через одну или две зоны, это говорит о необходимости повышении качества работы.
Чтобы оценить и повысить способность процесса повысить качество производимой продукции, важно уяснить, что воспроизводимость отражает изменчивость от обычных причин, и для ее улучшения почти всегда необходимы менеджерские действия над системой.
Оценка воспроизводимости процесса начинается после того, как все проблемы управляемости по картам средних и размахов решены, и текущие контрольные карты показывают, что процесс статистически управляем на 20 или большем числе выборок. В таблице 2 приведены различные индексы для оценки воспроизводимости процесса.
Таблица 2
Обозна- чение индекса |
Определение |
Типовое выражение |
Расчет |
Индекс вопроизводимости, определяемый как допуск, деленный на воспроизводимость без учета его центровки. |
|||
|
Верхний индекс воспроизводимости, определяемый как отклонение среднего уровня процесса от верхнего предела поля допуска, деленное на действительный полуразброс процесса. |
||
|
Нижний индекс воспроизводимости, определяемый как отклонение среднего уровня процесса от нижнего предела поля допуска, деленного на действительный полуразброс процесса. |
||
|
Индекс вопроизводимости, который учитывает центровку процесса и определяется как минимальное из и . |
|
|
|
Процент выхода за верхнюю границу допуска. |
|
=1,72 |
Процент, выхода за нижнюю границу допуска |
|
=0,59 | |
Общий процент несоответствий выходов процесса |
|
| |
|
Число несоответствий на миллион операций (изделий) |
|
|
Для улучшения воспроизводимости процесса необходимо обратить внимание на действие обычных причин, на глубинные факторы, отвечающие за изменчивость процесса. Как правило, такие причины непригодности процессов требуют менеджерского вмешательства, выделения дополнительных ресурсов и обеспечения обшей координации работ по улучшению процессов.
Разработка мероприятий по улучшению управляемости и воспроизводимости процесса начинается с определения причин выявленных закономерностей и недостаточно высоких значений индексов воспроизводимости. Для наиболее удобно использовать причинно-следственную диаграмм Исикавы (рисунок 10). При ее построении необходимо проанализировать все элементы процесса, указанные в его документированной процедуре.
Рисунок 10 - Причинно-следственная диаграмма Исикавы
В заключении важно отметить, что структурирование процесса разработки программного продукта позволяет определять задачи каждого этапа создания программного продукта, и сравнивать достигнутые результаты с требованиями к этапу, то есть проверять соответствие реализованных требований с поставленными. Это является основой контроля качества разрабатываемого программного продукта.
Планирование функций работника на рабочем месте позволяет последовательно определить его действия на каждом этапе создания программного продукта, определить его задачи, и степень выполнения им своих обязанностей. Таким образом, контролируется качество программного продукта.
Цель анализа контрольных карт – распознавание указаний на то, что изменчивость или среднее значение не остаются на постоянном уровне, что одно из них или оба вышли из управляемого состояния и что необходимо соответствующее действие. Карты размахов и средних значений анализируются раздельно, но сравнение хода их кривых может иногда дать дополнительную информацию об особых причинах, воздействующих на процесс. Точки данных сравнивают с контрольными границами для нахождения точек вне границ управляемости или необычного хода или тренда. В нашем случаи отсутствие точек за пределами любой из контрольных границ – первое свидетельство управляемого, стабильного состояния процесса.