Понятие программного обеспечения, классификация программного обеспечения

Понятие программного обеспечения, классификация программного обеспечения

 

Программное обеспечение - это совокупность программ, выполненных вычислительной системой.

К ПО относится также вся область деятельности по проектированию и разработке ПО.

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

Существует три категории ПО:

1) Прикладные программы, непосредственно обеспечивающие выполнение необходимых пользователям работ.

2) Системные программы:

• управление ресурсами ЭВМ.
• создание копий используемой информации.
• проверку работоспособности устройств компьютера.
• выдачу справочной информации о компьютере и др..

3) Инструментальные программные системы, облегчающие процесс создания новых программ для компьютера.

 

Более или менее определенно сложились следующие группы программного обеспечения:

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

 

Жизненный цикл ПО и его стандартизация, процессы ЖЦ ПО, группы процессов ЖЦ ПО

 

В технологиях разработки программного обеспечения понятие жизненного цикла является одним из основных.

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

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

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

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

1.1. приобретение;

1.2. поставка;

1.3. разработка;

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

1.5. сопровождение;

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

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

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

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

2.4. верификация;

2.5. аттестация;

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

2.7. аудит (определение соответствия требованиям, планам и условиям договора);

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

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

3.1. управление;

3.2. инфраструктура;

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

3.4. обучение.

3. Процесс разработки ПО: основные действия и их содержание

 

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

Процесс разработки включает следующие действия:

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

2) Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т.д.

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

4) Анализ требований к ПО

Проектирование архитектуры ПО

6) Детальное проектирование ПО

Кодирование и тестирование ПО

8) Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирование агрегированных компонентов.

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

10) Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование.

11) После интеграции система, в свою очередь, подвергается квалификационному тестированию на соответствие совокупности требований к ней.

12) Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором.

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

 

Сертификация процессов разработки ПО, модель CMM

Гарантия качества процессов разработки программных продуктов является весьма значимой в современных условиях. Такую гарантию дают сертификаты качества процесса, подтверждающие его соответствие принятым международным стандартам. Наиболее авторитетными являются модели стандартов ISO 9001:2000, ISO/IEC 15504 и модель зрелости процесса разработки ПО (Capability Maturity Model – CMM).

Основным понятием модели CMM является зрелость процессов (Software process maturity). Зрелость процессов – это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.

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

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

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

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

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

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

 

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

Критерии применения

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

Системный анализ – Анализ требований – Проектирование – Реализация – Тестирование – Внедрение – Сопровождение

Системный анализ: задается роль каждого элемента и их взаимодействие друг с другом.

Анализ требований: определение функциональных и нефункциональных требований к ПО.

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

Реализация: преобразование проектных спецификаций в текст на ЯП (язык прогр.) (кодирование).

Т естирование: проверка корректности, исправление ошибок в функциях и логике.

Внедрение: установка разработанного ПО у заказчика, обучение персонала.

Сопровождение: внесение изменений в эксплуатируемое ПО (исправления ошибок, адаптации к изменениям внешней для ПО среды, усовершенствования ПО по требованиям заказчика).

Преимущества:

- модель хорошо известна потребителям;

- хорошо срабатывает для тех проектов, которые достаточно понятны

- весьма доступна для понимания, проста и удобна в применении;

- ее структурой может руководствоваться даже неопытный персонал;

- отличается стабильностью требований;

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

- способствует осуществлению строгого контроля менеджмента проекта;

- стадии модели довольно хорошо определены и понятны;

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

Недостатки:

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

- Выражение "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;

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

- у клиента едва ли есть возможность ознакомиться с системой заранее;

- все требования должны быть известны в начале жизненного цикла;

- возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

- модель основана на документации, а значит, количество документов может быть избыточным;

- весь программный продукт разрабатывается за один раз. Нет возможности раз­бить систему на части;

- отсутствует возможность учесть переделку и итерации за рамками проекта.

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

Критерии применения

 

Макетирование (прототипирование) – это процесс создания модели разрабатываемого программного продукта. Модель может принимать один из трех видов:

1) бумажный макет или «электронный» макет, который представляет GUI;

2) работающий макет (выполняет только часть требуемых функций);

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

Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик, как это показано.

Преимущества:

- пользователь может "увидеть" системные требования в процессе их сбора командой разработчиков;

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

- в процесс можно внести новые требования пользо­вателя;

-

НАЧАЛО

Сбор и уточнение требований

Быстрое проектирование

Построение макета

Оценка макета заказчиком

Уточнение макета

Конструирование продукта

КОНЕЦ

Продолжать

Да

Нет

образуются постоянные, видимые признаки прогресса;

- качество продукта определяется при активном участии пользователя в процесс разработки;

- благодаря меньшему объему доработок уменьшаются затраты на разработку;

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

Недостатки:

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

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

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

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

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

- вызывает зависимость и может продолжаться слишком долго;

Критерии применения:

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

- существует потребность в разработке пользовательских интерфейсов;

- осуществляются временные демонстрации;

- выполняется новая, не имеющая аналогов разработка;

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

- алгоритмы или системные интерфейсы усложнены;

- разрабатывается ПО, когда проявляется средняя и высокая степень риска;

 

Типы связей IDEF3

Изображение	Название	Назначение
	Временное предшествование (Temporal precedence)	Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия (исходное действие должно завершиться, прежде чем конечное действие сможет начаться)
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

Соединения разбивают или соединяют внутренние потоки:

Типы соединений

Графическое обозначение	Название	Вид	Правила инициализации
&	Соединение «И»	Разворачивающее	Каждое конечное действие обязательно инициируется
Сворачивающее	Каждое исходное действие обязательно должно завершиться
X	Соединение «исключающее ИЛИ»	Разворачивающее	Одно и только одно конечное действие инициируется
Сворачивающее	Одно и только одно исходное действие должно завершиться
O	Соединение «ИЛИ»	Разворачивающее	Одно или несколько конечных действий инициируются
Сворачивающее	Одно или несколько исходных действий должны завершиться

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

Виды указателей IDEF3

Тип указателя	Назначение
ОБЪЕКТ (OBJECT)	Для описания того, что в действии принимает участие какой-либо заслуживающий внимания объект.
ССЫЛКА (GOTO)	Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться к соединению
ЕДЕНИЦА ДЕЙСТВИЯ (Unit of Behavior – UOB)	Для помещения на диаграмму дополнительного экземпляра уже существующего действия без зацикливания (при повторении одного и того же действия).
ЗАМЕТКА (NOTE)	Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах.
УТОЧНЕНИЕ (Elaboration – ELAB)	Для уточнения или более подробного описания изображенного на диаграмме.

22 Основные этапы проектирования программных систем и их содержание

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

Модель анализа - Информационная - Функциональная - Поведенческая

Этап проектирования

Этап кодирования

Этап тестирования

Процедурная разработка

Разработка данных

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

Программные модули

Модель хранилища данных

Редактор проекта

Генератор кода

Проектный транслятор

Редактор программы

Анализатор проекта

Хранилище данных проекта

Модель «клиент-сервер»

Клиент 1

Клиент 2

Клиент 3

Клиент N

Сервер 1

…

Сервер 2

Сервер 3

Сервер M

…

Сеть (протокол взаимодействия TCP/IP)

Трехуровневая модель

Графический интерфейс пользователя

Бизнес-логика

Реляционная СУБД

Преимущества трехуровневой модели:

· упрощается такая модификация уровня, которая не влияет на другие уровни;

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

Модель абстрактной машины

Операционная система

СУБД

Управление объектом

Управление версиями

Операционная система

СУБД

Управление объектом

Управление версиями

Вид сверху

Вид сбоку

Широковещательная модель

Подсистема 1

Подсистема 2

Подсистема N

…

Обработчик событий и сообщений

Модульная декомпозиция

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

· модель потока данных;

· модель объектов.

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

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

Принцип «разделяй и властвуй». С увеличением количества модулей (и уменьшением их размера) затраты на их реализацию также растут.

