3) Проектирование с использованием метода «сущность - связь». Метод «сущность - связь» является комбинацией двух предыдущих и обладает достоинствами обоих.

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

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

Сущность - это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, «Сотрудники» или «Автомобиль»), так и абстрактные (например, «Экзамен» или «Диагноз»).

Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр конкретными значениями свойств.

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

Для каждой сущности выбираются свойства (атрибуты).

Различают:

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

2) Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.

3) Однозначные и многозначные атрибуты (могут иметь соответственно одно или несколько значений для каждого экземпляра сущности).

4) Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

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

? тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;

? характеристики производительности системы;

? запас функциональных возможностей для дальнейшего развития ИС;

? степень оснащенности системы инструментарием для персонала администрирования данными;

? удобство и надежность СУБД в эксплуатации;

? стоимость СУБД и дополнительного программного обеспечения.

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

1) путем декомпозиции (разбиения) когда исходное множество отношений входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает) являющихся проекциями исходных отношений;

2) путем синтеза или компоновки из заданных исходных элементарных зависимостей между объектами предметной области.

Физическое проектирование БД - данный этап заключается в связывании логической структуры БД и физической среды хранения для наиболее эффективного размещения данных. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам «физической» БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.

Одной их важнейших составляющих проекта базы данных является разработка средств защиты БД. Защита данных имеет два аспекта: защита от сбоев и защита от несанкционированного доступа. Для защиты от сбоев разрабатывается стратегия резервного копирования. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только в соответствии с его правами доступа [11].

3.1.2 Описание предметной области

В качестве предметной области выбрана строительная фирма ООО "Строй-Сервис" в г.Усть-Куте.

Данная БД предназначена для:

- учета контрагентов организации;

- учета товаров и услуг, потребляемых в ходе выполнения подрядных работ;

- учета заключенных договоров, работ по договору;

- составления графика оплаты по работам договора;

- составления графика потребления товаров и услуг по работам договора;

- заключения дополнительных соглашений к договору;

- составления графика оплаты и графика потребления товаров и услуг по дополнительному соглашению;

- ведения журнала платежей;

Формирования следующих выходных документов и отчетности:

- договор подряда;

- график работ и оплаты по договору;

- дополнительное соглашение;

- график работ и оплаты по дополнительному соглашению;

- полный список потребляемых товаров и услуг по договору;

- список платежей по договору;

- журнал платежей за заданный период времени;

- список заключенных договоров за заданный период времени;

- список контрагентов;

- справочник товаров и услуг.

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

3.1.3 Инфологическое проектирование

Инфологическая модель данных.

Посредством анализа предметной области выделены следующие сущности и их атрибуты.

Сущности:

1) «Договоры» (№договора; КонтрагентID; ДатаНач; ДатаКон; СтатусID; Сумма);

2) «ДопСоглашения» (№Соглашения; ДоговорID; РаботаID; Наименование; ДатаНач; ДатаКон; Выполнено; Описание);

3) «ЖурналПлатежей» (Счет№; СчетДата; Сумма; Назначение);

4) «Контрагенты» (ID; Наименование; Адрес; Телефоны; Реквизиты; ИНН; КПП; ВлицеКого);

5) «Оплата» (ID; РаботаID; ДатаАванс; ДатаОстаток; СуммаАванс; СуммаОстаток; ОплаченАванс; ОплаченОстаток);

6) «ОплатаДопСоглашение» (ID; ДопСоглашениеID; ДатаАванс; ДатаОстаток; СуммаАванс; СуммаОстаток; ОплаченАванс; ОплаченОстаток);

7) «Потребление» (РаботаID; ТоварУслугаID; Количество; Цена);

8) «ПотреблениеДопСоглашене» (ДопСоглашениеID; ТоварУслугаID; Количество; Цена);

9) «Работы» (Шифр; ДоговорID; Наименование; ДатаНач; ДатаКон; Выполнено; Описание);

10) «СтатусыДоговора» (ID; Статус);

11) «ТоварыУслуги» (Шифр; Наименование; Услуга; ЕдИзм; Цена).

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, то есть любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, «Прочие».

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

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

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Между сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности

Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).

Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером и Мак-Леоном, функциональную модель данных Шипмана, модель «сущность-связь», и ряд других моделей. В настоящий момент именно модель «сущность-связь» стала фактическим стандартом при инфологическом моделировании баз данных. Большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели.

Для реализации базы данных выбрана МS Аccеss. Для доступа к БД используется АDО (ActiveX Data Object) Delphi.

3.1.4 Даталогическое проектирование

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

В результате выполнения этого этапа должны быть получены следующие результаты:

- описание концептуальной схемы БД в терминах выбранной СУБД;

- описание внешних моделей в терминах выбранной СУБД;

- описание декларативных правил поддержки целостности базы данных;

- разработка процедур поддержки семантической целостности базы данных.

Проектирование схемы БД может быть выполнено двумя путями:

- путём декомпозиции, когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

