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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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, в котором приведены перечень, определения и иерархические структуры показателей качества, метрик и измерительных элементов на разных этапах жизненного цикла ПС. Кроме того, в этом стандарте имеется таблица с классификатором программных средств по их назначению, которая служит для определения важности тех или иных характеристик качества для конкретного ПС.