Проектирование

В соответствии с Положением о составе разделов проектной документации и требованиях к их содержанию, утвержденного Постановлением Правительства РФ №87 от 16.02.2008, вводятся понятия «проектная документация» и «рабочая документация».

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

Стадийность проектирования:

• Одностадийное проектирование осуществляется при параллельной разработке проектной документации и рабочей документации, но разработка рабочей документации не может предшествовать разработке проектной документации.
• Двустадийное проектирование осуществляется при последовательной разработке проектной документации и рабочей документации.
• Трехстадийное проектирование (предпроектное предложение, проект, рабочая документация) – для объектов V, IV категорий сложности и для объектов III категории сложности с недостаточным перечнем исходно-разрешительной документации.

Исходные данные для проектирования.

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

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

Как правило, для разработки проектной документации, требуются следующие дополнительные исходные данные:

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

Состав проектной документации и рабочей документации.

Общий состав проектной документации регламентирован Градостроительным кодексом РФ и Постановлением Правительства РФ №87 от 16. 02.2008. Согласно этим документам проектная документация состоит в общем случае из следующих разделов:

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

Проектирование — процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния.

Проектирование — процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния. В технике — разработка проектной, конструкторской и другой технической документации, предназначенной для осуществления строительства, создания новых видов и образцов. В процессе проектирования выполняются технические и экономические расчёты, схемы, графики, пояснительные записки, сметы, калькуляции и описания. Проект — комплект указанной документации и материалов (определённого свойства), результат проектирования. Проект какого-либо объекта может быть индивидуальным или типовым. При разработке индивидуальных проектов широко применяются типовые проектные решения. В информационных системах Проектирование — это первоначальная фаза проекта, которая включает в себя следующие стадии: концептуальную, моделирования, конструирования и технологической подготовки. ,   Виды проектирования Инженерных систем (вентиляции, газопроводов, электросетей и др. инфраструктуры) — Инженерное проектирование Транспорта и транспортной инфраструктуры (Дорог, мостов и др.) — Транспортное проектирование Зданий и других наземных объектов — Архитектурное проектирование Промышленных объектов — промышленное проектирование Ландшафтное проектирование Техники и оборудования — техническое проектирование Наружного и внутреннего оформления — дизайн-проектирование Других объектов.   Общие сведения о проектировании Виды проектирования согласно Градостроительному кодексу РФ подразделяются на: Территориальное планирование Архитектурно-строительное проектирование Архитектурно-строительное проектирование осуществляется путем подготовки проектной документации применительно к объектам капитального строительства и их частям, строящимся, реконструируемым в границах принадлежащего застройщику земельного участка, а также в случаях проведения капитального ремонта объектов капитального строительства, если при его проведении затрагиваются конструктивные и другие характеристики надежности и безопасности таких объектов (далее также — капитальный ремонт). Виды проектов В зависимости от специфики поставленных задач разрабатываемые проекты можно разделить на несколько основных видов: Проекты нового строительства. Проекты реконструкции, расширения, технического перевооружения, модернизации. Проекты усиления, восстановления, капитального ремонта. Проектная документация и рабочая документация. Стадийность проектирования   В настоящее время, в связи с вступлением в силу Положения о составе разделов проектной документации и требованиях к их содержанию, утвержденного Постановлением Правительства РФ №87 от 16.02.2008, не предусматривается стадийность проектирования, а вводятся понятия «проектная документация» и «рабочая документация». Основным проектным документом является проектная документация, состоящая из текстовой и графической частей. Проектная документация (за исключением некторых случаев) направляется застройщиком или заказчиком на государственную экспертизу и, при наличии положительного заключения государственной экспертизы, утверждается им. Здесь необходимо подчеркнуть, что объем проектной документации, как правило, недостаточен для строительства объекта: в ней отсутствуют необходимые спецификации и требуемая степень детализации. Проектная документация содержит только основные технические решения, позволяющие оценить их безопасность, а так же доказать техническую возможность (а в некоторых случаях — и экономическую целесообразность) реализации инвестиционного проекта. Для реализации в процессе строительства технических решений, заложенных в проектной документации, разрабатывается рабочая документация, состоящая из текстовых документов, рабочих чертежей и спецификаций оборудования и изделий. Поскольку единого документа, регламентирующего состав и содержание рабочей документации, не существует, при ее разработке необходимо руководствоваться соответствующими стандартами СПДС. Однако Министерство регионального развития РФ в своем письме заявляет, что «объем, состав и содержание рабочей документации должны определяться заказчиком (застройщиком) в зависимости от степени детализации решений, содержащихся в проектной документации, и указываться в задании на проектирование». На наш взгляд целесообразно требования стандартов СПДС дополнять и конкретизировать в задании на проектирование требованиями заказчика, но при этом обеспечить непротиворечивость этих требований стандартам СПДС. Поскольку Положения о составе разделов проектной документации и требованиях к их содержанию не содержит требования о разработке рабочей документации только после разработки проектной документации, можно сделать вывод о том, что проектная документация и рабочая документация могут разрабатываться параллельно, но разработка рабочей документации не может предшествовать разработке проектной документации. Отсюда можно дать следующие пояснения относительно стадийности проектирования: Одностадийное проектирование осуществляется при параллельной разработке проектной документации и рабочей документации. Ранее проектный документ, разрабатываемый при одностадийном проектировании, именовался «рабочий проект» (РП) и состоял из утверждаемой части рабочего проекта и рабочей документации. Эти две составляющие рабочего проекта соответствуют принятым в настоящее время понятиям «проектная документация» и «рабочая документация» соответственно. Двустадийное проектирование осуществляется при последовательной разработке проектной документации и рабочей документации. Ранее проектные документы, разрабатываемые при двустадийном проектировании именовались «проект» или «ТЭО» (1 стадия) и «рабочая документация» (2 стадия). Эти два проектных документа так же соответствуют принятым в настоящее время понятиям «проектная документация» и «рабочая документация» соответственно. Трехстадийное проектирование (предпроектное предложение, проект, рабочая документация) — для объектов V, IV категорий сложности и для объектов III категории сложности по индивидуальным проектам, с недостаточным перечнем исходно-разрешительной документации. ПИСЬМО МИНИСТЕРСТВО РЕГИОНАЛЬНОГО РАЗВИТИЯ РФ 22 июня 2009 г. N 19088-СК/08 Письмо №19088-СК/08 от 22. 06.09 В соответствии с пунктом 2 Постановления Правительства Российской Федерации от 16 февраля 2008 г. № 87 О составе разделов проектной документации и требованиях к их содержанию   Министерство регионального развития Российской Федерации в соответствии с многочисленными обращениями, а так же в соответствии с пунктом 2 Постановления Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию» (далее — Положение) сообщает.   Инструкция о порядке разработки, согласования, утверждения и составе документации на строительство предприятий, зданий и сооружений (СНиП 11-01-95), утвержденная постановлением Министерства строительства Российской Федерации от 30 июня 1995 г. № 18-64 со вступлением в силу указанного постановления не подлежит применению. Также не подлежит применению Порядок разработки, согласования, утверждения и состав обоснований инвестиций в строительство предприятий, зданий и сооружений (СП 11-101-95), утвержденный постановлением Минстроя России от 30. 06 1995 №18-63.   В отличие от ранее действовавших нормативных документов Положением не предусматривается стадийность проектирования: «ТЭО», «проект», «рабочий проект», а используются понятия «проектная документация» и «рабочая документация».   С учетом того, что постановлением Правительства Российской Федерации «О порядке организации и проведения государственной экспертизы проектной документации и результатов инженерных изысканий» от 5 марта 2007 № 145 предусмотрен порядок проведение экспертизы в отношении документации, разработанной в объеме стадии «проектная документация», заказчик должен подготовить ее в соответствии с указанным положением, и представить для проведения государственной экспертизы.   В соответствии с пунктом 4 Положения рабочая документация разрабатывается в целях реализации в процессе строительства архитектурных, технических и технологических решений. Кроме того, положение не содержит указаний на последовательность разработки рабочей документации, что определяет возможность ее выполнения, как одновременно с подготовкой проектной документации, так и после ее подготовки.   При этом объем, состав и содержание рабочей документации должны определяться заказчиком (застройщиком) в зависимости от степени детализации решений, содержащихся в проектной документации, и указываться в задании на проектирование.   По мнению Минрегиона России, при одновременной разработке проектной и рабочей документации по решению заказчика и с согласия экспертной организации, вся документация может быть представлена на государственную экспертизу. При этом размер платы за проведение государственной экспертизы нежилых объектов капитального строительства и (или) результатов инженерных изысканий рекомендуется осуществлять от базовой (в ценах 2001 года) стоимости разработки проектной документации (рабочей документации, если она представлялась на экспертизу) и (или) изыскательских работ, в размере не более величин, установленных заказчиком при определении начальной (максимальной) цены конкурса (аукциона) на выполнение указанных работ.   В связи с изменением требований к составу разделов проектной документации, предусмотренных Положением, Минрегион России рекомендует при определении стоимости проектных работ, принимать распределение базовой цены проектирования, рассчитанной с использованием справочников базовых цен на проектные работы, в зависимости от стадии проектирования в следующих размерах: проектная документация — 40%  рабочая документация — 60%.   В зависимости от специфики объектов строительства и -полноты разработки проектной и рабочей документации рекомендуемое соотношение базовой цены проектирования может корректироваться по согласованию между исполнителем проектных работ и заказчиком.   Кроме того, если заданием на проектирование предусмотрена одновременная разработка проектной, и полная или частичная разработка рабочей документации, то суммарный процент базовой цены определяется по согласованию между заказчиком (застройщиком) строительства и лицом, осуществляющим подготовку такой документации, в зависимости от архитектурных, функционально-технологических, конструктивных и инженерно-технических решений, содержащихся в проектной документации, а также степени их детализации.   Во исполнении пункта 6 Положения подготовлен приказ Минрегиона России об утверждении правил выполнения и оформления текстовых и графических материалов, входящих в состав проектной и рабочей документации, который находится на регистрации в Минюсте России.   До вступления в силу указанного приказа выполнение и оформление текстовых и графических материалов, входящих в состав проектной и рабочей документации, рекомендуется осуществлять с использованием ранее принятых стандартов Системы проектной документации для строительства, стандартов Единой системы конструкторской документации в части, не противоречащей законодательству Российской Федерации о техническом регулировании, законодательству Российской Федерации о градостроительной деятельности.   Одновременно Минрегион России сообщает, что с выходом данного письма письмо Минрегиона России от 08.08.2008 № 19512-СМ/08 утратило силу. С. И. Круглик Состав проектной документации и рабочей документации   Общий состав проектной документации регламентирован Градостроительным кодексом РФ и конкретизирован в Положении о составе разделов проектной документации и требованиях к их содержанию, утвержденном Постановлением Правительства РФ №87 от 16.02.2008. Согласно этим документам проектная документация на объекты производственного и непроизводственного назначения (кроме линейных объектов) состоит в общем случае из 12 разделов Пояснительная записка Схема планировочной организации земельного участка Архитектурные решения Конструктивные и объемно-планировочные решения Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений (включает 7 подразделов: система электроснабжения; система водоснабжения; система водоотведения; отопление, вентиляция и кондиционирование воздуха, тепловые сети; сети связи; система газоснабжения; технологические решения) Проект организации строительства Проект организации работ по сносу или демонтажу объектов капитального строительства Перечень мероприятий по охране окружающей среды; Мероприятия по обеспечению пожарной безопасности; Мероприятия по обеспечению доступа инвалидов Смета на строительство объектов капитального строительства Иная документация в случаях, предусмотренных федеральными законами Состав рабочей документации определяется соответствующими стандартами СПДС и конкретизируется и дополняется указаниями заказчика в задании на проектирование   Исходные данные для проектирования   Градостроительным кодексом (п. 6, ст. 48) предусмотрена обязанность застройщика (заказчика) передать проектировщику следующие исходные данные: Градостроительный план земельного участка Результаты инженерных изысканий (как правило, состоят из результатов инженерно-геодезических изысканий, инженерно-геологических изысканий, инженерно-экологических изысканий) Технические условия на подключение к сетям инженерно-технического обеспечения В действительности, для разработки проектной документации, как правило, требуются следующие дополнительные исходные данные: Разрешительное письмо Комитета по государственному контролю, использованию и охране памятников истории и культуры (для объектов, находящихся в зоне охраны недвижимых памятников истории и культуры). Утверждённое задание на проектирование. Утвержденное технологическое задание (для объектов со специальной технологией) Инвентарные планы этажей окружающей застройки. Обмерные чертежи (для объектов реконструкции). Заключение по результатам обследования фундаментов и конструкций (по объектам окружающей застройки в стесненных условиях строительства и по объектам реконструкции). Исходные данные и требования по инженерно-техническим мероприятиям ГО и ЧС. Справочная литература: В настоящем стандарте использованы ссылки на следующие стандарты: ГОСТ 2.004—88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ ГОСТ 2.101—68 ЕСКД. Виды изделий ГОСТ 2.102—68 ЕСКД. Виды и комплектность конструкторских документов ГОСТ 2.105—95 ЕСКД. Общие требования к текстовым документам ГОСТ 2.108—68 ЕСКД. Спецификация ГОСТ 2.109—73 ЕСКД. Основные требования к чертежам ГОСТ 2. 113—75 ЕСКД. Групповые и базовые конструкторские документы ГОСТ 2.114—95 ЕСКД. Технические условия ГОСТ 2.301—68 ЕСКД. Форматы ГОСТ 2.302—68 ЕСКД. Масштабы ГОСТ 2.303—68 ЕСКД. Линии ГОСТ 2.304—81 ЕСКД. Шрифты чертежные ГОСТ 2.305—68 ЕСКД. Изображения — виды, разрезы, сечения ГОСТ 2.306—68 ЕСКД. Обозначения графические материалов и правила их нанесения на чертежах ГОСТ 2.307—68 ЕСКД. Нанесение размеров и предельных отклонений ГОСТ 2.308—79 ЕСКД. Указание на чертежах допусков форм и расположения поверхностей ГОСТ 2.309—73 ЕСКД. Обозначение шероховатости поверхностей ГОСТ 2.310—68 ЕСКД. Нанесение на чертежах обозначений покрытий, термической и других видов обработки ГОСТ 2.311—68 ЕСКД. Изображение резьбы ГОСТ 2.312—72 ЕСКД. Условные изображения и обозначения швов сварных соединений ГОСТ 2.313—82 ЕСКД. Условные изображения и обозначения неразъемных соединений ГОСТ 2.314—68 ЕСКД. Указания на чертежах о маркировании и клеймении изделий ГОСТ 2.316— 68 ЕСКД. Правила нанесения на чертежах надписей, технических требований и таблиц ГОСТ 2.317—69 ЕСКД. Аксонометрические проекции ГОСТ 2.410—68 ЕСКД. Правила выполнения чертежей металлических конструкций ГОСТ 2.501—88 ЕСКД. Правила учета и хранения ГОСТ 21.110—95 СПДС. Спецификация оборудования, изделий и материалов ГОСТ 21.113—88 СПДС. Обозначения характеристик точности ГОСТ 21.114—95 СПДС. Правила выполнения эскизных чертежей общих видов нетиповых изделий ГОСТ 21.203—78 СПДС. Правила учета и хранения подлинников проектной документации ГОСТ 21.501— 93 СПДС. Правила выполнения архитектурно-строительных рабочих чертежей. Проектная документация — в соответствии со статьей 48 [[Градостроительный кодекс Российской Федерации|Градостроительного кодекса РФ представляет собой документацию, содержащую материалы в текстовой форме и в виде карт (схем) и определяющую архитектурные, функционально-технологические, конструктивные и инженерно-технические решения для обеспечения строительства, реконструкции объектов капитального строительства, их частей, капитального ремонта, если при его проведении затрагиваются конструктивные и другие характеристики надежности и безопасности объектов капитального строительства. Виды работ по подготовке проектной документации, которые оказывают влияние на безопасность объектов капитального строительства, должны выполняться только индивидуальными предпринимателями или юридическими лицами, имеющими выданные саморегулируемой организацией свидетельства о допуске к таким видам работ. Иные виды работ по подготовке проектной документации могут выполняться любыми физическими или юридическими лицами. Лицом, осуществляющим подготовку проектной документации, может являться застройщик либо привлекаемое застройщиком или заказчиком на основании договора физическое или юридическое лицо. Лицо, осуществляющее подготовку проектной документации, организует и координирует работы по подготовке проектной документации, несет ответственность за качество проектной документации и ее соответствие требованиям технических регламентов. Лицо, осуществляющее подготовку проектной документации, вправе выполнять определенные виды работ по подготовке проектной документации самостоятельно при условии соответствия такого лица требованиям к видам работ, и (или) с привлечением других соответствующих указанным требованиям лиц. В соответствии с Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требованиях к их содержанию» проектная документация на объекты капитального строительства производственного и непроизводственного назначения состоит из 12 разделов: Раздел 1 «Пояснительная записка». Раздел 2 «Схема планировочной организации земельного участка». Раздел 3 «Архитектурные решения». Раздел 4 «Конструктивные и объемно-планировочные решения». Раздел 5 «Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений» а) подраздел «Система электроснабжения»; б) подраздел «Система водоснабжения»; в) подраздел «Система водоотведения»; г) подраздел «Отопление, вентиляция и кондиционирование воздуха, тепловые сети»; д) подраздел «Сети связи»; е) подраздел «Система газоснабжения»; ж) подраздел «Технологические решения»; Раздел 6 «Проект организации строительства». Раздел 7 «Проект организации работ по сносу или демонтажу объектов капитального строительства». Раздел 8 «Перечень мероприятий по охране окружающей среды». Раздел 9 «Мероприятия по обеспечению пожарной безопасности». Раздел 10 «Мероприятия по обеспечению доступа инвалидов». Раздел 11 «Смета на строительство объектов капитального строительства». Раздел 12 «Иная документация в случаях, предусмотренных федеральными законами». Проектная документация на линейные объекты капитального строительства (далее — линейные объекты) состоит из 10 разделов: Раздел 1 «Пояснительная записка». Раздел 2 «Проект полосы отвода». Раздел 3 «Технологические и конструктивные решения линейного объекта. Искусственные сооружения». Раздел 4 «Здания, строения и сооружения, входящие в инфраструктуру линейного объекта». Раздел 5 «Проект организации строительства». Раздел 6 «Проект организации работ по сносу (демонтажу) линейного объекта». Раздел 7 «Мероприятия по охране окружающей среды». Раздел 8 «Мероприятия по обеспечению пожарной безопасности». Раздел 9 «Смета на строительство». Раздел 10 «Иная документация в случаях, предусмотренных федеральными законами». Рабочая документация — в соответствии с Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требованиях к их содержанию» это документация, которая разрабатывается в целях реализации в процессе строительства архитектурных, технических и технологических решений. Состав и содержание рабочей документации должны определяться заказчиком (застройщиком) в зависимости от степени детализации решений, содержащихся в проектной документации, и указывается в задании на проектирование. В соответствии с письмом Министерства регионального развития Российской Федерации от 22. 06.2009 №19088-СК/08 в отличие от ранее действовавших нормативных документов не предусматривается стадийность проектирования: «ТЭО», «Проект», «Рабочий проект», а используются понятия «Проектная документация» и «Рабочая документация». По мнению Минрегиона России, при одновременной разработке проектной и рабочей документации по решению заказчика и с согласия экспертной организации, вся документация может быть представлена на государственную экспертизу. В связи с изменением требований к составу разделов проектной документации, предусмотренных Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87, Минрегион России рекомендует при определении стоимости проектных работ, принимать распределение базовой цены проектирования, рассчитанной с использованием справочников базовых цен на проектные работы, в зависимости от стадии проектирования в следующих размерах: проектная документация — 40%, рабочая документация — 60%. В зависимости от специфики объектов строительства и полноты разработки проектной и рабочей документации рекомендуемое соотношение базовой цены проектирования может корректироваться по согласованию между исполнителем проектных работ и заказчиком. Кроме того, если заданием на проектирование предусмотрена одновременная разработка проектной, и полная или частичная разработка рабочей документации, то суммарный процент базовой цены определяется по согласованию между заказчиком (застройщиком) строительства и лицом, осуществляющим подготовку такой документации, в зависимости от архитектурных, функционально-технологических, конструктивных и инженерно-технических решений, содержащихся в проектной документации, а также степени их детализации. Структурная схема Государственной экспертизы проектной документации на капитальное строительство «Назад | Вперед » Навигация и структура информации на сайте

Обоснование продолжительности подготовки проектной документации для объектов капитального строительства

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

Продолжительность проектирования обусловлена назначением объекта капитального строительства и его сложностью. Продолжительность выполнения проектных работ функционально связана со следующими факторами [1]:

1. Нормативом выполнения единицы проектной продукции;
2. Общей трудоемкостью проектных работ;
3. Степенью технологической возможности совмещения процессов проектирования.

Продолжительность выполнения проектных работ определяется общим объемом проектных работ, предусмотренным требованиями нормативных документов на проектирование, и не учитывает время, необходимое для выполнения неучтенных работ, в том числе:

1. сбор и анализ исходных данных;
2. выполнение изыскательских работ;
3. расчет максимальных нагрузок по каждому виду сетей инженерно-технического обеспечения;
4. подготовка и согласование задания на проектирование;
5. согласование проектных решений с заинтересованными организациями и органами надзора в строительстве;
6. корректировка проектных решений, в связи с изменениями условий проектирования и др.

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

Нормы продолжительности проектирования застройки микрорайонов (кварталов), градостроительных комплексов с инженерными сетями, благоустройством и подготовкой территории (без «привязки» жилых домов и объектов культурно-бытового и коммунального назначения) приведена в табл. 1 [1].

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

Таблица 1