- путём синтеза, то есть путём компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

Текущие таблицы полностью соответствуют этим требованиям.

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



Рисунок 3.2 - Даталогическая модель

3.2 Общее описание разработанного приложения

3.2.1 Логическая структура приложения

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 3.3 - Структура приложения

3.2.2 Интерфейс и основные функции приложения

Работа с программой начинается с вывода на экран главного меню, содержавшего основные компоненты программы (рис. 3.4).



Рисунок 3.4 - Окно главного меню

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

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

Рисунок 3.5 - Контрагенты

Пункт меню «Товары и услуги» содержит сведения о предоставляемых услугах строительной фирмой ООО «Строй-Сервис» и сопутствующем товаре (рис.3.6).

Рисунок 3.6 - Товары и услуги

При нажатии на кнопку «Договоры» появляется следующее окно (рис. 3.7).



Рисунок 3.7 - Окно просмотра договоров

В окне просмотра договоров, пользователь может просматривать сведения о договорах, их статусе, дате заключения и выполнения (рис.3.8), а также, при нажатии на кнопку «Открыть», можно получить информацию о предмете договора, имеются ли дополнительные соглашения, сведения о потреблении товаров и услуг, сведения об оплате (рис.3.9).

Рисунок 3.8 - Просмотр договора по номеру



Рисунок 3.9 - Дополнительное соглашение

Кнопка «Журнал платежей», содержит информацию о платежах, поступивших на счет предприятия за оказание услуг (рис.3.10).

Рисунок 3.10 - Окно Журнал платежей

На рисунке 3.11 показаны дополнительные формы для просмотра потребления товаров и услуг по номеру договора и дополнительным соглашениям и суммы проплат.

Рисунок 3.11 - Дополнительные формы

Интерфейс программы реализован в Delphi, выходные документы генерируются в MS Word и MS Excel (рис.3.11).



Рисунок 3.11 - Печать выходных документов

Заключение

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

В данной системе обеспечены следующие требования:

1) максимальная автоматизация рутинных процессов;

2) своевременное удовлетворение информационной потребности;

3) минимальное время ответа на запросы пользователя;

4) простота приемов работы с АИС и легкость общения, надежность и простота обслуживания.

Реализованы возможности:

- учета контрагентов организации;

- учета товаров и услуг, потребляемых в ходе выполнения подрядных работ;

- учета заключенных договоров, работ по договору;

- составления графика оплаты по работам договора;

- составления графика потребления товаров и услуг по работам договора;

- заключения дополнительных соглашений к договору;

- составления графика оплаты и графика потребления товаров и услуг по дополнительному соглашению;

- ведения журнала платежей;

Формирования следующих выходных документов и отчетности:

- договор подряда;

- график работ и оплаты по договору;

- дополнительное соглашение;

- график работ и оплаты по дополнительному соглашению;

- полный список потребляемых товаров и услуг по договору;

- список платежей по договору;

- журнал платежей за заданный период времени;

- список заключенных договоров за заданный период времени;

- список контрагентов;

- справочник товаров и услуг.

Список использованных источников

1 Автоматизированные информационные технологии в экономике: учебник/ Под ред.проф.Г.А.Титоренко - М.:ЮНИТИ, 2007.-399с.

2 Теория экономических информационных систем: Учебник. А.И. Мишенин - М.: Финансы и статистика, 2006. - 240с.

3 Елисеев В. Ладыженский Г. Введение в Интранет. Системы Управления Базами Данных - М.- 2006.

4 Компьютерные системы и сети: Учебное пособие/ Под ред. В.П.Косарева и Л.В. Еремина. - М.: Финансы и статистика, 2005. - 464с.

5 Информационные системы: Учебник для вузов / В.Н.Петров.- СПб.: Питер, 2007. - 687с.

6 Томсон Л. Веллинг Л. Разработка web-приложений на PHP и MySQL- СПб.: ООО “ДиаСофтЮП”,2008. - 672с.

7 Бекаревич Ю.Б. Microsoft Access 2003. - СПб.: БХВ-Петербург, 2006. - 202с.

8 Самохина М.И., Работа с СУБД Microsoft Access: учебное пособие/ М.И. Самохина, Н.А.Барковская - Братск: ГОУ ВПО «Братский государственный университет», 2008. - 85с.

9 Проектирование информационных систем: Учебное пособие./ Н.Н.Заботина. - Братск: ГОУВПО «БрГТУ», - 2004. - Ч 2: 119с.

10 Дейт К.Дж.- Введение в системы баз данных.:Пер. с англ. - 6-еизд. - К.:Диалектика, 2007. - 784с.

11 Н. Н. Заботина Проектирование информационных систем. Часть 1. Методология функционального моделирования: Учебное пособие. - Братск: ГОУВПО «БрГУ», 2005. - 146с.

12 Н. Н. Заботина Проектирование информационных систем. Часть 2. Концептуальное моделирование базы данных: Учебное пособие. - Братск: ГОУВПО «БрГУ», 2004. - 119с.

