Производство информационных систем. Часть 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)
    системы»
    Поделиться публикацией
    Комментарии 4
      0
      На мой взгляд пропагандисты Scrum явно лукавят.<...>
      Вопрос лишь в том, кто будет оплачивать все эти перерождения почти готового продукта? Тут возможно два базовых варианта:
      * У заказчика есть неограниченный финансовый кредит.<...>
      * Заказчик, заключив договор на определенную сумму<...>

      Хм. Странно, а в моей практике наиболее массовый вариант — есть контракт с фиксированным бюджетом, но на входе не детализированное ТЗ. И управление объемом детализации, реализации и качеством — позволяет производить множество изменений на каждом из этапов.
      Ведь зачастую, во многих крупных проектах внедрения информационных систем, заказчики не являются экспертами в том, что им нужно и уж тем более состава действий в проекте, т.к. не понимают что делает команда — они эксперты в своей области. И в конечном итоге то они ожидают результат от проработки их задачи, а не ритуального исполнения последовательности действий в диаграмме гантта.
      Суть agile заключается в том, что возможность распланировать сложный проект до уровня часов и конкретных задач — это даже не инженерная или управленческая задача, а искусство — т.е. достаточно субъективная вещь. И даже атомарная инженерная задача в рамках проекта не имеет однозначных оценок трудозатрат — так как в том числе упирается в конкретного исполнителя с его системой мотивации, квалификации и готовности окружения с которым он будет работать.
      Поэтому вместо того, чтобы самообманываться, что процесс в областях с высокой неопределенностью будет контролируемым на всю глубину — предлагается иметь цель и корректировать средства, методы, а часто и результаты в ходе проекта. А вопрос оценки стоимости оставить все же искусству продавцов.
        0
        Ведь зачастую, во многих крупных проектах внедрения информационных систем, заказчики не являются экспертами в том, что им нужно и уж тем более состава действий в проекте, т.к. не понимают что делает команда — они эксперты в своей области. И в конечном итоге то они ожидают результат от проработки их задачи,

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

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

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

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

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

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

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

          Зачем мне читать — если я с этим просто работаю постоянно в практике )). Если дошло до законодательства, а это суд — значит проект изначально был непроработан и вовсе не в детализации проектных задач, а в модели управления им и рисками и отношениями с заказчиком.
          Проекты с детальной, документированной проектной проработкой предполагают, что оба участника и заказчик и исполнитель находятся в конкурентной позиции. А есть большой класс задач и проектов, где это вовсе не так. В них заказчик также зависим от успешности проекта как и исполнитель. Банально в кастомных системах получить потом поддержку, если система выполнена по плану и формальным признакам с убытком исполнителя — будет крайне затруднительно. А без этого система жить и развиваться не будет дальше — деньги на неё будут просто выброшены. Таких примеров внедрений множество. Более того — задача внедрения ИС часто ведь жизненно необходима для заказчика — нормативно ли как для госки или обусловленная бизнес-убытками, потерей конкурентности. Поэтому если стороны заинтересованы получить результат — проще договориться, чем закрыться документированием.
          Но безусловно это не договора на 3 копейки и в такие договора и проекты не входят без управления отношениями с заказчиком, что также является часть проектного управления.
            0
            По крайней мере есть ряд продуктов — на котором первичное макетирование метаданных почти ничего не стоит и при этом это уже будет работоспособный прототип, который выпускается частями и отрабатывается конкретные потребности и ожидания пользователей

            Я специально посвятил целый раздел, для определения точки зрения, на понятие БОЛЬШОЙ системы. На этапе предпроектного исследования могут еще не быть известны ни команды, ни инструменты и платформы которые будут использоваться. Их возможно только предстоит выбрать по итогам первого этапа. Команд в проекте может быть много и они могут использовать самые разнообразные технологии, которые еще надо будет соединить в единую систему.
            Если дошло до законодательства, а это суд — значит проект изначально был непроработан

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

            Бывает все прозаичнее. Команда получает при старте лишь аванс. Основной расчет может производиться при сдаче проекта. При этом если задействованы подрядчики и субподрядчики и проект идет больше полугода, то работа идет в кредит. То есть небольшая команда условно говоря каждый месяц кредитует 1 млн. руб. за полгода 6 млн. руб. Причем субподрядчику их должен не заказчик, а подрядчик. Заказчик не принимает продут у подрядчика, подрядчик соответственно у субподрядчика. Так дедка за репку, бабка за дедку. Я к тому, что в жизни больших проектов все сложнее, чем просто сходить вальяжно в суд. людям надо платить зарплату, кредиторам проценты, а доказать, что Вы делали все согласно контракту невозможно — нет детальных условий контракта.

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

            Самое читаемое