Технология разработки проектов строительства

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» выделяют следующие основные стадии создания и этапы разработки автоматизированной системы (АС):

1. Формирование требований к АС.
2. Разработка концепции АС. . . .
3. Рабочая документация.
4. Ввод в действие.
5. Сопровождение АС.

Как правило, этапы стадий формирования требований к автоматизированной системе объединяют с этапами разработки технического задания, а этапы разработки концепции — с этапами эскизного проектирования. Также к приведенным стадиям создания АС добавляют стадию подготовки к началу проекта.

Ниже представлены стадии создания информационно-аналитической системы – корпоративного хранилища данных. Также дана оценка длительности каждого из этапов внедрения системы.

Стадия I. Организация проекта

Этапы работРезультатДней

Заключение контракта	Контракт на разработку системы заключен	10

Стадия II. Формирование требований и разработка технического задания

• требуемых отчетах, показателя, измерениях
• возможных системах-источниках данных
• системном ландшафте
• сетевом окружении

• альбом показателей
• альбом измерений и иерархий
• альбом отчетности
• определены источники данных для каждого показателя

Стадия III. Эскизный проект

данных.
• Определен состав сущностей области постоянного хранения (System of Record, Summary Area, Data Marts).
• Окончательно сформирован состав реализуемых показателей, измерений и отчетов.

• Предварительные регламенты взаимодействия согласованы с разработчиками и администраторами систем-источников данных.
• Определен состав сущностей области временного хранения (Staging Area) и области обмена данными (Data Exchange Interface).

Стадия IV. Технический проект

Этапы работРезультатДней

Определение функциональной и технической архитектур	Описание функциональной архитектуры (включая описание каждой функции, задачи, методов реализации). Описание технической архитектуры (включая описание размещения технических средств, условий эксплуатации, режима функционирования, организации резервного копирования и т.д.)	15
Формирование плана развертывание системного ландшафта	План развертывания системного ландшафта	10
Разработка физической модели данных	Физическая модель данных — описание таблиц БД, индексов, секций и других объектов БД	10
Разработка и согласование регламентов взаимодействия информационных систем	Согласованный и утвержденный набор регламентов взаимодействия, включающих описание интерфейсов, периодичности и т.п.	10
Проектирование процессов ETL	Описание процессов извлечения данных, алгоритмов трансформации и обеспечения качества данных, процессов загрузки и агрегации данных	20
Проектирование интерфейсов пользователя	Описание бизнес-слоя данных, интерфейсов ввода и предоставления данных, разграничения прав доступа	15
Оформление технического проекта	Пояснительная записка к техническому проекту	20
Согласование и утверждение	Согласованная и утвержденная пояснительная записка к техническому проекту	5

Жак Фреско: Проект Венера и технологии которые изменят мир до неузнаваемости

Стадия V. Рабочая документация

• Ведомость эксплуатационных документов
• Ведомость машинных носителей информации
• Паспорт
• Общее описание системы
• Технологическая инструкция
• Руководство пользователя
• Описание технологического процесса обработки данных (включая телеобработку)
• Инструкция по формированию и ведению базы данных (набора данных)
• Состав выходных данных (сообщений)
• Каталог базы данных (ПИМ)
• Спецификация
• Описание программ
• Текст программ

• Развернуты экземпляры БД. Созданы необходимые объекты БД
• Разработаны процессы ETL и процессы обеспечения качества данных. Выставлено расписание запуска процессов
• Реализованы дополнительные приложения
• Реализованы витрины данных и отчетность
• Настроены профили пользователей и прав доступа

Стадия VI. Ввод в действие

Этапы работРезультатДней

Подготовка объекта автоматизации к вводу системы в действие	Создание у Заказчика службы сопровождения системы (при необходимости)	10
Подготовка персонала	Обучение пользователей и администраторов системы	10
Комплектация системы поставляемыми изделиями	Закупка и завоз необходимого оборудования и программного обеспечения. Для снятия рисков поставки данный этап обычно выполняется на предыдущей стадии	20 — 100
Строительно-монтажные работы	Оборудование смонтировано в выделенном для этого помещении и подключено к каналам передачи данных	20
Пусконаладочные работы	Прошла наладка технических и программных средств. ПО системы перенесено в зону тестирования/промышленной эксплуатации. Настроена система резервного копирования. Проведена загрузка исторических данных в систему. Запущены процессы извлечения данных из систем-источников	20
Проведение предварительных испытаний	Испытания системы на работоспособность и соответствие техническому заданию в соответствии с ПИМ проведены. Устранение неисправностей и внесение изменений в документацию в соответствии с протоколом испытаний проведено. Акт приёмки системы в опытную эксплуатацию оформлен и подписан	10
Проведение опытной эксплуатации	Опытная эксплуатация проведена. Устранение неисправностей, доработка ПО и дополнительная наладка технических средств проведены	30 — 60
Проведение приёмочных испытаний	Испытания системы в соответствии с ПИМ проведены. Устранение неисправностей и внесение изменений в документацию проведено. Акт передачи системы в промышленную эксплуатацию оформлен и подписан	5
Завершение работ	Акт завершения работ подписан	5

Почему в BIM много платят. IT в строительстве

Стадия VII. Сопровождение

Этапы работРезультатДней

Выполнение работ в соответствии с гарантийными обязательствами	Выявленные недостатки системы устранены	365
Послегарантийное обслуживание	Система работает стабильно, без сбоев. Выявленные недостатки устранены	—

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

Источник: www.prj-exp.ru

Этап проектирования: технический проект

Техническое проектирование имеет свои особенности в зависимости от системы стандартов, по которым происходит разработка. Разберем эти отличия.

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

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

Технический проект в ЕСКД

В соответствии с требованиями ЕСКД, перечень работ данной стадии, порядок оформления и требования к содержанию конструкторских документов (КД) технического проекта описаны в ГОСТ 2.120-2013 «ЕСКД. Технический проект».

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

В техническом проекте должны быть определены конструктивные решения изделия и его основных частей: выполнены необходимые схемы, чертежи, обоснования, составлен перечень работ для стадии рабочей КД. Полный перечень КД, разрабатываемой на данной стадии, следует определить в соответствии с указаниями ГОСТ 2.102-2013 «ЕСКД. Виды и комплектность конструкторских документов» с учётом требований ГОСТ 2.120-2013 «ЕСКД. Технический проект».

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

Чертёж общего вида (электронная модель сборочной единицы) должен содержать изображение изделия, различные надписи и текстовую часть, которые позволяют понять принцип его работы, обозначения и наименования составных частей, порядок их взаимодействия, особенности конструктивного устройства, указания о выбранных посадках деталей, технические требования о применении определённых покрытий, способов, методов, обеспечивающих необходимое качество изделия. Изображение изделия должно содержать размеры, технические данные и характеристики, при необходимости – схему.

Пояснительная записка должна включать в себя описание всех принятых технических решений, расчёты, обоснования и результаты аналитической работы, результаты работ, проведённых на предыдущих стадиях проектирования изделия. Оформление пояснительной записки должно соответствовать требованиям ГОСТ 2.106-96 «ЕСКД. Текстовые документы» и ГОСТ 2.120-2013 «ЕСКД. Технический проект».

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

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

Технический проект программного изделия

В ЕСПД (ГОСТ 19-102-77 «ЕСПД. Стадии разработки») технический проект определён как стадия разработки программ и программных документов, необходимость проведения которой должна быть определена в техническом задании на разработку программного изделия.

Данная стадия состоит из двух этапов:

• разработка технического проекта (уточнение структуры данных, формы их представления, разработка алгоритма решения задачи, определение языка, структуры программы и требований к техническим средствам);
• утверждение технического проекта (разработка пояснительной записки по ГОСТ 19.404-79 «ЕСПД. Пояснительная записка. Требования к содержанию и оформлению», плана мероприятий по разработке и внедрению изделия, согласование и утверждение проекта).

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

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

