Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Современные стандарты и модели диагностики функционирования ИС (СОСОМО, ISO,CMM, ITIL)





 

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

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

COCOMO

В конце 70-х годов Барри Боэмом (BarryBoehm) была разработана модель оценивания объемов работ при разработке информационных систем, и получила название конструктивная модель стоимости (ConstructiveCostModel – COCOMO). На сегодняшний день данная модель оценки трудоёмкости разработки программного обеспечения является наиболее известной среди множества подобных моделей. Она основана на анализе ряда проектов, реализованных по заказу Министерства обороны США. В общих чертах она с одной стороны определяет соответствие между размером системы в тысячах условных строк кода и «классом» проекта, а с другой трудоемкость разработки системы.

-Базовый уровень рассчитывает трудоемкость и стоимость разработки как функцию от размера программы. Размер выражается в оценочных тысячах строк кода (KLOC – kilolinesofcode).

COCOMO применим к трем классам проектов разработки ПО:

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

Полуразделенный вид – средние по размеру команды со смешанным опытом разработки и со смешанными требованиями (как жесткими, так и нет).

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



Вот базовые уравнения COCOMO:

Трудоемкость = ab(KLOC)^bb [человеко-месяцев]

Срок разработки или длительность = cb(Трудоемкость)^db [месяцев]

Число разработчиков = Трудоемкость/ Срок разработки [человек]

Коэффициенты ab, bb, cb и db приведены в следующей таблице.

 

Тип проекта ab bb cb db
Органический 2.4 1.05 2.5 0.38
Полуразделенный 3.0 1.12 2.5 0.35
Встроенный 3.6 1.20 2.5 0.32

Таблица 4.1 Коэффициенты модели COCOMO Базового уровня

 

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

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

Каждому из этих 15 факторов ставится в соответствие рейтинг по шести бальной шкале, начиная от «очень низкий» и до «экстра высокого» (по значению или важности фактора). Далее значения рейтинга заменяются множителями трудоемкости из нижеприведенной таблицы. Произведение всех множителей трудоемкости составляет Регулирующий фактор трудоемкости (РФТ). Обычно он принимает значения в диапазоне от 0.9 до 1.4. Коэффициенты представлены в таблице ниже.

 

Факторы стоимости Рейтинг
Очень низкий Низкий Средний Высокий Очень высокий Критический
Характеристики продукта            
1. Требуемая надежность ПО 0.75 0.88 1.00 1.15 1.40  
2. Размер БД приложения   0.94 1.00 1.08 1.16  
3. Сложность продукта 0.70 0.85 1.00 1.15 1.30 1.65
Характеристики аппаратного обеспечения            
4. Ограничения быстродействия при выполнении программы     1.00 1.11 1.30 1.66
5. Ограничения памяти     1.00 1.06 1.21 1.56
6. Неустойчивость окружения виртуальной машины   0.87 1.00 1.15 1.30  
7. Требуемое время восстановления   0.87 1.00 1.07 1.15  
Характеристики персонала''''            
8. Аналитические способности 1.46 1.19 1.00 0.86 0.71  
9. Опыт разработки 1.29 1.13 1.00 0.91 0.82  
10. Способности к разработке ПО 1.42 1.17 1.00 0.86 0.70  
11. Опыт использования виртуальных машин 1.21 1.10 1.00 0.90    
12. Опыт разработки на языках программирования 1.14 1.07 1.00 0.95    
Характеристики проекта''''            
13. Применение методов разработки ПО 1.24 1.10 1.00 0.91 0.82  
14. Использование инструментария разработки ПО 1.24 1.10 1.00 0.91 0.83  
15. Требования соблюдения графика разработки 1.23 1.08 1.00 1.04 1.10  

Таблица4.2 Коэффициенты рейтинга

 

Формула модели COCOMO для среднего уровня принимает вид

E=ai(KLoC)^(bi).РФТ

где E – трудоемкость разработки ПО в человеко-месяцах, KLoC – оценочный размер программы в тысячах строках исходного кода, и РФТ – регулирующий фактор, рассчитанный ранее. Коэффициенты ai и показатель степени bi представлены в следующей таблице.



 

Тип проекта ai bi
Органический 3.2 1.05
Полуразделенный 3.0 1.12
Встроенный 2.8 1.20

Таблица 4.3 Коэффициенты Среднего уровня модели COCOMO

 

Расчет времени разработки для среднего уровня COCOMO совпадает с расчетом для Базового уровня.

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

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

ISO 9000

ISO 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.

Серия стандартов ISO 9000 разработана Техническим комитетом ТК 176 Международной Организации по Стандартизации (ISO, InternationalOrganizationforStandardization). В основе стандартов лежат идеи и положения теории всеобщего менеджмента качества (TQM)

Серия стандартов ISO 9000 неоднократно пересматривалась.

1 версия была подготовлена в 1987 году.

2 версия была выпущена в 1994 году и представляла собой уточненную версию 1987.

3 версия была разработана в 2000 году. Версия 1994 года была радикально пересмотрена.

4 версия стандарта вышла разобщенно – в 2005 году был выпущен стандарт ISO 9000-2005, в 2008 и 2009 годах были опубликованы стандарты ISO 9001 и 9004.

Несмотря на ожидавшийся полный пересмотр версии 2000 года, ТК176 решил ограничиться "косметическими" правками – исправлением неточностей и разночтений. Причинами отказа от существенных изменений и задержки с выпуском новой версии были названы желание продлить срок действия существующих сертификатов у организаций (т.е. сохранить статус-кво в сертификационном бизнесе).

