Критерии оценки и выбора CASE-средств

Критерии формируют базис для процессов оценки и выбора и могут принимать различные формы:

– числовые меры в широком диапазоне значений, например, объем требуемой памяти;

– числовые меры в ограниченном диапазоне значений, например простота освоения, выраженная в баллах от 1 до 5;

– двоичные меры (истина/ложь, да/нет), например способность генерации документации в формате Postscript;

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

Типичный процесс оценки и/или выбора может включать набор критериев различных типов.

Приведенная в данном разделе технология базируется в основном на стандартах IEEE [16,17] (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин "внедрение" используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов [16]:

• определение потребностей в CASE-средствах;
• оценка и выбор CASE-средств;
• выполнение пилотного проекта;
• практическое внедрение CASE-средств.

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

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

53. Элементы управления проектами создания ИС

До сих пор среди руководителей организаций часто бытует мнение, что система управления проектами (далее – СУП или Система) – это программное обеспечение, автоматизирующее процессы управления проектами, которыми как правило, являются процессы календарно-ресурсного планирования.
На самом же деле, в обновленной трактовке, указанной в своде знаний PMI PMBoK (4-th edition) [1], СУП – это совокупность процессов, инструментов, методов, методологий, ресурсов и процедур для управления проектом.

Вместе с этим, стоит обратить внимание на то, что проектная методология представляет собой трехуровневую структуру “ПРОДУКТ – БИЗНЕС — СТРАТЕГИЯ”:
1-й уровень (ПРОДУКТ) – управление проектами;
2-й уровень (БИЗНЕС) – управление программами;
3- й уровень (СТРАТЕГИЯ) – управление портфелем проектов.

Причем, уровень ПРОДУКТ (Управление проектами) является базовым уровнем, отправной точкой, для построения остальных уровней – БИЗНЕС и СТРАТЕГИЯ (см. Рисунок 1).

Рисунок 1 – Трехуровневая структура проектной методологии

Зачем организации СУП и проектная деятельность?
Система управления проектами позволяет эффективно выполнять проекты, приводящие к качественным изменениям внутри организаций, что в свою очередь позволяет организациям получать новые конкурентные преимущества.

В качестве примеров таких проектов можно привести строительство инфраструктуры, выход на IPO, вывод на рынок нового продукта или услуги и т.д.

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

Ключевые элементы Системы Управления Проектами
Существует множество интерпретаций состава элементов СУП. Из этого множества к ключевым элементам устойчивой системы, можно отнести следующие (см. Рисунок 2):
— Методологический;
— Организационный;
— Программно-технический;
— Мотивационный.

Подробнее: http://megamozg.ru/post/2110/

54. Управление требованиями к системе.

Управление требованиями к программному обеспечению (англ. software requirements management) — процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.

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

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

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

55. Оценка затрат на проектирование ИС.

Оценка эффективности информационной системы, как расчет соотношения положительного результата и произведенных затрат, не всегда возможна. Часто положительный эффект от автоматизации обработки информации проявляется спустя некоторое время после внедрения информационной системы, особенно, если речь идет о совершенствовании управленческого учета. Или проблематично выделить явное повышение производительности труда после автоматизации. В большинстве случаев принятие решения о разработке и внедрении автоматизированной информационной системы (АИС) базируется на интуиции управленческого персонала, рекламных обещаниях компаний-разработчиков программных средств, жизненном опыте друзей, коллег или конкурентов.

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

1. Изначально определяется денежная сумма, которую руководство может потратить на развитие корпоративных информационных систем. Финансирование по данной статье расходов рассчитывается как фиксированный процент от некой базы. Обычно, в качестве базы для расчета используется объем производства в денежном выражении, планируемая выручка, общая смета расходов организации. В пределах выделенных средств производится разработка и сопровождение ИС. При таком подходе возможно множество вариантов неэффективного расходования средств. Например, премия работникам IT-подразделений выплачивается при условии экономии средств. Следовательно, сотрудники таких отделов будут стараться снизить расходы даже в ущерб эффективности работы предприятия в целом. В другой ситуации IT-отдел приступит к реализации информационного проекта для освоения выделенных средств без четкой оценки необходимых затрат и не сможет его довести до конца при превышении установленного лимита.
2. Выбор программного средства из возможных вариантов основывается на стоимости разработки или приобретения программного продукта. Тем не менее, специалисты оценивают расходы на внедрение и дальнейшее использование автоматизированной информационной системы в 100-250% стоимости разработки АИС. В результате стоимость автоматизации системы обработки информации значительно превышает первоначально запланированную.
3. Предпочтение отдается той ИС, которая обладает меньшей стоимостью владения. Совокупная стоимость владения (ТСO - Total Cost of Ownership) информационной системой - сумма прямых и косвенных расходов пользователя на приобретение и использование ИС на протяжении всего жизненного цикла, включая стоимость рисков, связанных с использованием ИС.

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

Дата добавления: 2015-08-31