Нормы продолжительности проектирования объектов строительства города Москвы

Наименование объекта	Мощность, тыс. кв. м общей площади	Продолжительность проектирования в месяцах
		проектной документации	рабочей документации	проектной и рабочей документации
1. Многоэтажная застройка (9 этажей и более)	до 50	4,0	4,5	7,0
	от 50 до 100	от 4,0 до 5,0	от 4,5 до 6,0	от 7,0 до 8,5
	от 100 до 150	от 5,0 до 5,5	от 6,0 до 7,0	от 8,5 до 9,5
	от 150 до 250	от 5,5 до 6,0	от 7,0 до 8,0	от 9,5 до 10,0
	свыше 250	от 6,0 до 6,5	от 8,0 до 8,5	от 10,0 до 10,5
2. Среднеэтажная застройка (5-8 этажей)	до 15	4,5	5,0	8,0
	от 15 до 75	от 4,5 до 6,5	от 5,0 до 7,5	от 8,0 до 10,0
	свыше 75	от 6,5 до 7,5	от 7,5 до 8,5	от 10,0 до 11,0
3. Малоэтажная застройка (до 4 этажей)	до 5	1,5	2,0	2,5
	от 5 до 35	от 1,5 до 3,0	от 2,0 до 3,5	от 2,5 до 5,0
	свыше 35	от 3,0 до 4,0	от 3,5 до 4,5	от 5,0 до 6,0

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

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

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

Общая продолжительность выполнения работ по подготовке проектной документации на объект капитального строительства формируется на основе продолжительности разработки разделов, определяющих критический путь. В качестве таких разделов выступают, как правило, два раздела проектной документации: АР – «Архитектурные решения» и КР – «Конструктивные и объемно-планировочные решения» [2].

Продолжительность разработки раздела или его части определяется пропорционально доле этого раздела или его части в общем объеме проектных работ. При этом продолжительность проектирования архитектурно-строительного раздела принимается равной общей продолжительности проектирования с коэффициентом 0,9, а продолжительность проектирования прочих разделов – с коэффициентом 1,2, учитывающим время, необходимое для ознакомления с проектом в целом, но не менее одного месяца.

Доля раздела в общем объеме проектных работ определяется в соответствии с разбивкой, принятой в организации-исполнителе проектных работ.

На рис. 1 показан пример календарного графика на проектирование многофункционального комплекса, состоящего из нескольких объектов, связанных единым архитектурным замыслом [1].

Состав многофункционального комплекса [1]:

1. Монолитная 12-этажная гостиница, продолжительность проектирования 7,5 мес.;
2. Ресторан на 200 посадочных мест, продолжительность проектирования 3,5 мес. ;
3. Офисные помещения на 100 раб. мест, продолжительность проектирования 3 мес.

Рисунок 1. Календарный график разработки проекта

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

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

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

1. выполнить первичный анализ возможности выполнения проектных работ в заданные заказчиком сроки;
2. установить объективные сроки подготовки проектной документации для строительства объектов капитального строительства;
3. установить правовое основание для преодоления разногласий между заказчиком и исполнителем проектных работ по продолжительности проектирования;
4. предварительно определить прибыльность проекта для организации;
5. иметь возможность обеспечения качества выполнения проектных работ в целом по проекту;
6. знать независимую оценку сроков выполнения работ по объектам-аналогам;
7. определить сложность и нестандартность решений предстоящих задач.

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

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

1. разработку сквозного плана-графика проектирования объекта на основе действующих норм продолжительности проектных работ;
2. корректировку (актуализацию) сквозного плана-графика в ходе выполнения проектных работ.

Планирование проектных работ по объектам осуществляют главные инженеры проекта (ГИПы) и главные архитекторы проекта (ГАПы). С помощью современных программных средств они определяют сроки начала и окончания каждого процесса проектирования с учетом возможных изменений. Окончательные сроки выполнения проектных работ устанавливаются на этапе переговоров с заказчиками и прописываются в договорах.

Литература:

1. Сборник 11.1 «Нормы продолжительности проектирования объектов строительства МРР-11.1-16»
2. Постановление Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию».

Автор: Сергей Волков, канд. техн. наук, доцент СПбГАСУ, г. Санкт-Петербург

Разработка проектной документации, подготовка и оформление

Наличие в штате компании более 50 профессиональных инженеров различного профиля позволяет выполнять комплексное проектирование.

 

Проектно-строительная компания «Эверест» предоставляет услуги по разработке проектной документации на всех стадиях проекта, а именно:

• «Технико-экономическое обоснование» включает в себя вариантные предложение предпроектных решений со сравнительной оценкой инвестиционных затрат на реализацию объекта
• «Проектная документация» включает в себя разделы проекта, необходимые для получения положительного заключения органов экспертиз
• «Рабочая документация» включает в себя все разделы проектно-сметной документации, необходимые для получения разрешения на строительство, а также производства строительно-монтажных работ
• «Авторский надзор за строительством» производится в целях контроля соответствия выполняемых строительно-монтажных работ, утвержденной проектной документации

Основной приоритет отдается:

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

 

Сделайте заказ на разработку проектной документации позвонив на многоканальный телефон: +7 (343) 342-02-10
или отправьте Ваш запрос на e-mail: everest@pskeverest. ru

 

Подготовка и разработка разрешительной документации

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

 

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

 

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

 

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

• Во-первых, заказчикам или же застройщикам, которые хотят сэкономить на специализированной организации, нужно понимать, что невозможно быть специалистом во всем. Если Вы отлично разбираетесь в самом строительстве, то в документации и формализации процесса разбираться придется долго и нудно. Подготовка исходно разрешительной документации – это процесс, который подразумевает тщательный анализ нормативной базы, состоящей из законов, кодексов и подзаконных актов. К тому же, Вам придется неоднократно обращаться в соответствующие органы власти с целью оформления проектной документации. Специалисты, ответственные за сбор ИРД смогут сделать это намного качественнее и быстрее.
• Во-вторых, состав исходно разрешительной документации – это огромное количество документов, которые необходимо получить для начала самого процесса строительства. Для того, чтобы тот или иной орган государственной власти выразил свое согласие на Ваше строительство, необходимо отстоять немалые очереди и заполнить огромное количество бланков и формуляров. Собирая десятки документов, Вы потратите времени ровно в два, а то и в три раза больше, чем опытный представитель проектной организации.
• В-третьих, если Вы обращаетесь к специалисту за составлением проекта объекта, Вы гарантируете себе отсутствие проблем с последующим оформлением ИРД. Проектирование капитальных сооружений – это тоже довольно сложная и формализованная процедура. Проект здания должен соответствовать не только установленным нормам и стандартам, но и учитывать состав проектной документации, закрепленный нормативно. Этот состав включает в себя 12 разделов, каждый из которых должен быть тщательно выполнен и проработан.
• В-четвертых, стоимость проектной документации, оформленной специализированными агентствами, далеко не заоблачная. Проект Вашего здания – это его основа, это залог того, что оно найдет нужных инвесторов и будет введено в эксплуатацию без особых проблем. На проектировании капитального строения экономить не стоит: специалист за умеренную плату учтет все требования технологических норм и нормативных актов для того, чтобы в дальнейшем процессе строительства у заказчика и застройщика не возникало никаких проблем.

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

Проектная документация — разработка, составление

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

Архитектурный отдел

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

Отдел дизайна

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

Отдел технологического проектирования

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

Отдел генплана

Генеральный план — основной регламентирующий документ в градостроительной деятельности, на основании которого осуществляется планировка, застройка, реконструкция и иные виды освоения территорий.

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

Отдел инженерных систем

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

• системы электроснабжения и электроосвещения;
• системы водоснабжения;
• системы водоотведения и канализации;
• системы отопления и теплоснабжения;
• системы вентиляции и кондиционирования;
• сети связи

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

Отдел инженерной защиты

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

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

Отдел специализированных разделов

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

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

Проект организации строительства

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

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

Решения принятые в ПОС оказывают существенное влияние на сметную стоимость, а также ход строительного производства, и могут существенно снизить затраты Инвестора на осуществление строительства.

НЕОКА | СТАДИИ ПРОЕКТИРОВАНИЯ — ПРЕДВАРИТЕЛЬНОЕ ПРОЕКТИРОВАНИЕ, ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ (СТАДИЯ ПРОЕКТ), РАБОЧАЯ ДОКУМЕНТАЦИЯ, РАБОЧИЙ ПРОЕКТ. РАЗРАБОТКА ПРОЕКТНОЙ И РАБОЧЕЙ ДОКУМЕНТАЦИИ.

Введение.

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

1. Общие положения.

Разработка проектной и рабочей документации зданий и сооруженийосуществляется на основании Постановления Правительства РФ №87, — нормативного документа, который регламентирует состав разделов проектной документации и требованиях к их содержанию.
Оформление чертежей проектной и рабочей документации осуществляется на основании ГОСТ 21. 101-97, который устанавливает основные требования к оформлению проектной и рабочей документации на строительство предприятий, зданий и сооружений различного назначения.

2. Стадии проектирования.

Существуют две схемы организации проектных работ:
   •   одностадийное проектирование;
   •   двухстадийное проектирование.

2.1. Одностадийное проектирование осуществляется без разработки стадии проект (П), при этом утверждаемая часть проекта, включающая в себя расчет конструкций, пояснения проектных решений, перечень исходных данных и т.д., разрабатывается в общем объеме стадии. Данная схема проектирования целесообразна в тех случаях, когда отсутствует необходимость проходить государственную экспертизу.
Подобные ситуации детально описаны в статье 49 Градостроительного кодекса РФ. Для заказчика одностадийное проектирование удобно тем, что оно экономит сроки на производство проектных работ.

Упрощенная схема организации проектных работ при одностадийном проектировании выглядит следующим образом:
   1.    Предварительное проектирование – разработка регламентного альбома, архитектурного эскиза, стадии ПП (предварительный проект), стадии ТЭО, оно необходимо для согласования в местном архитектурно-планировочном управлении (АПУ) и для обоснования размещения объекта нового строительства или реконструкции на проектируемой участке;
   2.   Согласование в местном АПУ;
   3.   Рабочее проектирование – разработка рабочего проекта (РП), представляющего собой комплект чертежей и указаний для проведения строительных работ.
В случаях, когда необходимо проходить экспертизу и иные согласования использование данной схемы не целесообразно ввиду возникновения дополнительных рисков, выраженных в затягивании сроков подачи проектной документации на согласование экспертизой, а соответственно и сроков проектирования в целом.

2.2. Двухстадийное проектирование осуществляется в две стадии. Схема позволяет разбить весь объем проектных работ на две части и предоставить на согласование часть проектной документации, минимально необходимой для её прохождения, не дожидаясь окончания всего проектирования. Это позволяет на более ранних стадиях разработки проектной документации снять возможные экспертные замечания, не прибегая к значительным изменениям в рабочей документации (Р).
Данная схема проектирования целесообразна в случаях, когда требуется согласование в государственной экспертизе. Подобные ситуации детально описаны в «Градостроительном кодексе РФ», статья 49.

Упрошенная схема организации проектных работ при двухстадийном проектировании выглядит следующим образом:
   1.   Предварительное проектирование – разработка регламентного альбома, архитектурного эскиза, стадии ПП (предварительный проект), стадии ТЭО, оно необходимо для согласования в местном архитектурно-планировочном управлении (АПУ) и для обоснования размещения объекта нового строительства или реконструкции на проектируемой участке;
   2.   Согласование в местном АПУ;
   3.   Разработка стадии проект (П) – разработка пакета проектной документации, минимального необходимого для прохождения государственной экспертизы;
   4.    Согласование проектной документации – подача документов в согласующий орган и снятие замечаний;
   5.   Рабочее проектирование – разработка рабочей документации (Р), содержащей пакет чертежей и указаний для проведения строительных работ.

Проектирование зданий и сооружений в Москве! Услуги проектирования недорого!

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

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

Что входит в состав проектной документации?

Состав проектной документации по 87 постановлению 2016 года Правительства РФ включает в себя следующие документы.

