Деятельность организованной команды по управлению проектом - это система действий, объединенных общей целью и направленных на предметную область проекта 1 . Видение перспективы проекта является тем фундаментом, на котором строят свои подходы к проекту не только его руководитель, но и члены команды проекта, а так-же другие участники проекта. Это картина того состояния проекта, которое может быть достигнуто в отдаленном будущем при самых благоприятных обстоятельствах и к которому устремлены чаяния его участников. Видение, как правило, представляет собой результат мысленного движения от известного к неизвестному, создание будущего путем монтажа известных фактов, надежд, мечтаний с учетом опасностей и возможностей.
Руководитель проекта должен иметь ясное видение перспективы проекта, а также решимость, лидерские и профессиональные навыки, творческие способности для того, чтобы вести вперед команду и персонал проекта, к реализации видения. Формулирование видения позволяет изложить подходы в ясной и лаконичной форме. Содержание видения - это письменное изложение взглядов на ключевые элементы выбранной стратегии 2 .
Миссия проекта
Роль миссии заключается в том, чтобы ориентировать в едином направлении людей, которые воспринимают проект извне и изнутри. В широком понимании миссия - это философия, предназначение, смысл существования проекта.
Философия проекта меняется редко и определяет ценности, убеждения и принципы, в соответствии с которыми участники проекта намереваются осуществлять свою деятельность.
Предназначение определяет действия, которые участники проекта намереваются осуществлять, и может меняться в зависимости от глубины возможных изменений в проекте и окружающей его среде.
Смысл существования проекта заключается в том, чтобы как можно более полно удовлетворить нужды и ожидания потребителя результата проекта, хорошо сбалансировав при этом интересы участников проекта и общественные интересы.
Принципиальная разница между видением и миссией заключается в том, что видение - это идеальная «картинка» будущего положения дел, к которому стремятся участники проекта, а миссия раскрывает образ действия.
Миссия в большей или меньшей мере должна отражать интересы участников проекта, а также субъектов, составляющих его ближнее и дальнее окружение, поэтому вырабатывается с учетом:
существующего стиля поведения и способа действия участников проекта;
ресурсов, которые можно привести в действие для достижения поставленных целей;
состояния внешней среды проекта;
отличительных особенностей конкретного проекта.
Миссия организации, как сформулированное утверждение вырабатывается участниками проекта, которые наделены правом принимать решения. Обычно миссия формулируется в двух вариантах. Короткий вариант миссии представляет собой два-три предложения - брендовый слоган проекта, направленный на создание вполне определенного имиджа проекта (например, честность и открытость, работа в единой команде, свободный обмен информацией).
Расширенный вариант миссии разрабатывается для внутреннего использования и должен подробно раскрывать все необходимые аспекты миссии такие, как целевые ориентиры, философия, возможности и способы реализации проекта, его результаты и тому подобное.
Миссия становится действенной только тогда, когда участники проекта внутренне согласны с ней и следуют в своей деятельности ее положениям. Поэтому очень важно, чтобы миссия формулировалась предельно ясно и понятно всем участникам проекта; исключала возможность неоднозначного толкования; оставляла простор для творческого и гибкого развития мысли; не содержала в себе конкретных указаний относительно того, что, как и в какие сроки следует делать.
Содержание миссии не должно зависеть от текущего состояния дел, так как она выражает устремленность в будущее, показывая, куда будут направлены усилия и какие ценности будут приоритетными. Так, не принято указывать в качестве главной цели проекта получение прибыли. Правильно определенная миссия, хотя и имеет всегда общий философский смысл, обязательно несет в себе что-то, что делает конкретный проект уникальным.
Предполагает определение тех ключевых качественных и количественных показателей, которых проект позволит достичь в будущем. Стратегическое видение позволяет искать и находить ответы на вопрос «Что изменится, когда проект будет завершен?» Кроме того, видение помогает субъектам внешней среды (партнерам, контрагентам и др.) оценивать намерения проектной организации относительно ее дальнейших действий и поведения в деловой среде, а также прогнозировать перспективы развития взаимоотношений и формировать требования к ответственности за принимаемые решения.
Миссию, видение и стратегические цели проекта рекомендуется разрабатывать на основе SWOT-анализа:
Strong - сила (преимущества, придающие дополнительные возможности, конкурентную привлекательность проекту);
Weak - слабость (отсутствие чего-то важного для функционирования проекта, то, что не удается в сравнении с другими или ставящее в неблагоприятные условия);
Opportunity - возможности (благоприятные условия, дающие шанс сделать что-то новое: создать новый продукт, услугу, внедрить новую технологию и т. п.);
Trouble - угрозы (то, что может нанести ущерб, лишить существенных преимуществ: риски, форсмажорные обстоятельства и др.)
Пример 2. Миссия Герценовского университета в программе стратегического развития на 2006-2010 гг.
«Миссия Герценовского университета в современных условиях, отражая основные ценности нового, характерного для начала третьего тысячелетия смысла университетского образования и лучшие традиции отечественного образования, ориентирует коллектив герценовцев на построение университета как пространства жизненного самоопределения Человека во всем многообразии его проявлений в современной культурной практике».
Еще по теме Видение проекта:
- ОСНОВЫ РАБОТЫ ПРОЕКТА ДОПОЛНИТЕЛЬНОГО ЭКОЛОГИЧЕСКОГО ОБРАЗОВАНИЯ"РЕЧНИКИ В ГАРМОНИИ С ПРИРОДОЙ"
- ОРГАНИЗАЦИОННО-СОДЕРЖАТЕЛЬНЫЕ АСПЕКТЫ РЕАЛИЗАЦИИ ПРОЕКТА "МОДЕЛЬ НЕПРЕРЫВНОГО ЭКОЛОГИЧЕСКОГО ОБРАЗОВАНИЯ И ВОСПИТАНИЯ НА ТЕРРИТОРИИ АСИНОВСКОГО РАЙОНА" В РАМКАХ ДОШКОЛЬНОГО УЧРЕЖДЕНИЯ
Формирование видения
Прототипирование
Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в лекции 10). Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
Метод RAD - один из наиболее известных способов быстро создавать прототипы 1) .
RAD базируется на следующих базовых принципах:
- Эволюционное прототипирование;
- CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
- Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
- Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
- Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.
Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в лекции 6, могут быть использованы и при формировании видения.
Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны - концепция, видение, образ, с другой - рамки, границы, контекст.
В первом случае речь идет о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем не ограниченным".
Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет - значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, "подняться над ситуацией", планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п.
Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно "увидеть" в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых методов и средств управления предприятием на основе информационных технологий зачастую приходится "перекраивать" существующие бизнес-процессы; по сути внедрение АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит к перестройке этих процессов с целью оптимизации деятельности предприятия, достижения ключевых факторов эффективности и пр.
Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не ограниченное видение", рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.
Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?
Зачастую Заказчик осознает необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова 1) автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по которым ходят коровы.
В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой". Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.
Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.
Некоторые аргументы за разделение видения и границ были приведены выше. Провести четкую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос "разделять или не разделять" определяется выбранной методологией.
Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.
10 марта 2011 в 18:46Как оценить задачу до начала разработки сайта
- Управление проектами
Постановка задачи - ключ к успеху любой работы. Если задача не поставлена чётко, то невозможно даже понять, решена ли она.
Мы предлагаем алгоритм оценки задачи до начала разработки сайта, неоднократно обкатанный и написанный кровью менеджеров. Мы уверены, что этот алгоритм сэкономит вам массу времени, денег и нервов.
Выясните, что нужно сделать
«А зачем вам нужен сайт? - Ээээ, ну как… Чтобы бизнес шёл лучше.»Вот что отвечает каждый второй клиент на самый простой, казалось бы, вопрос. Он должен знать ответ на него как «Отче наш», хоть средь ночи его разбуди. Но не тут-то было.
Перед тем, как начинать работу над сайтом, необходимо понять:
- Попадает ли задача в спектр ваших услуг;
- Интересно ли вам это;
- Сможете ли вы это сделать;
- Если ответ на первые три вопроса «Да», то сколько это будет стоить и сколько займёт времени.
Такая работа редко приносит удовольствие и прибыль. Из такой ситуации есть всего два эффективных выхода - отказаться от проекта или обучать клиента. Второй более конструктивный, но не всегда возможный.
Перед тем как разобраться, что такое видение и как его создать, мы рассмотрим два примера, как делать не надо - то есть примеры практики, широко распространённой в Рунете.
Не просите клиента выслать техническое задание
Ни в коем случае не просите у клиента сделать техническое задание. Обычно этим грешат фрилансеры-одиночки или начинающие студии.Представьте, что вы хотите построить дачу. Вы знаете, что вам нужен дом, вы можете примерно сказать, сколько комнат вы хотите иметь, какие постройки вы хотите видеть на участке. Вы приходите в компанию по строительству коттеджей, а менеджер этой компании говорит вам: «Нарисуйте мне, пожалуйста, подробный архитектурный проект, чертежи с коммуникациями и расcчитайте нагрузку на оборудование». Нормально? Абсурд!
Клиент по определению не должен писать вам никаких заданий, потому что:
- Он не компетентен в постановке задачи при создании сайта;
- Он не умеет и не должен уметь писать технические задания;
- Самое лучшее задание - то, которое вы сами для себя и напишете.
Не просите клиента заполнить анкету
Анкета - это уже, без сомнения, лучше просьбы выслать ТЗ. Хотя бы потому, что именно вы её готовили и, вероятно, думали над вопросами, которые она содержит. Однако, смеем вас заверить, результат анкетирования даёт вам не намного больше представления о задаче. Недостатки анкетирования довольно очевидны:- Клиенты очень разные, всех одинаковыми вопросами не обработаешь.
- При заполнении анкеты клиент остаётся наедине с самим собой: ему не у кого уточнить ваши вопросы, которые почти наверняка содержат непонятные термины. Сие неизбежно приводит к неправильным или неполным ответам.
- Вы не можете задать уточняющие вопросы, которые прояснят ответы клиента. А ведь именно уточняющие вопросы дают самую полезную информацию.
Личный разговор и никак иначе
Единственным по-настоящему сто́ящим способом понять клиента является интервью . В отличие от любого письменного задания, интервью даёт значительно бо́льшую свободу, позволяет лучше понять истинные цели клиента и выявить скрытые.Интервью обладает лишь одним «недостатком» - вы должны уметь разговаривать и выяснять потребности клиента. Полагаем, этот навык полезно освоить в любом случае. Зато интервью обладает следующими неоспоримыми преимуществами:
- Оно демонстрирует клиенту ваше трепетное отношение : вы готовы выслушать его, а не отбояриться анкетой; вы готовы к личному контакту; клиент для вас - индивидуальность, к нему не применимы анкеты (это и правда так).
- Интервью позволяет получить намного больше полезной информации благодаря тому, что вы, задавая основные вопросы, можете в любой момент уточнить их или задать дополнительные так, что клиент их поймёт и адекватно ответит.
- Интервью позволяет вам собрать вместе всех нужных людей со стороны клиента и получить полезную информацию из первых рук . Анкетирование, например, не даёт такой гарантии, потому как анкету могут вообще поручить заполнить секретарше, которая ни бельмеса не смыслит «что там нужно от сайта, только этого мне и не хватало...».
- В процессе интервью вы получаете информацию не только в виде текста, но и паравербально (см. статью ).
Что нужно выяснить у клиента
Прежде всего, мы рекомендуем выяснить следующие моменты:- Чем занимается клиент : в какой сфере он работает, какие товары или услуги предлагает.
- Зачем клиенту сайт: какие цели он ставит и как видит их достижение.
- Что клиент ожидает от сайта: как быстро сайт даст результаты, что изменится в работе и жизни клиента.
- Какие требования клиент предъявляет к сайту: обязательная информация, функции, с чем должен быть интегрирован. Это несколько повторяет предыдущий вопрос, но необходимо сделать акцент на том, что всё перечисленное является обязательным.
- Требуется ли что-то ещё кроме сайта : продвижение, брендинг, подготовка контента, обучение сотрудников.
- Какие материалы есть у клиента: фирменный стиль, тексты и иллюстрации, маркетинговые данные, необходимые для проектирования.
- Кто будет работать над проектом со стороны клиента: один или несколько человек, какой у него/них опыт в области создания сайтов. Кто является лицом, принимающим решения ?
- Как клиент видит себе рабочий процесс : какие формы общения предпочитает, сколько времени он сможет уделять проекту и как регулярно.
Подготовьте видение
Итак, вы пообщались с клиентом и получили нужные ответы - пора готовить видение . Сделаем небольшое отступление и заметим, что видение, помимо основной своей функции, также решает следующие задачи:- Показать свой высокий уровень работы, профессионализм .
- Согласовать точки зрения - вашу и клиента - на проект и, таким образом, вовлечь клиента в процесс.
- Натолкнуть клиента на мысли о дополнительных услугах . Причём совсем не обязательно, что вы просто втюхаете эти услуги - они вполне могут оказаться нужными в рамках проекта, просто клиент об этом не ведает ни сном, ни духом.
- Определить, готов ли клиент к проекту и какие ресурсы ему потребуются в процессе создания, обслуживания и развития проекта.
Информационный состав видения
Мы считаем, что видение должно содержать следующую информацию:- Цели проекта,
- Требования и пожелания клиента,
- Ожидания клиента,
- Концепция сайта,
- Что делаете вы в рамках проекта и что потребуется от клиента.
Заказчик:
DABCC.COM
Исполнитель:
Douglas Brown, Owner
Проект:
Развертывание Citrix® MetaFrame® Access Suite
Стадия проверки концепции проекта предназначена для определения возможностей продлагаемого развертывания MetaFrame Access Suite с точки зрения достижения видения проекта. В процессе проверки концепции создан прототип среды MetaFrame Access Suite вместе со всеми необходимыми приложениями, принтерами и т.п. Приложения были тщательно протестированы для проверки их работоспособности в терминальной среде MetaFrame XP/Terminal Server. По каждому пункту задокументированы результаты и внесены необходимые корректировки. Этот документ является итоговым отчетом по процедурам проверки концепции.
Этот документ разделен на следующие разделы:
- Спецификация среды
- Процедура создания среды
- Тесты
- Корректировки тестов
- Заключение
1. Спецификация среды
1.2. Аппаратное обеспечение
| Имя: DB2KCTX1 Модель: Compaq ML 530 Роль: Citrix MetaFrame XP Server |
| 48x CDROM, второй - под Compaq Internal DLT 20/40 Дисковый контроллер - Smart Array 4200 4-канальный контроллер RAID 5 |
| Имя: DB2KWEB1 Модель: Compaq ML 530 Роль: Web Interface Web Server |
| Form Factor – монтируемый в стойку Процессор – 2 х 933MHz, Pentium III Xeon, 256KB level 2-Advanced Transfer Cache. Память – 1 GB 133 MHz ECC SDRAM, расширяемая до 4GB с использованием модулей 512 MB Сетевой адаптер - NC3123 Fast Ethernet NIC PCI 10/100 controller Отсеки под диски – 4 отсека 5.25" для съемных дисков и один 1.44 MB флоппи-привод. Один использован под привод 48x CDROM, второй - под Compaq DLT 20/40 Дисковые накопители - всего 218.4 GB Maximum Internal Hot Plug Storage Ultra2. Установлены три диска 18.2 GB Hot Plug Ultra 3 Дисковый контроллер - Smart Array 5300 RAID ADG, настроен на RAID 5 Интерфейсы - один порт RJ-45 Ethernet, два последовательных, один параллельный, клавиатуры, мышь, видео, внешний SCSI |
1.3. Среда операционных систем
| Конфигурация домена | |
| Active Directory или NT Domain? | Active Directory |
| (NT Domains) Модель домена (Single domain, Master domain, Multiple-master, etc.): | - |
| (Active Directory) Режим (native / mixed)? | Native |
| (Active Directory) Имя дерева: | DABCC.COM |
| (Active Directory) Имя домена: | DABCC.COM |
| (Active Directory) Пространство имен DNS: | DABCC.COM |
| (Active Directory) Внутреннее пространство имен: | DABCC |
| Имена серверов DNS: | DB2KAD1, DB2KAD2 |
| Имена серверов WINS: | DB2KAD2 |
| Имя сервера DHCP: | DB2KAD2 |
| Адреса TCP/IP | |
| Укажите информацию об адресах IP вашей сети | |
| Network Address: | 192.168.1.0 |
| Subnet Mask: | 255.255.255.0 |
| Gateway: | 192.168.1.254 |
| Primary WINS: | 192.168.1.1 |
| Secondary WINS: | Нет |
| Primary DNS: | 192.168.1.1 |
| Secondary DNS: | 192.168.1.2 |
| Укажите адреса серверов, перечисленных в разделе "Аппаратная среда": | |
| DB2KAD1 | 192.168.1.5 |
| DB2KAD2 | 192.168.1.6 |
| DB2KFS1 | 192.168.1.71 |
| DB2KWEB1 | 192.168.1.8 |
| Укажите адреса IP сетевых принтеров | |
| HP 4M | 192.168.1.15 |
| HP 4000 | 192.168.1.16 |
| HP 4000 | 192.168.1.17 |
| HP LaserJet 4050 Color | 192.168.1.18 |
| HP OfficeJet 720 | 192.168.1.19 |
| Укажите диапазон DHCP: | |
| Диапазон DHCP: | с 192.168.1.100 по 92.168.1.200 |
| Список OU | |
| Наименование | Описание |
| Built-in | Default OU |
| Computers | OU для конечных пользователей |
| DABCC Users | OU для пользователей и групп DABCC.COM |
| Domain Controllers | OU для контроллеров домена Windows 2000 Active Directory. Включает в себя DB2KAD1 и DB2KAD2. |
| Foreign Security/Principles | Default OU |
| Servers | OU для серверов Windows NT/2000. Включает: DB2KFS1 и DB2KWEB1 |
| Users | OU по умолчанию для пользователей и групп Active Directory |
| Информация о групповых политиках (если есть) | |
| Используются политики WinNT или Win2000? | Win2000 |
| Размещение файлов политик | - |
| Пользователи и группы, затрагиваемые политиками | Administrators, Users |
1.4. Скрипты входа
| net use h: \dabcc\\dfsroot\users\%username% |
Logon_admins.cmd
| net use j: \dabcc\\dfsroot\applications net use k: \dabcc\\dfsroot\drivers net use o: \dabcc\\dfsroot\citrix net use p: \dabcc\\dfsroot\public |
1.5. Среда печати
| Имя принтера | Имя сервера печати | Драйвер |
| HP4M | DB2KFS1 | HP 4M |
| HP4000West | DB2KFS1 | HP 4000 |
| HP4000East | DB2KFS1 | HP 4000 |
| HPColor | DB2KFS1 | HP LaserJet 4050 Color |
| HPOfficeJet | DB2KFS1 | HP OfficeJet 720 |
1.6. Клиентская среда
2. Процедура создания среды
Сервер Citrix MetaFrame Access Suite и все другие серверы, использованные на этапе проверки концепции, настроены в сооветствии с методологией D&D Consulting, включая безопасность и оптимизацию сервера. Это делается на тот случай, если проверка концепции будет успешной, то среда сервера будет основой для промышленного внедрения MetaFrame Access Suite в промышленную среду.
Подробности относительно проектирования MetaFrame XP, MetaFrame Secure Access Manager, Web Interface или Secure Gateway см. в документации, предложенной D&D Consulting.
Ниже приведен основной список шагов по созданию сервера MetaFrame XP:
- Установка операционной системы сервера, последнего сервис-пака и хотфиксов
- Установка необходимых служб и удаление ненужных служб
- Настройка сетевой и доменной идентификации сервера
- Изменение службы SNMP так, чтобы сообщество “public” имело право"чтение и запись"
- Настройка всех сетевых адаптеров сервера на 100 Mbps и Full Duplex
- Настройка локальной безопасности на сервере Citrix
- Активация сервера лицензирования Terminal Services Licensing и клиентских лицензий TS CAL
- Инсталляция последнего Feature Release на Citrix MetaFrame XP и последнего сервис-пака
- Настройка лицензирования Citrix на сервере
- Установка Citrix Installation Manager (если требуется)
- Установка Citrix Resource Manager (если требуется)
- Настройка на сервере SpeedScreen
- Настрока соединений
- Настройка ICA Client Update Configuration
- Настройка на сервере оптимизации
- Иолирование сервера с использованием прав доступа NTFS и системных политик
- Настройка печати на сервере
- Установка и настройка приложений
- Настройка SpeedScreen для индивидуальных приложений
- Публикация приложений
- Создание диска аварийного восстановления
- Установка остальных компонентов (MetaFrame Conferencing Manager, Web Interface, Secure Gateway, и т.п.)
- Проверка сервера и приложений
2.2. Процедура инсталляции приложений
Напишите подробную инструкцию инсталляции каждого приложения, которое
будет проверяться на этапе проверки концепции.
3.0. Тесты
4.0 Корректировка тестов
5.0 Заключение
После анализа результатов тестирования и необходимых корректировок, D&D Consulting и DABCC.COM определили, что получены достаточные основания для продолжения изначально спланированного проекта.