Ателье по ремонту сложной бытовой техники

Автор работы: Пользователь скрыл имя, 30 Мая 2013 в 19:06, курсовая работа

Описание работы

Целью данной работы является изучение технологических аспектов первых этапов проектирования программных средств, в том числе системный анализ поставленной задачи, выбор модели жизненного цикла, выявление и обоснование основных требований спецификации качества и функциональности ПС.

Содержание работы

ВВЕДЕНИЕ 3
1. ОПИСАТЕЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ ПС 5
2. ВЫБОР МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗВИТИЯ ПРОЕКТИРУЕМОГО ПРОГРАММНОГО СРЕДСТВА 8
3. РАЗРАБОТКА СПЕЦИФИКАЦИИ КАЧЕСТВА ПРОЕКТИРУЕМОГО ПС 12
4. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ СПЕЦИФИКАЦИИ ПРОЕКТИРУЕМОГО ПС 15
5. ПРОЕКТ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ «АТЕЛЬЕ ПО РЕМОНТУ…» 18
ЗАКЛЮЧЕНИЕ 25
СПИСОК ЛИТЕРАТУРЫ 26

Файлы: 1 файл

trpo.doc

— 262.50 Кб (Скачать файл)

В соответствии с ГОСТ 28195-89 разрабатываемое  ПС можно отнести к классу 5012 (программные  средства управления базами данных). В  соответствии с этим определим следующие показатели качества для разрабатываемого ПС

1. Показатели надежности:

1.1. Устойчивость функционирования. Разработанное ПС должно быть устойчиво, так как в противном случае на предприятии возможны убытки. Метрики:

      1. Средства восстановления при ошибках на входе. Оценочные элементы:
        • Полнота обработки ошибочных ситуаций: определяется как отношение обработанных ошибочных ситуаций к их общему числу. 0.9 - 90% ситуаций должны быть обработаны.
        • Наличие средств контроля корректности входных данных: определяется как отношение контролируемых входных данных к их общему числу. 0.8 – контроль корректности должен присутствовать для 80% данных.

Итоговая оценка метрики – 0.85.

Оценка  критерия качества – 0.85.

1.2. Работоспособность. Метрики:

      1. Функционирование в заданных режимах
        • Показатель устойчивости к искажающим воздействиям: P(Y)=1-D/K, где D – число экспериментов, в которых искажающие воздействия приводили к отказу, K – число экспериментов, в которых имитировались искажающие воздействия. P(Y)=0.6, 40% всех искажающих воздействий приводят к отказу.
        • Вероятность безотказной работы: P=1-Q/N, где Q - число зарегистрированных отказов, N — число экспериментов. P = 0.8, т.е. 20% всех экспериментов составляют отказы.

Итоговая оценка метрики - =0.7

Оценка  критерия качества – 0.7

Значение фактора качества - =1.6

2. Показатели удобства применения:

2.1. Легкость освоения. Метрики:

      1. Освоение работы ПС
        • Возможность освоения ПС по документации: 1 – ПС возможно освоить по документации, 0 – не возможно. 1 – ПС можно освоить по документации.
        • Возможность освоения ПС на контрольном примере при помощи ЭВМ: 1 – ПС возможно освоить на контрольном примере, 0 – не возможно. 1 – ПС можно освоить на контрольном примере.

Итоговая оценка метрики – 1.

Оценка  критерия качества – 1.

Значение фактора качества - =1

3. Показатели корректности:

3.1. Полнота реализации. Метрики:

      1. Полнота документации разработчика
        • Наличие всех необходимых документов для понимания и использования ПС: объем документации в наличии к общему числу необходимых документов. 0.9 – должно быть предоставлено не меньше 90% документации.
      1. Полнота программной документации
        • Реализация всех исходных модулей: доля реализации модулей. 0.8 – 80% исходных модулей должно быть реализовано.

Итоговая оценка метрики – 0.85.

Оценка критерия качества – 0.85.

