39. Основы case технологии.

CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.

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

Классификация по типам:

• Средства анализа;

• Средства проектирования баз данных;

• Средства разработки приложений;

• Средства реинжиниринга;

• Средства планирования и управления проектом;

• Средства тестирования;

• Средства документирования.

Классификация по категориям:

• отдельные локальные средства, решающие небольшие автономные задачи;

• набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла;

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

40. Определение потребности в CASE – средствах.

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

41. Оценка и выбор CASE средств.

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

Входной информацией для процесса оценки является:

• определение пользовательских потребностей;

• цели и ограничения проекта;

• данные о доступных CASE-средствах;

• список критериев, используемых в процессе оценки.

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

Процесс выбора:

• формулировка задач выбора, включая цели, предположения и ограничения;

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

• выполнение необходимого количества итераций с тем, чтобы выбрать (или отвергнуть) средства, имеющие сходные показатели;

• подготовка отчета по результатам выбора.

Результаты процесса выбора:

• рекомендации по выбору конкретного CASE-средства

• запрос на получение дополнительной информации, необходимой для оценки

42. CASE-модель жизненного цикла ПС.

Жизненный цикл ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Фазы ЖЦ CASE-технологии:

• Прототипирование

• Проектирование спецификаций

• Контроль проекта

• Кодогенерация

• Системное тестирование

• Сопровождение

43. Состав, структура и функциональные особенности CASE-средств.

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

Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:

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

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

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

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

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

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).

3. Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.

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

5. Доступность для разных категорий пользователей.

6. Рентабельность.

7. Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

44. Особенности и возможности Internet-технологии.

Функции интернета:

• Информационная;

• Коммуникационная.

Информационная функция:

• Получение информации об изучаемом предмете;

• Обучение;

• Получать информацию о событиях в реальном времени;

• Использование серверов для хранения данных.

Коммуникационная функция:

• Электронная почта;

• Общение в режиме online;

• Совместное использование приложений;

• Использование интернет – сервисов.

Средства разработки:

• HTML - стандартный язык разметки документов в Internet;

• CSS используется создателями веб-страниц для задания цветов, шрифтов, расположения отдельных блоков и других аспектов представления внешнего вида этих веб-страниц;

• JavaScript — скриптовый язык программирования.

45. Услуги, предоставляемые Internet.

• Электронная почта;

• Общение в режиме online;

• Обучение;

• Совместное использование приложений;

• Использование интернет – сервисов.

46. Особенности и возможности Intranet-технологии.

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

Сервисы, предоставляемые Интранетом:

• Просмотр гипертекстовых документов

• Электронная почта

• Службы новостей

• Передача файлов

• Взаимодействие с базами данных с помощью серверных приложений

• Передача мгновенных сообщений

Средства разработки, эксплуатации и сопровождения:

• средства выполнения (Run-time);

• инструментальные средства разработки;

• средства администрирования.

• Средства выполнения включают:

• программы просмотра и навигации (браузеры);

• клиентские приложения и расширения;

• программное обеспечение Web-серверов;

• серверные приложения и расширения;

• средства поиска информации;

• программное обеспечение Internet-серверов;

• средства безопасности.

47. Промышленные технологии разработки ПС.

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

48. Экстремальное программирование.

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

Основная цель ХР:

• Создание качественных программ.

Одно из главных средств:

• Отказ от всего, что не поддерживает непосредственно эту цель.

Суть экстремального программирования:

• все задание разбивается на формулировки подзадач, каждая формулировка должна иметь срок выполнения от 1 до 3-х недель, если больше, то - следует разделить, меньше - объединить;

• путем равновесия объема, времени, ресурсов и качества составляется структурный план выпуска версий программы на основании пользовательских формулировок;

• при выполнении очередной итерации проекта важно не добавить функциональности раньше времени;

• перед началом новой итерации создается ее подробный план: формулировки разбиваются на задачи сроком от 1 до 3-х дней и сортируются по важности, добавляются задачи, которые не смогли пройти тест приемки;

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

