Управление качеством в процессе разработки программного обеспечения предприятия - Дипломная работа

4.2 Анализ ПЭБ при эксплуатации персональных компьютеров 4.2.1 Перечень факторов обитаемостиООО «РУСОФТ» - компания, работающая в сфере информационных технологий, была основана и внесена в реестр Торгово-промышленной палаты России в 2000 году. В начале своего существования компания занималась только созданием прикладного программного обеспечения. Со временем компания Русофт стала принимать участие в проектах разработки программного обеспечения, ориентированного на Интернет и столкнулась с необходимостью интеграции интернет-технологий с бизнес процессами заказчика. Было принято решение о расширении поля деятельности компании и, в результате, компания обзавелась отделом веб-дизайна и интернет-разработок. В июне 2001 года компания Русофт заключило партнерское соглашение с американской компанией Internet Pictures Corporation, получив эксклюзивное право на распространение технологии IPIX в России.Как говорилось выше, компания Русофт специализируется на разработке заказного программного обеспечения.Среди прочих, потребителями продукции и услуг компании являются средние и крупные промышленные компании, государственные структуры, СМИ, туристические организации, страховые компании, автосалоны и др., осознавшие необходимость в предоставлении информации о себе, своей продукции и услугах в Интернет.Поставщиками компании Русофт являются предприятия, предоставляющие телематические услуги: доступ к информационным ресурсам городской сети, доступ в Интернет.Проектная деятельность компании строиться на словах и устных договоренностях, не закреплена в документированных процедурах, а, следовательно, не воспроизводима и зависит от носителей знаний.Пояснительная записка к дипломному проекту состоит из четырех глав: 1. Описание предприятия. В третьей главе представлен теоретический материал о творческой форме функционально-стоимостного анализа, дана классификация функций объекта, описана методика анализа структурно-функциональной диаграммы и метод расчета затрат на реализацию функций объекта.На предстоящем этапе формирования документа будет принят следующий глоссарий терминов.Областью применения процедуры проектного управление является проектная деятельность вплоть до реализации плана проекта. Входами процедуры являются: · Потребности, задачи, требования заказчикаПроцедура проектного управления состоит из следующих процедур: · Анализ требований · Проверка функциональной архитектуры Структурная схема процедуры проектного управления представлена на рис.Задачами процедуры являются: · определение того, что система должна делать и насколько хорошо;Процедура состоит из следующих операций: · Определение ожиданий заказчика · Определение проектных и корпоративных ограничений · Определение функциональных сценариев и сценариев использования · Определение измерителей эффективности и пригодности · Определение окружения функционированияОжидания заказчика можно выявить из документов с перечнем требований к функционированию, документов с описанием миссии и задач разрабатываемой системы, из прямых диалогов с заказчиком или из требований системы более высокого уровня, в которую разрабатываемая система входит как составная часть. Целью этой операции является определение того, чего действительно хочет заказчик от разрабатываемой системы в отражении того, какие функции она должна выполнять и насколько качественно. Описание требований также может включать в себя описание естественного или смоделированного окружения, в котором должны функционировать продукты системы, а также различные ограничения, например, размер и порядок финансирования проекта, стоимость, ценовая политика и цели, которые она преследует, ограничения по срокам проекта и его расписанию, по используемым технологиям, ограничения к физическим характеристикам, перечень неразрабатываемых и повторно используемых частей. Сайт должен показывать, что компания является лидером в своей области (дизайн). Система должна защищать информацию от несанкционированного изменения, должна позволять управлять несколькими пользователями с различными уровнями доступа (доступ к разным модулям системы администрирования, к редактированию разных разделов сайта)Проектные ограничения могут включать в себя: · Одобренные спецификации и основные версии документов, разработанные во время предшествующих применений процесса проектного управления · Измененный технический план и план менеджмента проекта · Состав и структура команды проекта Корпоративные ограничения могут включать в себя: · Управленческие решения из предшествующих технических оценок Сайт и система администрирования должны в одинаковой степени функционировать на серверной площадке с операционными системами Windows, Linux, FREEBSD, под управлением веб-сервера Apache 1.3.xx с модулем PHP 4.3.9 и выше (с установленным модулем Zend Optimizer) и сервера баз данных MYSQL 4.

Содержание

Введение

Глава 1. Описание предприятия

1.1 Продукция

1.2 Потребители

1.3 Поставщики

1.4 Проблемы и перспективы развития

