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

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

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

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

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

Поддержка пользователей это обучение работе с системой, документация, вторичная поддержка. планирование изменений – любая информационная система меняется и развивается при изменении бизнеса, или при обнаружении ошибок там.., и пользователи должны понимать необходимость этих изменений и должны получать соответствующую информацию. Здесь обращать внимание на человека и плохая документация, знаете, насколько она раздражает, и вообще не поймешь где там подлежащее, а где сказуемое. Даже форма эксплуатационной документации очень важна. Вот я работаю с некоторыми сотрудниками – можно основную мысль выразить сразу, а потом и ее развить, а можно что-то начать и долго-долго и ждешь – когда же, для чего что нужно делать? Надо начинать с того, что в случае возникновения такой-то ситуации надо делать то-то то-то. А не наоборот – «надо вообще выключить, переключить это направо.. налево.. нажать на такие клавиши.. ЕСЛИ У ВАС произошло то-то то-то J.

Сопровождение системы 

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

• Должна быть техническая компетентность
• Он должен быть убедительным собеседником
• Хорошим организатором и контролером
• Быстро реагировать на изменения
• Эффективно планировать
• Эффективно руководить
• Быть хорошим педагогом

Какие пять компонент, характеризующих роль менеджера?:

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

Измерение управления проектом Это выбор соответствующих метрик, их постоянное накопление.

При разработке ИС измерение проводится, для того чтобы:

1. Определить и показать качество продукции и соответствие его поставленным требованиям.
2. Оценить производительность труда
3. Оценить выгоды
4. Сформировать базовую линию организации

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

Наиля: “т.е. это какие-то нормативы данной организации!”

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

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

Результаты прямых измерений достаточно просто собрать.

Должно быть принято соглашение о метриках не только в пределах организации, но и в пределах отрасли  и мировой практики, чтобы можно  было по аналогии сказать затраты. Вот  на ремонт большого театра Швыдко взял и запросил миллиард долларов, а ему говорят – вы знаете, на ремонт мощнейшего (чего-то там) требуется всего несколько миллионов, а он – ну че?, много? говорит.. ну ладно.. давайте 500 миллионов. Ну так, разница, да? 500 миллионов долларов потребовал, ну можно 500, ну и если не хотите миллиард – давайте мы за 500. т.е. очень принципиально важно договориться.

Все эти метрики принято разделять  по нескольким признакам:

• Метрики производительности – процесс разработки
• Качества – пригодность системы (соответствие техническим характеристикам)
• Технических характеристик  - характеризуют особенности изделия (сложность)

2-й  признак – по ориентации 

• Размерно-ориентированные - результаты прямых измерений
• Функционально ориентированные – косвенно характеризуют функциональные возможности системы. Особенности его предметной информационной области. Этот подход принят в качестве стандартного.
• Человеко-ориентированные – эффективность и качество работы системы, удобство взаимодействия с ней, простота обучения работе с ней.

На  основе этих метрик существует масса  производных метрик.

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

Функционально ориентированные. Давайте о них поговорим более полно, т.к. как я сказал, что эта метрика становится общепринятой… для оценки характеристики системы или любого программного пакета и процесса его разработки была предложена мера функциональной точки. Подсчитывается число функциональных точек, которые вычисляются на основе 5-ти характеристик описывающих особенности функционирования изделия:

• Число входов пользователя.
• Число выходов пользователя
• Число запросов пользователя
• Число файлов БД
• Число внешних интерфейсов

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

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

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

Наибольшее  число строк для:

• Ассемблера – 300
• Паскаль – 100
• Ады - 70
• Объектно ориентированных – 30
• Языки 4-го поколения – 20

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

Оценка  размеров продукта на основе его функциональной декомпозиции

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

Сбор данных.

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

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

1. Какие из требований пользователя могут с наибольшей вероятностью измениться?
1. Самое вероятное – изменение исходных требований?
2. Какие из разрабатываемых модулей наиболее подвержены ошибкам?
3. Какое количество тестов необходимо запланировать для каждого модуля?
4. Какое количество ошибок и какого типа можно ожидать при проведении тестирования?

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

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

Чтобы упростить сбор и последующую  оценку собираемых данных целесообразно  руководствоваться следующими рекомендациями:

1. Точность собираемых данных должна быть обоснована разумным округлением.
2. Данные для базовой линии должны собираться для как можно большего числа прошлых проектов.
3. Данные по разным проектам должны быть сопоставимы и не содержать неоднозначности в их интерпретации в их единицах измерения.
4. Данные должны систематизироваться по группам программных средств.
5. Целесообразно состав собираемых метрик и выделенные группы информационных систем и программных пакетов регламентировать в соответствующих стандартах.