13 Ким С.Г., Шелепова М.Ю. Delphi. Система визуального программирования: Учебное пособие.-Братск: ГОУ ВПО «БрГУ», 2005. - 129 с.

14 Хоменко А.Д., Гофман В.Э. Работа с базами данных в Delphi. - 3-е изд., перераб. и доп. - СПб.:БХВ-Петербург, 2005. - 640с.

15 Мотузко Ф.Я. Охрана труда. - М.: Высшая школа, 2006. - 336с.

16 Безопасность жизнедеятельности. /Под ред. Н.А. Белова - М.: Знание, 2000. - 364с.

17 Самгин Э.Б. Освещение рабочих мест. - М.: МИРЭА, 2002. - 186с.

18 Справочная книга для проектирования электрического освещения. / Под ред. Г.Б. Кнорринга. - Л.: Энергия, 2001.- 457с.

19 Борьба с шумом на производстве: Справочник / Е.Я. Юдин, Л.А. Борисов; Под общ. ред. Е.Я. Юдина - М.: Машиностроение, 2005. - 400с.

20 Зинченко В.П. Основы эргономики. - М.: МГУ, 2002. - 179с.

Приложение А

ДОГОВОР ПОДРЯДА

(С ИСПОЛЬЗОВАНИЕМ МАТЕРИАЛОВ ПОДРЯДЧИКА)

№23/12

г. Усть-Кут 12 февраля 2012 г.

ООО "Строй-Сервис", именуемый в дальнейшем "Заказчик", в лице Васильева Ивана Петровича, действующего на основании Устава, с одной стороны, и ООО «Сервис-Строй», именуемое в дальнейшем "Подрядчик", в лице Глебова Андрея Васильевича, действующего на основании Устава, с другой стороны, заключили настоящий договор о нижеследующем:

1. Предмет договора

1.1. Заказчик поручает, а Подрядчик обязуется выполнить работы, указанные в Приложении N1 к настоящему Договору.

1.2. Объем, вид и срок исполнения работ устанавливается сторонами в факсимильных сообщениях, телефонограммах и в дополнительных соглашениях в период действия договора.

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

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

2. Стоимость работ и порядок расчетов

2.1. Стоимость работ устанавливается в Приложении №1, являющемся неотъемлемой частью настоящего Договора.

3. Порядок выполнения и сдачи-приемки работ

3.1. Заказчик имеет право присутствовать при выполнении работ, а также контролировать их выполнение.

3.2. Приемка выполненных работ осуществляется путем подписания акта сдачи-приемки работ и передачи сопроводительных документов на выполненные работы Заказчику.

3.3. Заказчик в течение 10 дней со дня получения акта сдачи-приемки работ и отчетных документов обязан направить Подрядчику подписанный акт сдачи-приемки выполненных или мотивированный отказ от приемки работ.

3.4. В случае прекращения работы по инициативе Заказчика последний в письменной форме уведомляет Подрядчика о причине и сроке прекращения действия Договора.

4. Ответственность сторон

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

4.2. За неисполнение или ненадлежащее исполнение обязательств по настоящему Договору стороны несут ответственность в соответствии с действующим законодательством. За нарушение сроков оплаты Подрядчик вправе взыскать с Заказчика неустойку в размере 1% за каждый день просрочки.

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

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

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

5. Порядок разрешения споров

5.1. Все споры и разногласия между сторонами, возникающие в период действия настоящего Договора разрешаются сторонами путем переговоров.

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

5.3. Положения, не урегулированные настоящим Договором, регулируются положениями действующего законодательства РФ.

6. Прочие условия

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

6.2. Условия настоящего Договора имеют одинаковую юридическую силу для Сторон и могут быть изменены по взаимному согласию с обязательным составлением письменного документа, который является неотъемлемой частью настоящего Договора.

6.3. Настоящий Договор составлен в 2-х экземплярах, имеющих одинаковую юридическую силу, по одному экземпляру для каждой из

Сторон.

7. Срок действия договора

начало: 12 февраля 2012 г.

окончание: 12 июня 2012 г.

8. Адреса и платежные реквизиты сторон

Заказчик:

ООО «Сервис-Строй»

г. Усть-Кут, ул. Яблочная, 54

ЗАО «БИНБАНК», р/с 4070281030089938475, к/с 3030181050000746537

ИНН 9847564583

КПП 986475643

Подрядчик:

ООО "Строй-Сервис"

665780, г. Усть-Кут, ул .Каракозова, д.34665780, г. Усть-Кут, ул .Каракозова, д.34

ОАО "Сбербанк". р/с 4070281050056000589, к/c 3010181030000589617ОАО "Сбербанк". р/с 4070281050056000589, к/c 3010181030000589617

ИНН 123454567845123454567845

КПП 345546776345546776

Подписи сторон:

Заказчик

Подрядчик

Приложение Б

Размещено на Allbest.ru