• Пояснительная записка проектной документации. Раздел проектной документации «Пояснительная записка» включает в себя основание для проектирования – решения федеральных служб и муниципальных органов на проведение строительства или реконструкции зданий, краткую характеристику сооружения и вопросы по градостроительному проектированию, генеральный план с элементами благоустройства территории, архитектурно-строительные решения и другие немаловажные моменты.
• Схема организации земельного участка. К этому этапу относятся дополнительные разделы проектной документации: ситуационный план, схема генерального плана с включением всех зданий и сооружений, общего объема работ по благоустройству участка, решений относительно наружных инженерных сетей.
• Конструктивные и объемно-планировочные решения. На этом этапе разработки разработка проектно-сметной документации помещения располагаются в целостном комплексе – таким образом, чтобы они соответствовали всем функциональным, экономическим, архитектурно-художественным и техническим требованиям.
• Сведения о технологических решениях и об инженерном оборудовании. Проектная документация на строительство частного дома обязательно должна включать в себя информацию об электроснабжении, кондиционировании воздуха, водоснабжении, дренажных системах и канализации, газоснабжении, инженерных сетях и связях, тепловых и отопительных сетях.
• Проект организации строительных работ. Согласно основным требованиям к проектной и рабочей документации, к этому этапу относится целый пакет документов: календарный и генеральный план строительства, организационно-технологические схемы, расчет потребности транспортных средств, оборудования и кадров, необходимых для выполнения строительных работ.

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

Мы оперативно выполним по ГОСТу оформление проектной документации и поможем организовать Вам государственную экспертизу проектной документации для строительства.

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

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

Заказать услуги

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

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

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

* Примечание. * Здесь я описываю более мелких клиентов, которым нужна единоличная армия от своего разработчика. Это не единственный путь, по которому может пойти фрилансер, и это не единственные клиенты, с которыми мы работаем в Toptal, но это тот путь, который мне нравится больше всего. Конечно, если вы работаете в команде, а не в одиночку, некоторые из перечисленных ниже не применимы. Например, если вы используете Agile-методологии или Scrum, вы, вероятно, захотите немного по-другому структурировать свои этапы.

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

Вы все слышали о первостепенной важности общения.Вы не сможете работать, получив по Skype несколько предложений с кратким описанием и сказав : «Увидимся через три месяца, когда я закончу». Вы должны поддерживать связь со своим клиентом и на каждом этапе своей работы удостовериться, что у вас есть совпадающие представления о цели, потому что действительно редко, когда клиент отправляет вам макеты и подробные функциональные спецификации. Вы получите очень общее представление о том, что программное обеспечение должно делать, как должно выглядеть и работать. Если вы напишете приложение на основе краткого описания, с которого обычно начинаете, почти нет шансов, что ваш клиент будет доволен результатом.На каждом этапе вы должны приближаться к соглашению.

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

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

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

Итак, когда вы беретесь за новый проект , прежде чем даже откроете Xcode или Visual Studio, вам необходимо иметь четкие и согласованные цели дизайна . И эти цели должны быть установлены в документе спецификации. Если клиент еще не написал его, вам следует написать его и отправить ему на рассмотрение, прежде чем вы даже откроете свою IDE. И , если вы встречаетесь с клиентом, который откровенно говорит: «У нас нет времени на проектную документацию», вам следует отказаться от проекта , потому что у вас впереди проблемы.Спецификация не должна быть особенно длинной; это может быть всего несколько страниц, но, по крайней мере, он должен содержать макет пользовательского интерфейса, включать в себя каркасы (если есть компонент пользовательского интерфейса) и устанавливать этапы завершения.

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

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

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

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

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

Пользовательский интерфейс

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

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

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

1. Всегда ли элементы управления видны и / или включены? При каких условиях меняются их состояния?
2. Похоже на растровое изображение — это кнопка?
3. Какие переходы происходят между этими состояниями и представлениями? А как их анимировать?

Если вам нужно сгенерировать пользовательский интерфейс для согласования клиента, сделайте то же самое в обратном порядке: используйте инструмент каркаса и создайте полный набор макетов экрана, включая любые варианты, которые представления отображаются в разных состояниях приложения. Это может быть исчерпывающая и утомительная работа, но вы не пожалеете об этом — она ​​может избавить вас от переписывания огромных объемов кода и воссоздания интерфейсов из-за небольшого недоразумения с серьезными последствиями. Если вы создаете двойное приложение (например, для iPhone и iPad), создайте отдельные каркасы для обоих.

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

Если ваш клиент поставляет вам графику, убедитесь, что у нее правильный размер и правильное соотношение сторон; преобразование любого растрового изображения, содержащего текст или объекты (например, круги), приведет к искажениям. Если они не совпадают, попросите клиента воссоздать их с соответствующими размерами. Не думайте, что вы можете растянуть экран-заставку размером 3,5 дюйма до заставки размером 4 дюйма и просто кататься вместе с ним.

Функциональность

Ключевые вопросы, которые следует задать в проектном документе приложения:

• Что делает приложение и как быстро оно это делает?
• Каковы возможные состояния отказа и как они обрабатываются?
• Какие разовые операции выполняются при первом выполнении (т.е., после установки)?
• Если пользователь создает какие-либо записи (например, закладки), каковы ограничения?

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

Вехи

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

Пример спецификации проектирования программного обеспечения

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

Заявление о целях

Включите короткий абзац с описанием проекта и его целевой аудитории.

Функциональное описание

Что делает приложение ? С какими состояниями приложения (высокоуровневыми описаниями основных пользовательских сценариев) столкнется пользователь?

Например, ваше функциональное описание может выглядеть так:

• Первый запуск
• Создание нового _____ (игра, поиск и т. Д.)
• Операции
• Поведение фона и переднего плана

Пользовательский интерфейс

Включите каркасы для каждой страницы с подробным описанием:

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

Вот макеты, относящиеся к моему последнему приложению для iOS, NotifEye:

Если вам интересно, я сделал эти макеты с помощью инструмента каркасного моделирования Balsamiq.

Например, описание вашего пользовательского интерфейса может выглядеть так:

• Панель навигации
  • Левый элемент управления: возврат на главную страницу
  • Строка заголовка: текущий экран или название операции
  • Новая кнопка: создать новую вещь
• Просмотр таблицы
  • Раздел 0: Название раздела
  • Секция 0 рядов:
    • Контроль ряда 0 (e.г., изображение)
    • Текстовая строка 0
    • Текстовая строка 2

Вехи

Как описано выше, сроки завершения и ожидаемые результаты.

Например, раздел этапов в шаблоне проектного документа может выглядеть так:

1. Фасадное приложение с изображением экрана и с временными переходами и примерами изображений / текста
2. Протокол связи: приложение подключается к сети / серверу
3. Функциональная веха 1:…
4. Alpha Application (с полной функциональностью)
5. Устойчивость
6. Версия

Убедитесь, что документация по программному обеспечению остается актуальной

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

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

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

1. Над чем только что работал разработчик?
2. Над чем сейчас работает разработчик?
3. Над чем разработчик будет работать дальше?

Как создать дизайн-документ ?.Когда вы думаете о дизайне, слово… | Джон Сайто | Dropbox Design

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

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

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

Когда все сделано хорошо, хороший дизайнерский документ может:

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

В Dropbox мы делаем дизайн-документацию для каждого проекта. Все проекты должны с чего-то начинаться, и для нас это часто начинается с документа Dropbox Paper.

Но как создать проектную документацию? Я попросил нескольких дизайнеров из нашей команды дать советы по созданию документации. Вот что я у них почерпнул.

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

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

Индекс связывает все это

Допустим, ее проектный документ называется « Project Popup [Design] ». Техническая документация и копия документа будут следовать аналогичному шаблону именования: « Project Popup [Eng] » и « Project Popup [Copy] ».

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

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

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

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

Emoji — это не только для украшения

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

А, вот и мой документ!

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

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

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

Документирование хорошего и плохого в документе аудита

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

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

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

Чтобы сделать вещи более интересными, Лаура также приправляет вещи несколькими отсылками к поп-культуре здесь и там.

Рассказ помогает сделать ваш дизайн более убедительным.

Лаура использует подобные истории, чтобы объяснить свой дизайн. Это не о пользователе А с проблемой X. Это о человеке в реальной ситуации с реальными проблемами. Рассказ помогает сделать проблему и решение более убедительными.

«Документы могут помочь людям увлечься идеей», — говорит мне Рихан Хасан.

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

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

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

Фотографии, разговоры в чате и зарисовки помогают рассказать историю.

«Легче набрать обороты, если другим это нравится», — говорит Рихан.С помощью визуальных артефактов эти большие плавающие идеи кажутся намного более конкретными и убедительными.

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

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

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

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

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

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

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

The Design Graveyard — где упокоятся некоторые из ваших лучших идей.

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

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

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

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

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

Заставьте одного человека просмотреть ваш документ раньше всех.

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

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

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

А если вы хотите пообщаться с дизайнерами, упомянутыми выше, вы можете найти их здесь:

Документирование процесса проектирования | Проектирование машин

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

Блокноты для дизайна

При решении любой проблемы проектирования важно, чтобы инженеры отслеживали разработанные идеи и принятые решения в блокноте для проектирования. Некоторые компании требуют, чтобы инженеры обслуживали их, причем каждая запись была подписана и датирована в юридических целях.Затем, если патент заявлен или защищен от нарушения, будет полная документация о рождении и развитии идеи. Записная книжка с последовательно пронумерованными, подписанными и датированными страницами считается хорошей документацией; случайные кусочки информации, нацарапанные на клочках бумаги, — нет. У успешных инженеров, таких как Томас Эдисон, есть хорошие дизайнерские блокноты.

Страница из дизайнерской записной книжки Томаса Эдисона.

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

• Дизайнерский блокнот — это дневник дизайна. Он не обязательно должен быть аккуратным, но он должен содержать все эскизы, заметки и расчеты, касающиеся дизайна. Итак, еще до того, как приступить к проектированию:
• Приготовьте тетрадь в переплете, желательно с линованной бумагой с одной стороны и миллиметровой бумагой с другой.
• Первой записью в записной книжке должно быть ваше имя, название вашей компании и название проблемы.
• Вторая запись должна быть постановкой задачи, так как она известна.
• Каждая следующая страница должна быть пронумерована, датирована и подписана.
• Если тестовые записи, компьютерные данные и другая информация слишком объемны для вырезания и вставки в записную книжку, введите примечание, указав, что это за документ и где он хранится.

Обзоры дизайна

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

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

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

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

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

Отчеты о проектировании

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

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

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

1. Представьте всю концепцию или сборку и объясните ее общую функцию.
2. Опишите основные части и их отношение к целому и его функции.
3. Свяжите части вместе в одно целое.

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

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

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

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

Титульный лист

Дата

Руководитель группы

Члены команды

Краткое содержание

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

Оглавление: Включить заголовки разделов и номера страниц

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

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

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

1. Предположения сделаны, убедившись в обосновании проектных решений.
2. Функция системы.
3. Соответствие технической документации.
4. Prototypes разработали свои испытания и результаты относительно технических требований.
5. Анализ затрат.
6. Используемые производственные процессы.
7. результатов DFX.
8. С учетом человеческого фактора.
9. Все диаграммы, таблицы и рисунки должны быть точно и четко помечены значимыми именами и / или заголовками.

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

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

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

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

Безопасность: Укажите соответствующие соображения безопасности в предлагаемой конструкции.

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

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

Ссылки: Включите книги, технические журналы и патенты.

Приложения: Необходимы для следующей информации:

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

Эта статья основана на отрывке из книги Дэвида Ульмана «Процесс механического проектирования» (6-е изд.), 2018 г. (www.mechdesignprocess.com).

Как написать хороший проект программного обеспечения doc

Анжелы Чжан

Фото Эсте Янссенс на Unsplash

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

Эта статья — моя попытка описать , что делает дизайн-документ отличным .

Статья разбита на 4 раздела:

• Зачем написать дизайн-документ
• Что включить в дизайн-документ
• Как написать
• Процесс вокруг него

Зачем писать дизайн-документ?

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

Уже есть много статей о том, почему так важно написать проектную документацию, прежде чем погрузиться в кодирование. Итак, все, что я скажу:

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

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

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

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

Фото Тодда Квакенбуша на Unsplash

Что включить в проектную документацию?

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

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

Заголовок и люди

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

Обзор

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

Контекст

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

Цели и нецели

Раздел Цели должен:

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

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

Вехи

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

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

Дата начала: 7 июня 2018 г.
Этап 1 - MVP новой системы, работающий в темном режиме: 28 июня 2018 г.
Этап 2 - Отказ от старой системы: 4 июля 2018 г.
Дата окончания: добавление функции X, Y, Z в новую систему: 14 июля 2018 г.

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

Существующее решение

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

Пользователь история — отличный способ сформулировать это. Имейте в виду, что в вашей системе могут быть разные типы пользователей с разными вариантами использования.

Предлагаемое решение

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

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

Альтернативные решения

Что еще вы учитывали, когда предлагали решение, описанное выше? Каковы плюсы и минусы альтернатив? Думали ли вы о покупке стороннего решения — или использовании решения с открытым исходным кодом — которое решает эту проблему, а не о создании собственного?

Тестируемость, мониторинг и оповещение

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

Cross-Team Impact

Как это увеличит нагрузку на вызовы и команду разработчиков?
Сколько это будет стоить?
Вызывает ли это уменьшение задержки в системе?
Есть ли уязвимости в системе безопасности?
Каковы негативные последствия и побочные эффекты?
Как служба поддержки может сообщить об этом клиентам?

Открытые вопросы

Любые открытые вопросы, в которых вы не уверены, спорные решения, которые вы хотели бы принять во внимание читателями, предлагаемые будущие работы и т. Д.Ироничное название этого раздела — «известные неизвестные».

Подробное определение объема и графика

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

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

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

Фото rawpixel на Unsplash

Как это написать

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

Пишите как можно проще

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

• Простые слова
• Короткие предложения
• Маркированные списки и / или нумерованные списки
• Конкретные примеры, такие как «Пользователь Алиса подключает свой банковский счет, затем…»

Добавьте много диаграмм и диаграммы

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

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

Включите номеров

Масштаб проблемы часто определяет решение. Чтобы помочь рецензентам получить представление о состоянии мира, включите реальные числа, такие как количество строк БД, количество пользовательских ошибок, задержка — и то, как они масштабируются с использованием.Помните ваши обозначения Big-O?

Постарайтесь быть смешным

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

Если вам, как и мне, трудно быть смешным, у Джоэла Спольски (, очевидно, , известного своими комедийными талантами…) есть этот совет:

Один из самых простых способов быть смешным — это быть конкретным , когда он не называется для [… Пример:] Вместо того, чтобы говорить «особые интересы», скажите «леворукие фермеры, выращивающие авакадо».

Пройдите скептический тест

Перед тем, как послать свой проектный документ на рассмотрение другим, пройдите его, выдав себя за рецензента. Какие вопросы и сомнения могут возникнуть по поводу этого дизайна? Тогда обращайтесь к ним заранее.

Пройдите тест на отпуск

Если вы сейчас уезжаете в длительный отпуск без доступа к Интернету, может ли кто-нибудь из вашей команды прочитать документ и реализовать его так, как вы планировали?

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

Фото SpaceX на Unsplash

Process

Ах да, ужасное P-word . Документация по дизайну поможет вам получить обратную связь, прежде чем тратить кучу времени на внедрение неправильного решения или решения неправильной проблемы. Получить хорошие отзывы — это искусство, но об этом позже. А пока давайте поговорим конкретно о том, как написать проектную документацию и получить по ней отзывы.

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

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

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

1. Попросите опытного инженера или технического руководителя вашей команды выступить в роли рецензента. В идеале это должен быть человек, которого уважают и / или знакомы с крайними случаями проблемы.При необходимости подкупите их бобой.
2. Зайдите в конференц-зал с доской.
3. Опишите проблему , которую вы решаете, этому инженеру (это очень важный шаг, не пропускайте его!).
4. Затем объясните реализацию , которую вы имеете в виду, и убедите их, что это правильный вариант.

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

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

В связи с этим рассмотрите возможность добавления специализированных проверяющих (таких как SRE и инженеры по безопасности) для конкретных аспектов проекта.

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

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

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

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

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

Наконец, давайте на секунду возьмем на самом деле мета: как мы оцениваем успех проектной документации?

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

1. Вы тратите 5 дней на написание проектной документации, это заставляет вас продумать различные части технической архитектуры
2. Вы получаете отзывы от рецензентов, что X — самая рискованная часть предлагаемой архитектуры.
3. Вы решаете сначала реализовать X , чтобы снизить риски проекта.
4. Через 3 дня вы понимаете, что X либо невозможно, либо намного сложнее, чем вы изначально Предполагаемый
5. Вы решили прекратить работу над этим проектом и вместо этого назначить приоритет другим

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

Пожалуйста, оставьте комментарий ниже, если у вас есть вопросы или отзывы! Я также хотел бы услышать о том, как вы по-другому разрабатываете документацию в своей команде.

Отдавая должное там, где полагается заслуга, я многому научился из вышеперечисленного, работая вместе с примерно невероятными инженерами в Plaid (мы нанимаем! Приходите проектировать и строить вместе с нами какие-то прекрасные технические системы) и Quora.

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

Проектная документация | Packt Hub

(Дополнительные ресурсы, связанные с этой темой, см. Здесь. )

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

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

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

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

• Архитектурное проектирование
• План реализации
• Руководство по установке
• План проверочных испытаний
• Операционные процедуры

Эта информация может быть включена в один документ или разделена на разные документы.

VMware предоставляет партнерам VMware комплекты для предоставления услуг. Эти комплекты можно найти на портале VMware Partner University по адресу http: // www.vmware.com/go/partneruniversity, где представлены шаблоны документации, которые можно использовать в качестве основы для создания проектных документов. Если у вас нет доступа к этим шаблонам, в этой статье приведены примеры схем, которые помогут вам в разработке собственных шаблонов проектной документации.

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

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

Отличным примером архитектурного документа является статья Cloud Infrastructure Architecture Case Study White Paper , которую можно найти по адресу http://www. vmware.com/files/pdf/techpaper/cloud-infrastructure-achitecture-case -study.pdf.

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

Как это сделать…

Архитектурный проектный документ должен включать следующую информацию:

• Назначение и обзор
  • Краткое содержание
  • Методология проектирования
• Концептуальный проект
• Логическое управление, хранилище, вычисления и проектирование сети
• Физическое управление, хранилище, вычисления и проектирование сети

Как это работает…

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

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

Краткое описание: Эта архитектура была разработана для поддержки проекта виртуализации по консолидации 100 существующих физических серверов в VMware vSphere 5.x виртуальная инфраструктура. Основные цели, которые решает эта конструкция, — повышение операционной эффективности и обеспечение высокой доступности приложений, ориентированных на клиентов.

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

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

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

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

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

ID	Требование
R001	Объединение существующих 100 физических серверов приложений до пяти серверов
R002	Обеспечение емкости для поддержки роста 25 дополнительных серверов приложений в течение следующих пяти лет
R003	Обслуживание оборудования сервера не должно влиять на время безотказной работы приложений
R004	Обеспечивает резервирование N + 2 для поддержки аппаратных сбоев во время обычных операций и операций по техническому обслуживанию

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

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

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

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

Параметр	Параметры
Текущие требуемые ресурсы ЦП	100 ГГц
* Рост ЦП	25 ГГц
Требуется ЦП (загрузка 75%)	157 ГГц
Текущие требуемые ресурсы памяти	525 ГБ
* Увеличение памяти	131 ГБ
Требуется память (использование 75%)	821 ГБ
Требуется память (экономия 25% TPS)	616 ГБ
* Увеличение ЦП и памяти 25 дополнительных серверов приложений (R002)

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

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

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

• Титульная страница : включает имена клиентов и проектов
• Журнал версий документа : содержит журнал авторов и изменений, внесенных в документ
• Контактная информация для документа : Включает экспертов в предметной области, участвовавших в создании дизайна
• Содержание : Это указатель разделов документа для быстрой справки
• Список таблиц : Это указатель таблиц, включенных в документ для быстрой справки
• Список цифр : Это указатель цифр, включенных в документ для быстрой справки
• Цель и обзор : Этот раздел состоит из резюме, чтобы предоставить обзор проекта и методологии проектирования, использованной при создании дизайна
• Концептуальный проект : Документация факторов проектирования: требований, ограничений и допущений
• Логический дизайн : Он содержит подробную информацию о логическом управлении, хранилище, сети и вычислительном дизайне
• Физическая конструкция : Содержит подробную информацию о выбранном оборудовании и конфигурации физического и виртуального оборудования

План реализации документирует требования, необходимые для завершения реализации проекта.

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

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

Как это сделать…

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

• Заявление о целях
• Контакты проекта
• Требования к реализации
• Обзор этапов внедрения
• Определение результатов проектной документации
• Внедрение управления изменениями

Как это работает…

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

Ниже приводится пример заявления о цели:

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

Объем этого документа относится к реализации реализации виртуального центра обработки данных и вспомогательных компонентов, определенных в Архитектурном проекте.

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

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

Роль	Имя	Контактная информация
Заказчик Спонсор проекта
Технический ресурс заказчика
Руководитель проекта
Архитектор-проектировщик
Инженер по внедрению
Инженер по контролю качества

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

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

Требования к доступу включают следующее:

• Физический доступ к сайту.
• Учетные данные, необходимые для доступа к ресурсам. К ним относятся учетные данные активного каталога и учетные данные VPN (если требуется удаленный доступ).

Требования к объекту включают следующее:

• Электропитание и охлаждение для поддержки оборудования, которое будет развернуто в рамках проекта
• Требования к месту в стойке

Требования к оборудованию, программному обеспечению и лицензированию включают следующее:

• Лицензирование vSphere
• Лицензирование Windows или другой операционной системы
• Лицензирование других сторонних приложений
• Программное обеспечение (ISO, физические носители и т. Д.)
• Физическое оборудование (хосты, массив, сетевые коммутаторы, кабели и т. Д.)

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

1. Приобретение оборудования, программного обеспечения и лицензирование.
2. Планирование инженерных ресурсов.
3. Проверка доступа и требований к объектам.
4. Проведение инвентаризации необходимого оборудования, программного обеспечения и лицензий.
5. Установка и настройка массива хранения.
6. Стойка, кабель и прогорание физического серверного оборудования.
7. Установка ESXi на физических серверах.
8. Установка vCenter Server.
9. Конфигурация ESXi и vCenter.
10. Тестирование и проверка плана внедрения.
11. Миграция физических нагрузок на виртуальные машины.
12. Оперативная проверка выполнения плана реализации.

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

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

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

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

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

Ниже приведен пример плана реализации:

• Титульная страница : включает имена клиентов и проектов
• Журнал версий документа : содержит журнал авторов и изменений, внесенных в документ
• Контактная информация для документа : Включает экспертов в предметной области, участвовавших в создании дизайна
• Оглавление : Это указатель разделов документа для быстрой справки
• Список таблиц : Это указатель таблиц, включенных в документ для быстрой справки
• Список цифр : Это указатель цифр, включенных в документ для быстрой справки
• Заявление о целях : Определяет цель документа
• Контакты проекта : это документация основных контактных лиц проекта
• Требования к реализации : Обеспечивает доступ, средства, оборудование, программное обеспечение и лицензию, необходимые для завершения реализации
• Обзор реализации : это обзор шагов, необходимых для завершения реализации
• Результаты проекта : Он состоит из документов, которые будут предоставлены в качестве результатов после завершения реализации

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

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

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

Как это сделать…

Руководство по установке должно включать следующую информацию:

• Заявление о целях
• Заявление о допущении
• Пошаговая инструкция по реализации дизайна

Как это работает…

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

Ниже приводится пример заявления об основной цели и предположении, которое можно использовать для руководства по установке:

Цель: этот документ предоставляет руководство по установке и настройке проекта виртуальной инфраструктуры, определенного в проекте архитектуры.

Допущения: Это руководство написано для инженера по внедрению или администратора, знакомого с концепциями и терминологией vSphere. Руководство не предназначено для администраторов, не знакомых с концепциями и терминологией vSphere .

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

• Конфигурации массива хранения
• Физические конфигурации сети
• Конфигурации физического хоста
• Установка ESXi
• Установка и настройка vCenter Server
• Конфигурация виртуальной сети
• Конфигурация хранилища данных
• Высокая доступность, планировщик распределенных ресурсов, хранилище DRS и установка и настройка других компонентов vSphere

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

На следующем снимке экрана показан пример из руководства по установке, в котором подробно описывается включение и настройка программного адаптера iSCSI:

Ниже приводится пример схемы руководства по установке:

• Титульная страница : включает имена клиентов и проектов
• Журнал версий документа : содержит журнал авторов и изменений, внесенных в документ
• Контактная информация для документа : Включает экспертов в предметной области, участвовавших в создании дизайна
• Оглавление : Это указатель разделов документа для быстрой справки
• Список таблиц : Это указатель таблиц, включенных в документ для быстрой справки
• Список цифр : Это указатель цифр, включенных в документ для быстрой справки
• Заявление о целях : Определяет цель документа
• Заявление о допущениях : определяет любые допущения, сделанные при создании документа
• Руководство по установке : В нем представлены пошаговые инструкции по установке, которым необходимо следовать при реализации проекта

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

Как это сделать…

План проверочного тестирования должен включать следующую информацию:

• Заявление о целях
• Заявление о допущении
• Критерии успеха
• Процедуры испытаний

Как это работает…

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

Ниже приводится пример заявления о целях и предположениях для плана валидационного тестирования:

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

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

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

В следующей таблице приведены некоторые примеры критериев успеха, определенных в плане проверки:

Описание	Измерение
Члены активной группы каталогов администраторы vSphere могут получить доступ к vCenter как администраторы	Да / Нет
Доступ запрещен для пользователей, не входящих в группу активных каталогов администраторов vSphere	Да / Нет
Доступ к хосту с помощью клиента vSphere разрешен, если режим блокировки отключен	Да / Нет
Доступ к хосту с помощью клиента vSphere запрещен, если включен режим блокировки	Да / Нет
Использование ресурсов кластера менее 75 процентов.	Да / Нет

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

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

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