3.2. Проверенность. Метрики:

      1. Полнота тестирования проекта
        • Отношение числа модулей, отработавших в процессе тестирования и отладки ( ), к общему числу модулей ( ). 0.9 – 90% модулей должны отработать.

Итоговая оценка метрики – 0.9

Оценка критерия качества – 0.9

Значение фактора качества - =1.85

 

 

    1. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ СПЕЦИФИКАЦИИ ПРОЕКТИРУЕМОГО ПС

С учетом назначения функциональной спецификации, а также с учетом возможности тяжелых ошибок в этом документе, функциональная спецификация должна быть очень точной и непротиворечивой и по возможности приближаться к математическим формулировкам, однако это не означает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать код программы. Это означает лишь то, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых и заказчиком  и разработчиками.

Достаточно часто функциональная спецификация  формализуется на естественном языке, тем не менее, использование математических и других формализованных методов при разработке функциональной спецификации весьма приветствуется.

В целом функциональная спецификация состоит из трех основных частей:

    • Описание внешней информационной среды по отношению к программному средству;
    • Определение функций ПС. Чаще всего такие функции рассматриваются на множестве состояний внешней информационной среды;
    • Описание нежелательных ситуаций, которые могут возникнуть при работе ПС и описание реакции ПС на эти ситуации.

В качестве внешней информационной среды выступает база данных. Ниже на Рисунке 2 представлена ее полная атрибутивная модель

Рисунок 2 – Информационная система ателье

 

Основные функции ПС можно выделить следующие:

    • Регистрация нового клиента. Производится с использованием паспортных данных клиента, которые вводятся в соответствующие текстовые поля. Повторение личного номера клиента не допустимо, следовательно, этот номер должен генерироваться внутри системы.
    • Добавление нового заказа. Новый заказ вводится в базу данных с заполнением необходимых полей таблицы. Номер заказа также как и личный номер клиента должен генерироваться внутри системы.
    • Добавление новой детали на склад. Либо производится добавление новой записи в базе данных, либо при наличии такой детали увеличивается счетчик деталей.
    • Поиск заказа по его параметрам. Результатом является отсортированный список заказов.
    • Предоставление клиенту истории его заказов.

При работе системы возможны следующие  исключительные ситуации:

    • некорректные данные, введенные пользователем. Например, введение строкового значения в поле для ввода даты. В этом случае пользователю должно быть выдано соответствующее сообщение.
    • попытка добавления в базу данных записи о новой детали с названием, которое совпадает с уже существующей записью. Здесь следует проинформировать пользователя и предложить ему добавить информацию в уже существующую запись.

Отработка случая параллельного вхождения  в одну таблицу не принципиальна, т.к. пользователь получает не прямой доступ, а ответ запроса в виде временной таблицы. Попытка сохранения разных записей в одну таблицу в одну и ту  же ячейку разными пользователями должна обрабатываться по принципу FIFO, исключая случаи, когда над таблицей работает администратор или другой привилегированный пользователь, тогда право сохранения получает более привилегированный класс.

В случае обновления какой-либо базы доступ к ней прекращается на время  обновления, пользователей просят закрыть  все рабочие копии данной таблицы.

 

    1. ПРОЕКТ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ «АТЕЛЬЕ ПО РЕМОНТУ…»

ВСЕ НИЖЕПРИВЕДЕННЫЕ  МАТЕРИАЛЫ БУДУТ ИЗЛОЖЕНЫ НА ОСНОВЕ ГОСТ 34.602-89  (ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ).

П.1. ОБЩИЕ СВЕДЕНИЯ

Систему программного обеспечения  ателье по  ремонту бытовой техники  далее будем называть как «автоматизированная система ателье по ремонту», условно обозначим ее как АСУ АпУ 1.0.

Наименование заказчика  – ООО «Ателье по ремонту сложной бытовой техники».

