Производство информационных систем. Часть 2. Формирование проектного решения

V РАЗРАБОТКА ПЛАНА-ГРАФИКА ПРОЕКТНЫХ РАБОТ

Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард

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

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

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

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

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

Рисунок 6. – Разработка плана-графика проекта

VI ФОРМИРОВАНИЕ ПРОЕКТНОГО РЕШЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Решение проектных задач часто заканчивается компромиссом: хочешь иметь преимущества — плати недостатками. Без этого практически не бывает.
Константин Феоктистов.

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

1. Уточнение и детализация требований

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

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

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

Подробно с моими рекомендациями по проведению этих работ можно ознакомиться в публикации Практика формирования требований в ИТ проектах от А до Я. Часть 3 — Часть 6 .

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

Рисунок 7. – Подготовка ТЗ и прочей документации для производстве информационной системы

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

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

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

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

В гибких методологиях (Agile) (1) один из важнейших принципов гласит: «Мы принимаем изменения в требования, даже на поздних этапах реализации проекта» и «Мы больше не заставляем расписываться заказчика кровью, ограничивая его жесткими и неудобными условиями договоров». В противовес этими принципам, обычно сразу же приводят «жестокую» модель Водопада (Waterfall), в которой предусматривается детальное проектирование и подробное документирование решения, обязательное перед началом производства информационной системы. Давайте обсудим этот момент.

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

1. У заказчика есть неограниченный финансовый кредит, и итоговая сумма проекта, при планировании разработки продукта, для него не имеет никакого значения. А при каждом новом изменении в ранее оговоренном решении, он например, достает толстую чековую книжку и выписывает новый чек.
2. Заказчик, заключив договор на определенную сумму, может ваять продукт путем проб и ошибок, пытаясь найти наилучшее для себя решение и заставляя исполнителей выкидывать и заново создавать модули и подсистемы, пока не устанет сам, или не разорится исполнитель.

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

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

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

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

Еще один принципом гибких методологий, с которым я не могу согласиться применительно к масштабным проектам звучит так: «Мы стали концентрироваться на продукте, вместо того чтобы писать изощренную проектную документацию, которую никто не читает». Ну для небольших проектов, допустим. Опять же, а те кто документирует процесс разработки продукта, они разве не сконцентрированы на продукте? Вообще-то они моделируют и документируют именно продукт. А что делать когда строится система, состоящая из десятков подсистем и модулей, разрабатываемых разными командами в разное время, да к тому же, взаимодействующая со сторонними системами? Как согласовать все это интерактивное общение между разнообразными компонентами? Например, варианты последовательностей выполнения цепочек событий и варианты ответных реакций на них? Неужели по комментариям в коде, написанном на разных языках? А прибавим сюда готовность менять требования на любом этапе, и что получаем? Пока Ваша команда реализовывала интерфейс взаимодействия своего модуля с другим, команда того другого уже поменяла требования и теперь не готова взаимодействовать с вами в старом формате. Какой же формат теперь актуален, узнать тяжело, по причине «сконцентрированности» команды на продукте и отсутствии документации, которую как пропагандирует Agile все равно никто не читает. Забегая вперед, для ценителей Agile уточню, что эта методика на мой взгляд, тоже может быть эффективно использована в больших проектах, но чуть позже.

2. Формирование спецификаций требований

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

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

Рисунок 8. – Формирование спецификации требований

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

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

А что показывает наш счетчик обратного отсчета?…

3. Резюме раздела

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

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

Рисунок 9. – Артефакты, порождаемые этапом разработки проектного решения

Автор: ARadzishevskiy

Источник