Планирование и проектирование информационных систем

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

 

Эти факторы увеличивают риск при  выполнении проектов:

1 группа связанна с характером проектируемой системы и ее программного обеспечения.

эти факторы следующие:

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

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

Для планирования проекта  обычно оценка сложности осуществляется на основе его функциональных характеристик.

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

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

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

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

Мы  пользовались базовой моделью, и  она нам позволяла:

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

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

Теперь  еще об оценках ресурсов проекта.

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

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

1. Описание ресурса
2. Сведения о его наличии или отсутствии
3. Хронологический момент времени, когда он потребуется
4. Продолжительность этого ресурса.

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

Людские ресурсы.

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

Ресурсы технических средств

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

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

 

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

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

Значит, какие здесь проблемы, с  которыми сталкивается менеджер? У  него есть ряд альтернатив:

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

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

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

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

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

В компании имеется большое количество программных продуктов и их надо использовать. Для того чтобы это  делать необходимо, сопровождать эти  старые программы и это дорого. Потому что, как правило, старые программы  разрабатывались людьми, которые  уже ушли… Ну не «туда ↑» в  другие места… J Но самое, то, главное чтобы качество документации, как правило, бывает плохим. У вас есть код, и вот вы на основе кода должны восстановить смысл вообще того, что там делается.  Это как черный ящик – вы знаете, что есть входи и выходы и есть какая-то функция, которая выполняется.

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

Какие здесь стратегии используются?:

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

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

Реверсивная инженерия это процесс анализа программы (кода) с целью выявления ее конструкции. Т.е. ее представления на более высоком уровне по сравнению с исходным кодом.

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

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

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

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

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

 

Управление рисками при разработке проектов информационных систем.

 

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

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

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

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

 

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

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

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

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

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

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