Выход 5 версии стандартов планируется на 2012 год.

Основополагающим стандартом серии стандартов качества является документ ISO 9000 "Стандарты на управление качеством и обеспечение качества. Руководящие положения по выбору и применению". Он определяет основные принципы политики руководства организаций в области обеспечения качества, описывает три возможных модели управления, устанавливает и разъясняет взаимосвязь между различными понятиями в области качества. Стандарт устанавливает новое для экономических процессов понятие "степень подтверждения", определяющее представление потребителю (заказчику) доказательств того, что система управления качеством и продукция изготовителя (поставщика) соответствует установленным в договорах техническим требованиям. В стандарте ISO 9004 "Система качества. Элементы системы управления качеством. Руководящие положения" рассматриваются 20 элементов системы управления качеством на предприятии и их применение. На основе рекомендаций этого стандарта руководитель предприятия может выбрать соответствующие элементы управления, отвечающие специфике организации. Используя рекомендации стандарта при проектировании системы управления качеством можно сократить затраты и одновременно, за счет применения уже апробированного опыта, повысить экономический эффект от проектируемой системы.

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

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

Вторая модель – стандарт ISO 9002 "Система качества. Модель обеспечения качества на стадиях производства и монтажа". Стандарт применяется в условиях, когда требования к продукции устанавливаются с точки зрения уже разработанного проекта. В этих случаях необходимо подтвердить возможности изготовителя (поставщика) в части производства и монтажа продукции. Хотя в договоре (контракте) рекомендуется использовать полный набор требований, строгость соблюдения некоторых из элементов управления качеством может быть ослаблена.

Третья модель – стандарт ISO 9003 "Система качества. Модель обеспечения качества на стадии контроля и испытания готовой продукции". Эта модель устанавливает возможности и обязанности изготовителя (поставщика) в части контроля и испытания поставляемой продукции. Третья модель качества может содержать полный набор требований или только часть наиболее важных элементов.

CMM

CapabilityMaturityModel – модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.

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

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

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

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

Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

Повторяемый уровень (repeatable level). Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.

Определенный уровень (defined level). Он характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

Управляемый уровень (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

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

Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.).

Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение).

Успешность использования данной области на практике (например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации).

Небольшой пример

Группа оборонно-космических проектов компании Boeing, сертифицированная летом 1996 г. по пятому уровню CMM, выполняла заказ Минобороны США по разработке и обеспечению полного жизненного цикла ПО для системы космической транспортировки оборудования и пристыковки грузовых модулей. Это ПО использовалось как на наземных станциях слежения, так и в бортовых компьютерах космических аппаратов. Когда группа обладала УЗР 4, во время разработки выявлялось 89% ошибок (из них 70% – на этапе тестирования). Теперь выявляются практически все ошибки, причем на ранних стадиях, а за полгода, прошедшие после сертификации по УЗР 5, субъективная оценка пользователями качества ПО возросла с 97% до 100%.

ITIL

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

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

Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей эффективности (KPI), а также на ресурсах, затраченных на достижение этих целей.

Преимущества библиотеки ITIL для заказчиков/пользователей:

- предоставление ИТ-услуг становится более ориентированным на заказчика, соглашения о качестве услуг способствуют улучшению взаимоотношений;

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

- лучше контролируются качество и стоимость услуг;

- улучшается взаимосвязь компании с ИТ-организацией за счет определения точек контактов.

Преимущества библиотеки ITIL для ИТ-организаций:

- становится четко понятна структура ИТ-департамента, его организация становится более рациональной и более ориентированной на корпоративные цели;

- руководство организацией становится более целенаправленным, облегчается Управление Изменениями;

- эффективная структура процессов создает основу для эффективного аутсорсинга элементов ИТ-услуг;

- следование передовому опыту ITIL способствует изменению корпоративной культуры в направлении осознания, что задачей ИТ-департамента является предоставление услуг, и поддерживает внедрение системы обеспечения качества на основе стандартов серии ISO-9000;

- библиотека ITIL предоставляет единую "систему координат" и понятий для взаимодействия как в компании, так и с поставщиками, необходимую при разработке и стандартизации корпоративных процедур.

Возможные проблемы при работе с ITIL:

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

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

- улучшения не достигаются при недостатке понимания, что должны обеспечивать процессы (в чем их цель), что является критериями оценки эффективности процессов и как осуществлять их контроль;

- улучшения в предоставлении услуг и снижении стоимости недостаточно видны;

- успешная реализация требует вовлечения и наличие обязательств со стороны руководства и при­верженности сотрудников на всех организационных уровнях[37]. Предоставление права разработки структуры процессов специализированному подразделению может привести к его изоляции, в результате чего определенные им направления деятельности не будет приняты другими подразделениями;

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

Эти возможные проблемы, конечно, могут быть решены. Библиотека ITIL развивалась с целью достижения преимуществ для ИТ-организации и компании в целом. Многие из лучших практических предложений направлены на предотвращение таких проблем или их решение в случае возникновения

 

 

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




Дата добавления: 2014-01-03; Просмотров: 645; Нарушение авторских прав?;


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



ПОИСК ПО САЙТУ:


Читайте также:
studopedia.su - Студопедия (2013 - 2022) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.052 сек.