• простой дизайн проекта;

• простые имена для создаваемых классов;

• постоянный контакт с заказчиком;

• использовать парное программирование: два программиста за одним компьютером;

• не бояться переделывать старый, работающий, но малоэффективный код;

• оптимизировать систему в последнюю очередь;

• следить за качеством исходных текстов;

• использовать тесты создаваемого "черного ящика" как можно чаще

• не работать сверх графика (переутомление).

Экстремальное программирование доводит использование многих общепринятых и широко используемых принципов программирования до экстремальных уровней:

• Пересмотр кода – каждый участник проекта будет пересматривать код постоянно;

• Проектирование – проектирование в экстремальном программировании нужно сделать составной частью повседневной работы каждого из участников проекта;

• Тестирование – каждый участник проекта будет тестировать код программы постоянно;

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

• Интеграционное тестирование - необходимо собирать и тестировать разрабатываемую систему несколько раз на дню.

49. Оценка качественных показателей ПС.

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

2. Установить веса показателей

где w_i – экспертная оценка (вес)

3. Для каждого показателя установить конкретную численную оценку.

Например:

• 0 – свойство в ПС присутствует, но качество его неприемлемо;

• 0.5 – 1 – свойство в ПС присутствует и обладает приемлемым качеством;

• 1 – свойство в ПС присутствует и обладает очень высоким качеством.

4. Оценка качества ПС как иерархической взвешенной суммы всех весов.

где w_i – экспертная оценка (вес), r_i – оценка, установленная экспериментом

5. Представить выходные данные:

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

б) гистограмма, показывающая распределение показателей по интервалам оценок.

в) какие дефекты ПС обнаружены в результате анализа показателей качества.

50. Оценка сложности ПС.

Метод Холстеда.

1. Мера длины

где – число различных операторов, – число различных операндов

2. Объем модуля

51. Оценка надежности ПС.

Модель Коркорэна.

N₀– число безотказных испытаний

N – число испытаний

N_i– количество ошибок i-го типа

a_i – вероятность появления ошибки i-го типа

Y_i – вероятность появления ошибок Y_i=a_i, если N_i>0 Y_i=0, если N_i=0

k – известное число типов ошибок

R – показатель уровня надёжности

Преимущества: легкий расчёт и получение показателя надёжности в виде числа.

Недостатки: необходимо знать вероятности появления ошибок в том или ином классе задач.

52. Оценка технико-экономических показателей ПС.

• объём программного средства (в операторах языка или строках текста)- О;

• длительность разработки (по фактическому времени)-Д;

Д=Д1-Д2, где Д1 - дата начала разработки технического задания на ПС, Д2- дата сдачи ПС;

• число программных и информационных модулей в ПС -Р;

• количество фактически затраченного времени на разработку ПС- М;

• трудоёмкость разработки ПС (по фактически затраченному времени по стадиям разработки) - Т;

• абсолютное снижение трудовых затрат- ТА

ТА=Т0-Т1, где Т0- трудовые затраты на решение задачи по базовому варианту ( вручную), Т1- трудовые затраты на решение задачи по предлагаемому варианту;

• коэффициент относительного снижения трудовых затрат- КТ

КТ=ТА/Т0*100,

• индекс снижения трудовых затрат или повышение производительности труда- УТ

УТ=Т0/Т1,

• абсолютное снижение стоимостных затрат- СА

СА=С0-С1, где С0 - стоимостные затраты на решение задачи по базовому варианту, С1- стоимостные затраты на решение задачи по предлагаемому варианту;

• коэффициент относительного снижения стоимостных затрат- КС

КС=СА/С 0 * 100,

• индекс снижения стоимости затрат -УС

УС=С0/С1,

• срок окупаемости ПС- К

К=КТ/СА, где КТ- затраты на разработку и внедрение программного средства.