Теория систем и системный анализ. : Модель программного

и его особенности»





Выполнил студент 3 курса
Мизер Александр.

поведении и работе, каков регламент отношений между членами команды, как

проект взаимодействует с внешним миром и т.д.? Все это вместе мы склонны называть процессом. Его осознание, выстраивание и улучшение - основа любой эффективной групповой деятельности. Поэтому не случайно, что процесс оказался одним из основных понятий программной инженерии.
Центральным объектом изучения программной инженерии является процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.).
Однако на сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI, Scrum и др.
В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом. Последний, таким образом, оказывается некоторой базой данных, содержащей следующее:
информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования – различных IDE, СУБД и т.д.);
описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.;
шаблоны проектных документов – технических заданий, проектных спецификаций, планов тестирования и т.д. и пр.

метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов

деятельности, то есть, определяетмодель процесса (process model).
Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако, сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель – самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И стали развиваться интегральные методологии разработки. Тем не менее существует несколько классических моделей процесса, которые полезны на практике и которые будут рассмотрены ниже.
Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.
Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.
Редко какой заказчик согласится первый раз увидеть результаты только после завершения проекта. С другой стороны, подрядчики предпочитают получать деньги постепенно, по мере того, как выполняются отдельные части работы. Таким образом, появляются фазы, позволяющие создавать и предъявлять промежуточные результаты проекта. Фазы полезны также безотносительно взаимодействия с заказчиком – с их помощью можно синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение проекта. Примерами фаз может служить согласование с заказчиком технического задания, реализация определенной функциональности ПО, этап разработки, оканчивающийся сдачей системы на тестирование или выпуском альфа-версии.
Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.
В рамках одной фазы может выполняться много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах – например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО.

программного процесса, представленное с некоторой точки зрения. Модель задается в

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

К первым типам моделей (модели жизненного цикла) относятся модели, в которых описывается порядок выполнения действий по созданию продукта. К наиболее известным моделям относятся:
Водопадная (каскадная) модель – процесс разбивается но последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям.
Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований.
Компонентная модель предполагает сборку продукта из заранее написанных частей – компонент. Основной упор делается на интеграцию и совместное тестирование компонент.
Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям.
Следует отметить, что различия между этими моделями существуют только в теории. На практике спиральная модель может быть дополнена элементами каскадной и компонентной. Задача программного инженера – подобрать правильную их комбинацию, ориентируясь только на конечный результат.
Ко второму типу моделей – моделей организации работ относятся:
Модель потока работ (workflow model) — показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам.
Модель потоков данных (data flow model) — представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями.
Ролевая модель — показывает роли людей, участвующих в программном процессе, а также действия и результаты, за которые они отвечают.

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

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

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





Далее более подробно о каждом из этих пунктов.

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

(англ.use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования ,которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества , или проектные ограничения).
В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

последовательность восприятия
Масштаб проекта
Ссылки на источники
Общее описание
Видение продукта
Функциональность продукта
Классы и характеристики

пользователей
Среда функционирования продукта (операционная среда)
Рамки, ограничения, правила и стандарты
Документация для пользователей
Допущения и зависимости
Функциональность системы
Функциональный блок X (таких блоков может быть несколько)
Описание и приоритет
Причинно-следственные связи, алгоритмы (движение процессов, workflows)
Функциональные требования
Требования к внешним интерфейсам
Интерфейсы пользователя (UX)
Программные интерфейсы
Интерфейсы оборудования
Интерфейсы связи и коммуникации
Нефункциональные требования
Требования к производительности
Требования к сохранности (данных)
Критерии качества программного обеспечения
Требования к безопасности системы
Прочие требования
Приложение А: Глоссарий
Приложение Б: Модели процессов и предметной области и другие диаграммы
Приложение В: Список ключевых задач

процесс, направленный на создание и поддержание работоспособности, качества и надежности