Автоматизированные системы

В соответствии с ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» технический проект – это стадия процесса создания автоматизированной системы. На этой стадии выделены следующие этапы:

• разработка проектных решений по системе и её частям;
• разработка документации на АС и её части;
• разработка документации на разработку и поставку изделий для комплектования АС;
• разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

Виды, комплектность и обозначение документов при создании автоматизированных систем». Требования к содержанию документов приведены в методических указаниях РД50-34.698-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».

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

Источник: tehpis.ru

Часть 1. Этапы разработки проекта: стратегия и анализ

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

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

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

Проектирование информационных систем охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

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

Считается, что сложную систему невозможно описать в принципе. Это, в частности, касается систем управления предприятием. Одним из основных аргументов является изменение условий функционирования системы, например директивное изменение тех или иных потоков информации новым руководством. Еще один аргумент — объемы технического задания, которые для крупного проекта могут составлять сотни страниц, в то время как технический проект может содержать ошибки. Возникает вопрос: а может, лучше вообще не проводить обследования и не делать никакого технического проекта, а писать систему «с чистого листа» в надежде на то, что произойдет некое чудесное совпадение желания заказчика с тем, что написали программисты, а также на то, что все это будет стабильно работать?

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

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

Можно придерживаться классических подходов к разработке информационных систем, один из которых — схема «водопада» (рис. 1) — описан ниже. Кратко будут рассмотрены и некоторые другие подходы к разработке информационных систем, где использование элементов, описанных в схеме «водопада», также допустимо. Какого подхода из описываемых ниже придерживаться (и есть ли смысл придумывать собственный подход) — в какой-то мере дело вкуса и обстоятельств.

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

• Каскадная модель. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• Поэтапная модель с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью; время жизни каждого из этапов растягивается на весь период разработки.
• Спиральная модель. Особое внимание уделяется начальным этапам разработки — выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание некой версии продукта или какого-либо его компонента, при этом уточняются характеристики и цели проекта, определяется его качество и планируются работы следующего витка спирали.

Ниже мы рассмотрим некоторые схемы разработки проекта.

«Водопад» — схема разработки проекта

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации — MoSCoW — предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have — необходимые функции; Should have — желательные функции; Could have — возможные функции; Won’t have — отсутствующие функции.

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

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

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

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

• иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
• модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

• диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
• диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
• диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

ER-диаграммы

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

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом1, являются ключевыми (так Title Identity — ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3) означает «один», «птичья лапка» слева — «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок — «не обязательно», например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

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

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

Атрибуты сущностей могут быть ключевыми — они выделяются полужирным шрифтом; обязательными — перед ними ставится знак «*», то есть их значение всегда известно, необязательными (optional) — перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными.

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

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности — сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6.

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа «один к одному» (рис. 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Связи «многие к одному» представлены на рис. 8.

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

II — это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III — применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рис. 9.

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

II — применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10).

I — редко, но имеет место. Отражает связи альтернативного типа.

II — достаточно часто применяется для описания иерархий с любым числом уровней.

III — имеет место на ранних этапах. Часто отражает структуру «перечня материалов» (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рис. 11) и ряд рекурсивных связей (рис. 12).

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

Диаграммы потоков данных

Логическая DFD (рис. 13) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

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

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

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

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

Хранилище данных (data storage) позволяет на ряде участков определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информацию, которую оно содержит, можно использовать в любое время после ее определения, при этом данные могут выбираться в произвольном порядке. Имя хранилища должно идентифицировать его содержимое. В случае когда поток данных входит (выходит) в (из) хранилище и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

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

Диаграммы изменения состояний STD

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

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