Описание теста	Задачи на выполнение теста	Ожидаемый результат
Доступ администратора vCenter	Используйте vSphere Web Client для доступа к vCenter Server.Войдите в систему как пользователь, который является членом группы AD администраторов vSphere.	Доступ администратора к инвентаризации vCenter Server
Доступ к vCenter: нет разрешений	Используйте vSphere Web Client для доступа к vCenter Server. Войдите в систему как пользователь, который не является членом группы AD администраторов vSphere.	В доступе отказано
Доступ к хосту: режим блокировки отключен	Отключить режим блокировки через DCUI.Используйте vSphere Client для доступа к хосту и войдите в систему как root.	Прямой доступ к хосту с помощью клиента vSphere выполнен успешно
Доступ к хосту: включен режим блокировки	Повторно включите режим блокировки через DCUI. Используйте vSphere Client для доступа к хосту и войдите в систему как root.	Прямой доступ к хосту с помощью клиента vSphere запрещен

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

Описание теста	Задачи на выполнение теста	Ожидаемый результат
Сбой пути к хранилищу хоста	Отключите vmnic, обеспечивающий подключение к системе хранения IP от хоста	Отключенный путь не работает, но операции ввода-вывода продолжают обрабатываться на оставшихся путях.Должен быть активирован сигнал о подключении к сети, и на настроенный адрес электронной почты должно быть отправлено электронное письмо.
Восстановление пути к хранилищу хоста	Повторно подключите vmnic, обеспечивая подключение к IP-хранилищу	Неисправный путь должен стать активным и начать обработку ввода-вывода. Тревоги подключения к сети должны исчезнуть.
Сбой пути хранения массива	Отключить одно сетевое соединение от активного SP	Отключенные пути не работают на всех хостах, но операции ввода-вывода продолжают обрабатываться на оставшихся путях.
Резервирование сети управления	Отключить активное управление сетью vmnic	Дежурный адаптер становится активным. Управляющий доступ к хосту не прерывается. Должен быть активирован сигнал тревоги потери сети избыточности, и электронное письмо должно быть отправлено на настроенный адрес электронной почты.

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

Ниже приведен пример плана валидационного тестирования:

• Титульная страница : включает имена клиентов и проектов
• Журнал версий документа : содержит журнал авторов и изменений, внесенных в документ
• Контактная информация для документа : Включает экспертов в предметной области, участвовавших в создании дизайна
• Оглавление : Это указатель разделов документа для быстрой справки
• Список таблиц : Это указатель таблиц, включенных в документ для быстрой справки
• Список цифр : Это указатель цифр, включенных в документ для быстрой справки
• Заявление о целях : Определяет цель документа
• Заявление о допущениях : определяет любые допущения, сделанные при создании документа
• Критерии успеха : Это список критериев, которые должны быть соблюдены для подтверждения успешной реализации проекта
• Процедуры тестирования : Это список процедур тестирования, которым необходимо следовать, включая шаги, которые необходимо выполнить, и ожидаемые результаты

Как написать проектную документацию по программному обеспечению (SDD)

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

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

Что такое проектный документ программного обеспечения?

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

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

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

Зачем писать проектную документацию по программному обеспечению?

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

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

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

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

Если вы работаете в качестве разработчика-фрилансера, проектный документ может также избавить вас от многих проблем в будущем, помогая избежать потенциальных разногласий с вашими клиентами и добавляя ясности к согласованным целям.«Без этого документа вы попадете в петлю язвительной двусмысленности, клиенты будут оспаривать то, что они вам сказали или что вы им сказали, сердито присылают вырезки из предыдущих сообщений, интерпретируют и спорят до тех пор, пока не придет время, когда клиент требует, чтобы вы внесли изменения », — предупреждает Кристофер Дж. Фокс, внештатный инженер-программист с более чем 30-летним опытом.

Структура документа по разработке программного обеспечения

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

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

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

Обзор и заинтересованные стороны

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

Контекст и цели

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

Предлагаемое решение

Конкретное подробное предложение по новой технической архитектуре.

Временная шкала

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

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

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

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

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

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

Существует множество инструментов для совместной работы с документами, которые могут облегчить такие рабочие процессы, включая Nuclino.«Важно, чтобы члены вашей команды могли комментировать документ и указывать на ошибки и упущения», — сказал Дэвид «Талин» Джойнер, программист игр и бывший разработчик программного обеспечения в Google+.

Сделайте это наглядным с помощью диаграмм и диаграмм

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

Будьте внимательны

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

Не пишите это в Word

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

Идеальный инструмент для написания SDD — открытый, совместный и организованный — Nuclino стремится быть таким инструментом. Сохраняйте документы по дизайну легкодоступными для всех заинтересованных сторон, храня их на своем общем диске или в своей внутренней базе знаний, чтобы их было легко найти и найти.

Не делайте его слишком длинным или сложным

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

«Не позволяйте своему желанию показать, насколько вы умны, не отвлекает вас», — рекомендует Джоунер.

Не позволяйте этому устаревать

“ Дизайн будет развиваться, и изменения должны быть отражены в вашем документе .За мой 25-летний опыт работы я ни разу не работал над проектом, где бы этого не происходило. Даже тогда я создал проектный документ с подробными спецификациями и при необходимости скорректировал его », — пояснил Кристофер Дж. Фокс, бывший старший инженер Microsoft и RealNetworks.

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

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

Nuclino: единый источник истины для вашей команды

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

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

• Общайтесь с помощью вдумчивых подробных рецензий и тратите меньше времени на душераздирающие встречи и хаотичные каналы Slack.

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

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

Попробовать

PMG | Этап проектирования

Этап проектирования

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

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

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

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

Менеджер проекта : Менеджер проекта несет ответственность за успешное выполнение этапа проектирования. Менеджер проекта несет ответственность за руководство командой, которая выполняет этапы деятельности и результаты.

Интегрированная группа проекта : Члены Интегрированной группы проекта (независимо от организации постоянного назначения) несут ответственность за выполнение поставленных задач в соответствии с указаниями Менеджера проекта.

Сотрудник по контрактам : Сотрудник по контрактам отвечает и подотчетен за подготовку тендерной документации под руководством Менеджера проекта.

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

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

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

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

• Бюджет: Гарантия того, что бюджет достаточен для удовлетворения потребностей проекта. Определите, определены ли бизнес-риски проекта и разработаны ли планы по их снижению.

• Финансы: Гарантия того, что оценки проектных расходов были обновлены для отражения фактических затрат и оценок будущих этапов.Определите, определены ли бизнес-риски проекта и разработаны ли планы по их снижению.

• HR: Подтвердите, что вопросы, связанные с персоналом, персоналом или другими областями управления персоналом, были решены.

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

• CPIC: Убедитесь, что проект полностью задокументирован.

• Показатели: Определите, определены ли технические риски проекта и разработаны ли планы по их снижению. Убедитесь, что цели производительности согласованы.

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

Мероприятия
Следующие задачи выполняются на этапе проектирования.

Проектная документация разрабатывается менеджером проекта и Интегрированной командой проекта, определяя этапы, используемые при разработке приложения / системы. Предпосылками для этого этапа являются бизнес-обоснование, план управления проектом и документ с требованиями. Менеджер проекта и интегрированная проектная группа определяют / определяют целевую среду, среду разработки и среду проектирования.Формулируются бизнес-организация, роли и процедуры для разработки этой системы / приложения. Проектный документ является результатом этапа проектирования. Документы предыдущих этапов при необходимости пересматриваются на этапе проектирования.

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

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

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

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

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

Критерии выхода для конкретных фаз:

• Нет нерешенных проблем среди заинтересованных сторон относительно адекватности или осуществимости проекта.

• Дизайн должным образом задокументирован, чтобы обеспечить эффективное и действенное развитие.

• Планы

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

• Security Documents максимально полны и точны.

Общие критерии выхода:

• Выявлены и устранены отклонения от исходных условий. [Выявлены отклонения в стоимости и расписании и изменения объема, существенные отклонения объяснены, и при необходимости подготовлены планы корректирующих действий (CAP) или запросы на изменение базового уровня.]

• Базовые инвестиционные планы были пересмотрены и, при необходимости, скорректированы. [Следует ли продолжать это вложение, изменить или прекратить на основании текущих знаний?]

• План управления проектом и планы компонентов были пересмотрены и соответствующим образом обновлены.[Это включает управление рисками, стратегию приобретения, управление изменениями, управление конфигурацией, категоризацию проекта, управление требованиями, план коммуникаций, WBS / расписание, планирование IV&V, обеспечение качества, управление записями, план развития персонала и подход к обеспечению безопасности.]

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

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

• Проектные решения в масштабах всей системы или подсистемы.

• Архитектурный проект программной системы или подсистемы.

• Программные проектные решения.

• Архитектурный проект программного продукта.

Детальный дизайн элемента программного обеспечения или его части (например, базы данных).

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

No related posts.