Стоимость

Количество модулей

Стоимость модуля

Стоимость интерфейса

Общая стоимость

Opt Область минимальной стоимости

Затраты на модульность

Таким образом, существует оптимальное количество модулей Opt, которое приводит к минимальной стоимости разработки.

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

Информационная закрытость обозначает следующее:

· все модули независимы, обмениваются только информацией, необходимой для работы;

· доступ к операциям и структурам модуля ограничен.

 

Достоинства информационной закрытости:

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

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

 

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

Типы вызовов модулей

А

В

В

А

С

А

В

а)

б)

в)

Условные и циклические вызовы модулей: а) – циклический; б) – условный; в) – однократный

Переход

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

На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние.

Сложные переходы

Выбор и соединение

Псевдосостояние выбора (choice pseudo state) предназначено для моделирования нескольких альтернативных ветвей при реализации поведения конечного автомата

Псевдосостояние соединения (junction pseudo state) является вершиной со свободной семантикой, которая используется для соединения вместе нескольких переходов

Разделение и слияние

Вершина разделения (fork vertex) – псевдосостояние, предназначенное для разделения входящего перехода на два или более перехода, которые имеют в качестве своих целей вершины в ортогональных регионах композитного состояния.

Вершина слияния (join vertex) – псевдосостояние, предназначенное для соединения нескольких переходов, которые имеют в качестве своих источников вершины из различных ортогональных регионов композитного состояния.

Точки входа и выхода

Точка входа (entry point) – псевдосостояние, предназначенное для моделирования входа в некоторый конечный автомат или композитное состояние

Точка выхода (exit point) – псевдосостояние, предназначенное для моделирования выхода из некоторого конечного автомата или композитного состояния

Псевдосостояние неглубокой истории (shallow pseudo state)

Псевдосостояние неглубокой истории (shallow pseudo state) предназначено для представления самого последнего активного подсостояния композитного состояния после выхода из него.

Псевдосостояние глубокой истории (deep pseudo state)

Псевдосостояние глубокой истории (deep pseudo state) предназначено для представления последней активной конфигурации композитного состояния после выхода из него.

Интерфейсы

 

Предоставляемый интерфейс (provided interface) – интерфейс, который компонент предлагает для своего окружения.

Требуемый интерфейс (required interface) – интерфейс, который необходим компоненту от своего окружения для выполнения заявленной функциональности, контракта или поведения.

Порт

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

Наличие имени у порта не является обязательным

При отсутствии имени порта его тип ассоциируется с типом интерфейса, с которым связан порт.

Собирающий соединитель
(assembly connector)

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

Делегирующий соединитель
(delegation connector)

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

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

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

Передача сообщений или сигналов, поступающих из некоторой внутренней части компонента, для обработки во внешний порт компонента

 

 

Узел(node)

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

На практике для уточнения спецификации узла могут использоваться различные текстовые стереотипы, которые акцентируют внимание на назначении этого узла.

Хотя в языке UML 2.х конкретные стереотипы для узлов не определены, разработчики предложили для этой цели следующие текстовые стереотипы:

«application server» (сервер приложений), «client workstation» (клиентская рабочая станция), «mobile device» (мобильное устройство), «embedded device» (встроенное устройство), «processor» (процессор), «sensor» (датчик), «modem» (модем), «net» (сеть), «printer» (принтер) и другие.

 

Понятие программного обеспечения, классификация программного обеспечения

 

Программное обеспечение - это совокупность программ, выполненных вычислительной системой.

К ПО относится также вся область деятельности по проектированию и разработке ПО.

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

Существует три категории ПО:

1) Прикладные программы, непосредственно обеспечивающие выполнение необходимых пользователям работ.

2) Системные программы:

• управление ресурсами ЭВМ.
• создание копий используемой информации.
• проверку работоспособности устройств компьютера.
• выдачу справочной информации о компьютере и др..

3) Инструментальные программные системы, облегчающие процесс создания новых программ для компьютера.

 

Более или менее определенно сложились следующие группы программного обеспечения:

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