Система создается на основе следующих документов:

  1. Задание на лабораторные работы по курсу «Технология разработки программного обеспечения».
  2. Задание на контрольно-курсовую работу по курсу «Технология разработки программного обеспечения»
  3. Текущее ТЗ

 

П.2. Назначение и цели создания (развития) системы

Назначением системы  является автоматизация процессов  управления и документооборота заказчика, возможность получения удаленных  запросов по требованию пользователя, как в локальной сети, так и удаленного.

Объектами автоматизации  является рабочее место приемщика-операциониста, занимающегося принятием и отпуском техники; рабочее место начальника склада и мастера-ремонтника.

Основной целью создания ПС является облегчение поиска дефектов, необходимых деталей и т.п., а так же ускорение операций с бумажными носителями, что, в конечном счете, скажется на скорости и качестве труда, а как следствие на увеличении оборачиваемости оборотных средств предприятия.

 

П.3. Характеристики объекта автоматизации

 

Под объектом автоматизации  будем понимать изученную ранее  систему «Ателье по ремонту сложной  бытовой техники».

В соответствии  с заданием  в  системе «Ателье по ремонту сложной  бытовой техники» возможные следующие  основные бизнес-процессы:

  • прием и регистрация заказа;
  • выбор и назначение мастера, осуществляющего ремонт, в зависимости от типа аппаратуры и загруженности мастеров;
  • определение вида неисправности;
  • оценка стоимости заказа в зависимости от типа необходимых комплектующих деталей и сложности ремонта;
  • поиск на складе, а если необходимо, закупка материалов и комплектующих деталей;
  • выполнение заказа;
  • оплата и выдача заказа, прием претензий.

В процессе приема заказа производится его прием от клиента и регистрация  на бумажных носителях. Клиенту выдается корешок с числом принятия заказа, кодовым номером, наименованием  заказа и примерной датой исправления  дефекта.

 После этого производится поиск наиболее подходящего мастера, разбирающегося в данной аппаратуре и имеющего необходимую квалификацию для ремонта подобной неисправности. Одним из основных параметров поиска является загруженность мастеров.

Выбранный мастер производит поиск неисправности, после чего на складе запрашиваются необходимые мастеру детали. В случае отсутствия деталей на складе они закупаются у постоянных поставщиков ателье.

После определения неисправности, оценки стоимости комплектующих,  расходных материалов и работы мастера определяется себестоимость работ. С учетом необходимой амортизации оборудования, налогов и сборов, необходимой прибыли и пр. определяется итоговая стоимость услуги, которая после проведения работ сообщается заказчику. Оплата производится по наличному расчету через кассу предприятия.

В процессе непосредственно ремонта  мастер, пользуясь необходимыми принципиальными  и электрическими схемами, картами  поиска неисправностей и т.п., а также  необходимыми приборами и расходными частями производит ремонт или восстановление изделия. Изделие может не подлежать ремонту, т.е. ремонт невозможен технически или его стоимость будет сопоставима с ценой нового изделия.

Заказчик при получении заказа имеет право на демонстрацию ему  работы прибора, объяснение устраненных неисправностей, возможных причин их возникновения. Помимо этого заказчик имеет право в течение трехмесячного срока (гарантия на качество ремонта) вернуть на доработку прибор, если возникли неисправности или произошел отказ прибора, либо потребовать возврат денег.

 

П.4. Требования к системе

Создаваемая система в обязательном порядке должна реализовывать следующие  функции:

    • Регистрация нового клиента.
    • Добавление нового заказа.
    • Добавление новой детали на склад.
    • Поиск заказа по его параметрам.
    • Предоставление клиенту истории его заказов.

Разрабатываемое ПС должно удовлетворять следующим показателям качества:

1. Показатели надежности:

1.1. Устойчивость функционирования.

      1. Средства восстановления при ошибках на входе. Оценочные элементы:
        • Полнота обработки ошибочных ситуаций: не ниже 0.9.
        • Наличие средств контроля корректности входных данных: не ниже 0.8.

Информация о работе Ателье по ремонту сложной бытовой техники