По дисциплине:                         ССиУКПО

Группа:                                      341-БИН

Направление подготовки:    Бизнес-информатика

Вариант:                                    1

Выполнил:

студент                                       Бишлеев В. М.

Проверил:

доцент                                       И.И. Мирошниченко

Ростов - на - Дону

2018

Задание 1 к лабораторной работе:

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

· анализ требований,

· проектирование,

· кодирование (программирование),

· тестирование и отладка,

· эксплуатация и сопровождение.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.

Среди наиболее известных стандартов можно выделить следующие:

· ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

· ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

· CustomDevelopmentMethod (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (FastTrack) или "облегченного подхода", рекомендуемых в случае малых проектов.

· RationalUnifiedProcess (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

· MicrosoftSolutionFramework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

· ExtremeProgramming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС

· Обследование объекта и обоснование необходимости создания АС

· Формирование требований пользователя к АС

· Оформление отчета о выполнении работ и заявки на разработку АС

2. Разработка концепции АС

· Изучение объекта

· Проведение необходимых научно-исследовательских работ

· Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

· Оформление отчета о проделанной работе

3. Техническое задание

· Разработка и утверждение технического задания на создание АС

4. Эскизный проект

· Разработка предварительных проектных решений по системе и её частям

· Разработка документации наАС и её части

5. Технический проект

· Разработка проектных решений по системе и её частям

· Разработка документации наАС и её части

· Разработка и оформление документации на поставку комплектующих изделий

· Разработка заданий на проектирование в смежных частях проекта

6. Рабочая документация

· Разработка рабочей документации наАС и её части

· Разработка и адаптация программ

7. Ввод в действие

· Подготовка объекта автоматизации

· Подготовка персонала

· Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

· Строительно-монтажные работы

· Пусконаладочные работы

· Проведение предварительных испытаний

· Проведение опытной эксплуатации

· Проведение приёмочных испытаний

8. Сопровождение АС.

· Выполнение работ в соответствии с гарантийными обязательствами

· Послегарантийное обслуживание

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

· приобретение;

· поставка;

· разработка;

· эксплуатация;

· сопровождение.

2. Вспомогательные процессы:

· документирование;

· управление конфигурацией;

· обеспечение качества;

· разрешение проблем;

· аудит;

· аттестация;

· совместная оценка;

· верификация.

3. Организационные процессы:

· создание инфраструктуры;

· управление;

· обучение;

· усовершенствование.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

· приобретение (внутренние решения или решения внешнего поставщика);

· поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

· управление окружающей средой предприятия;

· инвестиционное управление;

· управление ЖЦ ИС;

· управление ресурсами;

· управление качеством.

3. Проектные процессы:

· планирование проекта;

· оценка проекта;

· контроль проекта;

· управление рисками;

· управление конфигурацией;

· управление информационными потоками;

· принятие решений.

4. Технические процессы:

· определение требований;

· анализ требований;

· разработка архитектуры;

· внедрение;

· интеграция;

· верификация;

· переход;

· аттестация;

· эксплуатация;

· сопровождение;

· утилизация.

5. Специальные процессы:

· определение и установка взаимосвязей исходя из задач и целей.

ГОСТ 28195-89 Оценка качества программных средств.

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

ОБЩИЕ ПОЛОЖЕНИЯ:

1. Оценка качества осуществляется на всех этапах жизненного цикла ПС при:

· планировании показателей качества ПС;

· контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);

· контроле качества в процессе производства ПС;

· проверке эффективности модификации ПС на этапе сопровождения.

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

3. Оценку качества проводят специалисты организаций:

· разработчика - на этапах разработки ПС;

· фондодержателя - на этапах приемки ПС в фонд;

· испытательных центров и центров сертификации ПС - на этапах испытаний и внедрения;

· изготовителя - на этапах тиражирования ПС;

· пользователя - на этапах внедрения, сопровождения и эксплуатации ПС.

4. Основные задачи, решаемые при оценке качества ПС:

· планирование уровня качества;

· контроль значений показателей качества в процессе разработки и испытаний;

· эксплуатационный контроль заданного уровня качества;

· выбор базовых образцов по подклассам и группам;

· методическое руководство разработкой нормативно-технических документов по оценке качества;

· методическое руководство разработкой нормативно-технических документов по оценке качества.

5. Методы определения показателей качества ПС различаются:

· по способам получения информации о ПС - измерительный, регистрационный, органолептический, расчетный;

· по источникам получения информации - традиционный, экспертный, социологический.

Задание 2 к лабораторной работе:

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

Основными критериями качества ПО (criteriaofsoftwarequality) являются:

1. Функциональность – способность ПО выполнять набор функций (действий), удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПО;

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

3. Эффективность – соотношение уровня услуг, предоставляемых ПО пользователю при заданных условиях, и объема используемых для этого ресурсов. К числу таких ресурсов могут относиться требуемые аппаратные средства, время выполнения программ, затраты на подготовку данных и интерпретацию результатов;

4. Эргономичность – характеристики ПО, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПО и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя;

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

6. Мобильность – способность ПО быть перенесенным из одной среды (окружения) в другую, в частности, с одной аппаратной платформы на другую.

Оценочные характеристики качества:

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

· Путем непосредственного измерения определяются опорные свойства.

· Остальные свойства оцениваются путем вычисления функций от опорных значений. Такие функции называются метриками.

Размерно-ориентированные метрики:

Размерно-ориентированные метрики Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (LinesOfCode (LOC)). К числу размерно-ориентированных метрик относятся:

· производительность

· качество

· удельная стоимость

· документированность

Метрики производительности и качества:

Метрики производительности и качества рассчитываются в виде следующих отношений:

Производительность = [число строк кода(LOC)] /[Затраты]

где затраты измеряются в человеко-месяцах (работа одного человека в течение месяца)

Качество = [число ошибок] / [число строк кода(LOC)]

Метрики стоимости и документированности:

Удельная Стоимость = [Стоимость в тыс. рублей] / [число строк кода(LOC)]

Документированность = [число страниц документации] / [число строк кода(LOC)]

Функционально-ориентированные метрики (FP-оценки):

Исходят не из размера программного продукта, а из его функциональности.

Оценивают:

· характер пользовательского интерфейса

· сложность выполняемой обработки

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

· степень сложности инсталляции

· условия эксплуатации

· степень модифицируемости

FP-оценки:

Вместо количества строк в текстах используется количество функциональных указателей (FunctionPoints)

FP=UI*(0.65+0.01*E[F(i)])

где =

1. UI - оценка сложности пользовательского интерфейса,

2. F(i) ("эф итое") – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.

3. E[F(i)] - сумма всех коэффициентов по i параметру.

FP-оценки:

К числу параметров, учитываемых коэффициентами регулирования сложности относятся:

· объем используемых средств передачи данных

· степень распределенности обработки

· степень распространенности используемой аппаратной платформы

· степень жесткости требований к производительности

· частота выполнения транзакций

Кроме того учитываются:

· процент информации, вводимой в режиме on-line

· сложность обработки данных, наличие значительной логической и математической обработки

· легкость инсталляции

· степень переносимости

· степень модифицируемости

Область применения метода функциональных указателей (FunctionPoints) – коммерческие информационные системы.

Для продуктов с высокой алгоритмической сложностью (системного и встроенного ПО, ПО реального времени) используется метод указателей свойств (FeaturesPoints).

При расчете указателя свойств учитывается количество используемых в ПО алгоритмов.

Функционально-ориентированные метрики аналогичны соответствующим размерно-ориентированным метрикам с точностью до замены:

· параметра длины на количество функциональных указателей

· или указатель свойств в зависимости от выбранного метода FP-оценки

Задание 3 к лабораторной работе: