Производство информационных систем. Часть 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. – Артефакты, порождаемые этапом разработки проектного решения

Содержание

Часть 1. Отправная точка

Часть 2. Формирование проектного решения

Часть 3. Реализация проектного решения

  1. Уточнение и детализация плана-графика проекта
  2. Уточнение оценки затрат на производство информационной системы
  3. Процессы в итерациях по созданию программного продукта
  4. Подведение итогов итерации
  5. Передача финального релиза заказчику

Часть 4. Внедрение информационной системы

  1. Развертывание системы на площадке опытной эксплуатации
  2. Обучение персонала заказчика работе с информационной системой
  3. Выявление недостатков и дефектов информационной системы
  4. Согласование изменений в процессе внедрения информационной системы
  5. Доработка информационной системы по итогам опытной эксплуатации
  6. Передача информационной системы в промышленную эксплуатацию

Список литературы

1. Вольфсон Борис- «Гибкие методологии разработки»
2. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
системы»
FavoriteLoadingДобавить в избранное
Posted in Без рубрики

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *