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

Федеральное агентство  по образованию РФ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

Отчёт по контрольно-курсовой работе

по курсу  «Технология разработки программного обеспечения»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2010

 

Содержание

 

 

Введение

Как известно среднегодовой рост рынка программных средств за последние 30 лет составляет примерно 30%, при этом не является секретом что производительность труда программистов растет не такими темпами, поэтому в странах с развитой программной инфраструктурой (США, Германия, Япония) ощущается острая нехватка программистов. Эту проблему зачастую решают количеством, а не качеством, например, за счет эмигрантов или аутсорсинга (передачи прав на работы в другие страны, например, в Индию, Россию).

Помимо этого растет  объем программных средств, ужесточаются требования к безопасности и надежности. Критическим становится и время выполнения проекта – перед всеми предприятиями встают дилеммы время/качество, объем работ/цена итогового программного средства и т.п. В сложившейся обстановке производители, правильно оценив свои возможности, сократили время первых этапов проектирования при этом даже несколько увеличив этапы тестирования и внедрения. Это была необходимая ставка на дисциплину «технология разработки программных средств», которая позволяла предсказать параметры программного средства, правильно составить техническое задание, потребность в средствах и многое другое. Главное, она позволяла не совершить ошибку на первых этапах проектирования, которая, будучи обнаруженной на последующих этапах, принесет серьезные потери во времени и увеличит затраты. Это был шаг в сторону увеличения качества процесса разработки, качества как альтернативы количества средств, персонала, ресурсов, и самого дорогого – времени.

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

Итогом работы будет полностью обоснованное и технологически адекватное техническое задание на разработку указанного программного средства.

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

 

 

 

1. ОПИСАТЕЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ ПС

В ходе работы необходимо проанализировать систему «Ателье по ремонту сложной бытовой техники». Итогом системного анализа будет текст технического задания на проект программного продукта, который улучшит характеристики данной системы. Под программным продуктом в данном случае будем понимать   совокупность баз данных, СУБД,  приложений и документации, их характеризующей, находящихся в непосредственной или косвенной взаимосвязи и предназначенные для поставки, передачи или продажи пользователям систем типа «Ателье по ремонту сложной бытовой техники».

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

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

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

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

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

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

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

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

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

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

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

 

2. ВЫБОР МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗВИТИЯ ПРОЕКТИРУЕМОГО ПРОГРАММНОГО СРЕДСТВА

Наиболее подробно возможная  иерархическая структура процессов, действий и задач, решаемых в ходе проектирования ПС любого назначения представлена в стандарте ISO 12207. Однако в полном объеме данный стандарт обычно не используется из-за значительной избыточности, объясняемой его универсальностью, поэтому, адаптируя этот стандарт для  системы «Ателье по ремонту…» построим модель жизненного цикла.

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

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

• процесс разработки. Поставщик-разработчик обязуется соблюдать коммерческую тайну предприятия-заказчика при проведении системного анализа и моделирования и в положенный срок поставлять пробную(ые) версию(и) программ и оконечное ПС.

Выделим следующие необходимые  работы и задачи:

1. Анализ требований к системе. Следует проанализировать требования заказчика с целью выделения необходимых областей автоматизации.

1.1. Разработчик, должен выполнить анализ области применения разрабатываемой системы с точки зрения определения требований к ней. Технические требования к системе должны быть документально оформлены.

2. Проектирование программной архитектуры.

2.1. Разработчик должен трансформировать требования к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта.  

3. Программирование и тестирование программных средств

3.1. Разработчик должен разработать и документально оформить следующие продукты:    

a) каждый программный модуль и базу данных;     

b) процедуры испытаний  (тестирования) и данные для тестирования  каждого программного модуля  и базы данных.

4. Сборка программных средств

4.1. Разработчик должен собрать программные модули и компоненты и протестировать их как продукты, разработанные в соответствии с планом сборки.    

5. Обеспечение приемки программных средств

5.1. Разработчик должен обеспечить проведение заказчиком оценки готовности к приемке и приемочным испытаниям программного продукта.

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

     

Ответственность за работы и задачи вспомогательного процесса несет разработчик. Выберем следующие вспомогательные процессы жизненного цикла ПС в соответствии с моделью ее проектирования  и стандартом ISO 12207:

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

Выделим следующие необходимые  работы и задачи:

1. Проектирование и разработка

1.1. Каждый конкретный документ должен быть спроектирован в соответствии с используемыми стандартами на документацию.    

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

2. Выпуск

2.1. Документы должны быть изданы и распространены в соответствии с планом.    

 

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

1.1. Должна быть выполнена адаптация процесса обеспечения качества к условиям конкретного проекта.    

1.2. Должны быть выполнены запланированные и традиционные работы и задачи по обеспечению качества.     

2. Обеспечение продукта

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

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

3. Обеспечение процесса

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

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

 

Выберем модель жизненного цикла программного средства. Так  как в соответствии с заданием у системы будет один разработчик, и она будет написана на языке  высокого уровня с применением CASE-средств, то в качестве наиболее подходящей можно выбрать каскадную «водоворотную» модель(рисунок 1).

Рисунок 1 – «Водоворотная» модель разработки

 

Здесь   АТ – анализ  требований,

ПА – проектирование архитектуры,

ПрТ – программирование и тестирование,

Сб – сборка ПС

Пр – приемка ПС.

 

3. РАЗРАБОТКА СПЕЦИФИКАЦИИ КАЧЕСТВА ПРОЕКТИРУЕМОГО ПС

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

В соответствии с ГОСТ 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% документации.

2. Полнота программной документации

• Реализация всех исходных модулей: доля реализации модулей. 0.8 – 80% исходных модулей должно быть реализовано.

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

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

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

1. Полнота тестирования проекта

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

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

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

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

 

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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