программного обеспечения, используя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.
Как и другие традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы строк исходного кода, которые, как ожидается, должны правильно исполняться в изменяющихся условиях.
Разработка программного обеспечения может быть разделена на несколько разделов. Это:
Требования к программному обеспечению: извлечение, анализ, спецификация и ратификация требований для программного обеспечения.
Проектирование программного обеспечения: проектирование программного обеспечения средствами Автоматизированной Разработки Программного Обеспечения (CASE) и стандарты формата описаний, такие как Унифицированный Язык Моделирования (UML), используя различные подходы: проблемно-ориентированное проектирование и т. д.
Инженерия программного обеспечения: создание программного обеспечения с помощью языков программирования.
Тестирование программного обеспечения: поиск и исправление ошибок в программе.
Сопровождение программного обеспечения: программные системы часто имеют проблемы совместимости и переносимости, а также нуждаются в последующих модификациях в течение долгого времени после того, как закончена их первая версия. Подобласть имеет дело с этими проблемами.
Управление конфигурацией программного обеспечения: так как системы программного обеспечения очень сложны и модифицируются в процессе эксплуатации, их конфигурации должны управляться стандартизированным и структурированным методом.
Управление разработкой программного обеспечения: управление системами программного обеспечения имеет заимствования из управления проектами, но есть нюансы, не встречающиеся в других дисциплинах управления.
Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.
Инструменты разработки программного обеспечения, см. CASE: методика оценки сложности системы, выбора средств разработки и применения программной системы.
Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.
Локализация программного обеспечения, ветвь языковой промышленности.

считают:
Недостаток прозрачности. В любой момент времени сложно сказать, в каком

состоянии находится проект и каков процент его завершения. Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объём выполненной и оставшейся работы. Данная проблема возникает на этапе, когда проект, завершённый чуть более чем наполовину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.
Недостаток трассировки.
Недостаток мониторинга: Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени. Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы.
Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств. Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.
Недостаточная надёжность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали Кнут, Дейкстра и Вирт. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках. Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.
Неправильный выбор методологии разработки программного обеспечения. Процесс выбора необходимой методологии может проблемно отразиться на всех показателях программного обеспечения - это его гибкость, стоимость и функциональность. Так называемые гибкие методологии разработки помогают решить основные проблемы, однако, стоит отметить, что и каскадная модель (waterfall) так же имеет свои преимущества. В некоторых случаях наиболее целесообразным будет применение гибридных методологий в связке Agile + каскадная модель + MSF + RUP и т.д.
Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам. Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

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

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

Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых. Качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
надёжность,
сопровождаемость,
практичность,
эффективность,
мобильность,
функциональность.
Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998.

производительности классификацию видов тестирования. Обычно выделяют следующие:
По объекту тестирования
Функциональное тестирование
Нагрузочное

тестирование
Стресс-тестирование
Тестирование стабильности
Конфигурационное тестирование
Юзабилити-тестирование
Тестирование интерфейса пользователя
Тестирование безопасности
Тестирование локализации
Тестирование совместимости
По знанию системы
Тестирование чёрного ящика
Тестирование белого ящика
Тестирование серого ящика
По степени автоматизации
Ручное тестирование
Автоматизированное тестирование
Полуавтоматизированное тестирование
По степени изолированности компонентов
Модульное тестирование
Интеграционное тестирование
Системное тестирование
По времени проведения тестирования.

Альфа-тестирование

Дымовое тестирование (англ. smoke testing)
Тестирование новой функции (new feature testing)
Подтверждающее тестирование
Регрессионное тестирование
Приёмочное тестирование
Бета-тестирование
По признаку позитивности сценариев
Позитивное тестирование
Негативное тестирование
По степени подготовленности к тестированию
Тестирование по документации (формальное тестирование)
Интуитивное тестирование (англ. ad hoc testing)

отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.
Интеграционное тестирование —

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

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

жизненного цикла.

стадии основное внимание уделяется определенным группам видов деятельности, а именно:.
■

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


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