Некоторые принципы проверки качества и полноты информационной модели
(источник — Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

Качество сущностей

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

Список проверочных вопросов для сущности:

• Отражает ли имя сущности суть данного объекта?
• Нет ли пересечения с другими сущностями?
• Имеются ли хотя бы два атрибута?
• Всего атрибутов не более восьми?
• Есть ли синонимы/омонимы данной сущности?
• Сущность определена полностью?
• Есть ли уникальный идентификатор?
• Имеется ли хотя бы одна связь?
• Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
• Ведется ли история изменений?
• Имеет ли место соответствие принципам нормализации данных?
• Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
• Не имеет ли сущность слишком общий смысл?
• Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

• Отсутствуют ли пересечения с другими подтипами?
• Имеет ли подтип какие-нибудь атрибуты и/или связи?
• Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?
• Имеется ли исчерпывающий набор подтипов?
• Не является ли подтип примером вхождения сущности?
• Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

Следует выяснить, а действительно ли это атрибуты, то есть описывают ли они тем или иным образом данную сущность.

Список проверочных вопросов для атрибута:

• Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
• Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
• Имеет ли атрибут только одно значение в каждый момент времени?
• Отсутствуют ли повторяющиеся значения (или группы)?
• Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
• Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
• Не может ли он быть пропущенной связью?
• Нет ли где-нибудь ссылки на атрибут как на «особенность проекта», которая при переходе на прикладной уровень должна исчезнуть?
• Есть ли необходимость в истории изменений?
• Зависит ли его значение только от данной сущности?
• Если значение атрибута является обязательным, всегда ли оно известно?
• Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
• Зависит ли его значение только от какой-то части уникального идентификатора?
• Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

Список проверочных вопросов для связи:

Не является ли связь переносимой?

• Заданы ли степень связи и обязательность для каждой стороны?
• Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

• Не является ли она избыточной?
• Не изменяется ли она с течением времени?
• Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

Функции системы

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

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

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

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

Уточнение стратегии

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

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

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

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

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

Источник: compress.ru

Технология разработки проектов строительства

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile).

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

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

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

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

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

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:

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

4. Обеспечиваем команду техническими инструментами

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

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

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

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

Например, нет смысла разрабатывать оформление заказа, пока не разработаешь корзину или каталог. Тестировщик не сможет проверить задачу, пока не положит товар в корзину. Лучше делегировать эту задачу одному человеку, чтобы он делал корзину, а затем оформление.

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

Постарайтесь избавиться от крупных задач — их сложно оценивать, контролировать, тестировать и запускать в релиз. В таких задачах гораздо чаще встречаются ошибки после релиза в боевую среду. Если задача занимает более 20-человека-часов — декомпозируйте ее на мелкие, иначе она рискует превратиться в «болото».

6. Делегируем задачи, контролируем их выполнение

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

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

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

Контролируйте сроки — например, можно проводить ежедневные или еженедельные встречи с командой. Это поможет держать руку на пульсе, следить за этапами реализации проекта и вовремя решать возникающие сложности.

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

7. Выкладываем, тестируем и дорабатываем продукт

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

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

После этого продукт выкатывается в боевую среду, его финально проверяют тестировщики.

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

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

Чтобы организовать процесс разработки, который будет работать без вашего участия:

1. Отталкивайтесь от методологии: она определит, как, в каком составе и в какие сроки вы будете работать;
2. Создайте команду специалистов и определите роль каждого: на самостоятельную команду можно положиться, ведь она сама принимает решения;
3. Не работайте вслепую: отталкивайтесь от запросов клиентов и создайте понятное, ясное и четкое техническое задание;
4. Обеспечьте рабочее пространство: для разработчиков это не только кресло, стол, кофе и печеньки, а репозиторий, технические инструменты и рабочее окружение;
5. Составьте график реализации проекта: разбивайте большие задачи на мелкие и следите, чтобы рабочий процесс был логичен, а разработчики не сидели без дела;
6. Назначьте ответственного по каждой задаче и контролируйте срок ее выполнения: так вам не придется удивлять разработчиков их «новыми» обязанностями спустя месяц со старта, и вы не затянете процесс даже при гибкой методологии;

Следите за продуктом даже после релиза: в IT-индустрии ни одно решение не будет работать вечно. Обновляйте модули, добавляйте новые технологии и инструменты, чтобы продукт всегда был актуальным.

Источник: rb.ru