1.5 Краткое описание структуры дипломного проекта

Глава 2. Проект процедуры проектного управления

2.1 Описание процедуры проектного управления

2.1.1 Состав процедуры

2.2 Анализ требований

2.2.1 Состав процедуры

2.2.2 Определение ожиданий заказчика

2.2.3 Определение проектных и корпоративных ограничений

2.2.4 Определение внешних ограничений

2.2.5 Определение сценариев функционирования и применения

2.2.6 Определение измерителей эффективности и годности

2.2.7 Определение границ системы

2.2.8 Определение интерфейсов

2.2.9 Определение внешних условий функционирования

2.2.10 Определение концепции процессов жизненного цикла

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

2.2.12 Определение требований к рабочим характеристикам

2.2.13 Определение режимов работы

2.2.14 Определение измерителей технической производительности

2.2.15 Определение физических характеристик

2.2.16 Определение человеческого фактора

2.2.17 Установка основной версии требований

2.3 Подтверждение требований

2.3.1 Состав процедуры

2.3.2 Сравнение с ожиданиями заказчика

2.3.3 Сравнение с проектными и корпоративными ограничениями

2.3.4 Сравнение с внешними ограничениями

2.3.5 Определение расхождений и противоречий

2.3.6 Подтверждение основной версии требований

2.4 Функциональный анализ

2.4.1 Состав процедуры

2.4.2 Анализ функционального контекста

2.4.3 Функциональная декомпозиция

2.4.4 Установка функциональной архитектуры

2.5 Проверка функциональной архитектуры

2.5.1 Состав процедуры

2.5.2 Определение процедур проверки

2.5.3 Проведение проверочной оценки

2.5.4 Выявление расхождений и конфликтов

2.5.5 Установка проверенной функциональной архитектуры

2.6 Дизайн синтез

2.6.1 Состав процедуры

2.6.2 Группировка и выделение функций

2.6.3 Выявление альтернативных конструкционных решений

2.6.4 Оценка надежности, опасности вредного воздействия окружающей среды

2.6.5 Оценка факторов качества жизненного цикла

2.6.6 Оценка требований к технологии

2.6.7 Выделение физических и рабочих характеристик

2.6.8 Определение физических интерфейсов

2.6.9 Оценка возможности использования стандартных элементов

2.6.10 Оценка наличия стандартных элементов

2.6.11 Оценка альтернативы «произвести или купить»

2.6.12 Разработка моделей, изготовление прототипов

2.6.13 Оценка видов отказов, их последствий и критичности

2.6.14 Оценка необходимости тестирования

2.6.15 Оценка возможности конструкции к доработке

2.6.16 Завершение конструирования

2.6.17 Инициирование эволюционной разработки

2.6.18 Изготовление чертежей и схем

2.6.19 Установка физической архитектуры

2.7 Проверка физической архитектуры

2.7.1 Состав процедуры

2.7.2 Выбор принципа (метода) проверки

2.7.3 Проведение проверочной оценки

2.7.4 Выявление расхождений и конфликтов

2.7.5 Установка проверенной физической архитектуры

2.7.6 Проверка физической архитектуры процесса жизненного цикла

2.7.7 Составление проверенной системной архитектуры

2.7.8 Установка основных версий спецификации и конфигурации

2.7.9 Разработка дерева системы

2.8 Системный анализ

2.8.1 Состав процедуры

2.8.2 Оценка конфликтов требований

2.8.3 Оценка альтернативных вариантов функциональности

2.8.4 Оценка альтернативных решений

2.8.5 Выявление факторов риска

2.8.6 Определение области исследования

2.8.7 Проведение исследования

2.8.8 Выбор параметров управления риском

2.8.9 Выбор альтернативных рекомендаций

2.8.10 Документирование компромиссного решения и воздействия

2.8.11 Оценка эффективности решения

2.9 Контроль

2.9.1 Состав процедуры

2.9.2 Техническое управление

2.9.3 Прослеживание данных системного анализа и проверки/тестирования

Глава 3. Творческая форма функционально-стоимостного анализа в проектах разработки программного обеспечения

3.1 Функционально-стоимостной анализ

3.2 Этапы творческой формы ФСА

3.3 Функции объекта и их классификация

3.3.1 Классификация функций

3.4 Анализ функционально-структурных (совмещенных) моделей

3.4.1 Расчет затрат на реализацию функций в ФСА

Глава 4. Организация обстановки для умственного труда