Реферат Метелица. Реферат Дисциплина Информатика и основы программирования
 Скачать 279.5 Kb.
|
|
ФГБОУ Дальневосточный государственный университет путей сообщения Кафедра: ИТиС БИЗНЕС АСПЕКТЫ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ Реферат Дисциплина: «Информатика и основы программирования». Выполнил: Метелица И.А. Проверила: Ямполь Е.С. Хабаровск 2022г. ПРОГРАММНЫЕ СИСТЕМЫ Программная система (Software system) - система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения (OMG Essence). OMG Essence является результатом работы инициативы SEMAT (инициатива по превращению программной инженерии в настоящую научно-техническую дисциплину). SEMAT – это не метод , он не конкурирует с agile-подходами (серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. В системной инженерии “железных” систем методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО) или “водопадом” (классическая модель жизненного цикла, в которой жизненный цикл выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Отдельные практики выполняются последовательно, как вода проходит каскад. Все рабочие продукты стадий проходят передачу на следующую стадию, и дальше не меняются, а используются для получения продуктов этой стадии. Ключевая предпосылка “водопада” — это то, что практики совпадают со стадиями жизненного цикла. То есть “проектирование” — это и практика, и стадия жизненного цикла. “Тестирование” — это и практика, и название жизненного цикла) , а подкрепляет их, делает лучше и при этом позволяет быстро понять, в каком состоянии находится проект. В каждой организации применяются самые разные языки программирования, среды и методологии разработки, но без единой платформы SEMAT они будут существовать сами по себе, без взаимосвязей с единой проектной структурой. Цели и задачи SEMAT Главная задача SEMAT стоит в выработке нового набора типов компонент метода, по составу которого будет достигнут не столько "научный результат", но общественное согласие. По факту, основатели SEMAT хотят повторить успех UML в области SME — в начале 90-х по поводу UML договорились между собой представители самых разных методологий разработки и соответствующих им языков ОО-моделирования. Результат известен, UML сегодня "царь горы". Те же самые люди, которые занимались унификацией UML из своих разнородных подходов в середине 90-х, возглавляют теперь SEMAT. Тем самым развитие SME приобретает еще и социальное измерение: способ задания в SEMAT онтологии метода упирает на "разделяемость" (shared) множеством людей, как основное свойство онтологии — когда они получат результат (набор компонент метода), по факту под этим результатом подпишутся множество людей, и SEMAT будет претендовать на статус "стандарта де-факто". Концепция SEMAT 1.Ядро. Под всеми методологиями лежит единое ядро. Ядро не “математично”, а представляет собой скорее экспертные суждения. Главный принцип его формирования таков: использовать только то,, что нужно абсолютно всем. При этом, конечно, пользователи могут добавлять собственные проектные практики, которые описываются в терминологии ядра и таким образом становятся более понятными. -Альфы. Ядро само по себе очень компактно, а основная работа с помощью SEMAT строится на так называемых “альфах”, абстрактных атрибутах, которые изменяются в проекте, и изменения которых нужно понимать, отслеживать, обеспечивать, направлять, контролировать. 2.Язык. Так как разработчики документацию и книги практически не читают, им нужно предоставить интуитивно понятный графический синтаксис. Эффект от него поразительный. 3. Практики - последовательность действий, совершаемых в рабочих процессах. Практики описываются элементами Ядра. 4.Методы – наборы практик. В стандарте ONG Essence можно выделить две части: -Язык для описания метолов программной инженерии -Сущности для методов такой предметной области, как программная инженерия. Язык Язык основ – это минимальный набор понятий, в терминах которых описываются методы программной инженерии. Особое внимание тут уделялось минимальности языка. Язык не ограничен именно программной инженерией, но особо оговорено, что никаких пока приложений к другим областям не было. "Описывать в терминах" — это означает использовать мета-язык. Основы вводят четыре уровня этих "мета“ для описания: 0 – жизнь (экземпляры времени выполнения, объекты в реальной жизни) 1 - ситуационный метод/сущности (конкретные ядра и практики — "требования", "прописать сценарии использования"). 2 - мета-модель/язык (понятия языка Основ — ядро, альфа, рабочий продукт, действие, компетенция и т.д.) 3 – meta-language (мета-класс, отношение и т.д.) Мета-модель  Язык Основ предписывает использовать следующие термины-конструкты: -Практика (Practice) Постоянные действия, направленные на достижение какой-то цели. -Альфа (Alpha) Элемент, который требует отслеживания для успеха разработки, что будет продвигаться работами по последовательности состояний, которые проверяются ответами на контрольные вопросы. -Рабочий продукт (Work Product) Артефакт (документ, кусок программного кода, какая-то созданная сущность). Вводится понятие "уровни проработки" рабочего продукта, которые проверяются ответами на контрольные вопросы. -Деятельность (Activity Space) Указание на что-то, что должно быть сделано в процессе разработки программного обеспечения. Деятельность может включать в себя несколько дел или не включать ни одного. -Дело (Activity) набор работ и указания по их выполнению -Компетенция (Competency) Возможности, способности, знания и умения, необходимые для выполнения определенной работы. Для каждого члена команды может быть определен набор и уровень компетенций. -Шаблон (Pattern) Связки сущностей и их отношений - стадии жизненного цикла и даже роли вводятся паттернами -Ресурс (Resource) То, что будет использоваться без изменений при переносе из метода в жизнь: шаблоны, примеры, руководства, курсы для получения компетенций и т.д. -Ядро (Kernel) Набор элементов, формирующий общее описание деятельности (endeavor), определяющий базовые концепции (альфы, деятельности, компетенции и т.д.) и предметную область -Метод (Method) Сочетание ядра и набора практик для достижения определенной цели. Из 250 практик составляются тысячи и тысячи методов, в зависимости от ситуации. Важно, что метод не становится организационной догмой, он эволюционирует в ходе разработки (практики в методе меняются). Для методов определены способы их задействования (enactment), вплоть до того, что стандарт позволяет формально подсказывать, что когда можно делать (для этого может быть использован традиционный для OMG язык ограничений - OCL). -Область интересов (Area of Concern) Все элементы практик и ядра попадают в одну из трёх областей интересов Области интересов  В терминах-конструктах Языка описываются абстрактные сущности (kernel) для программной инженерии, имеющие определяемые Языком типы. Эти сущности разбиты на три области интересов: - Клиент (Customer) исследовать возможности; понять нужды заинтересованных сторон; обеспечить удовлетворение заинтересованных сторон; использовать систему. - Решение (Solution) понять требования; смоделировать (shape) систему; изготовить систему; тестировать систему; развернуть (deploy) систему; управлять (operate) системой. - Деятельность (Endeavor) приготовиться к выполнению работы; координировать дела; поддерживать команду; отслеживать прогресс; остановить работу. Карточки Стандарт вводит кроме графического и текстового языков для описания практик ещё и представление на карточках - когда для каждого состояния альфы делается отдельная карточка с представлением чеклиста. А потом для каждой альфы выкладывается ряд этих карточек с группировкой состояний по разным принципам: - Уже достигнутые, в работе, ещё не достигнутые (оценка состояния дел в проекте). - Те, которые будем достигать мы, и которые были достигнуты или будут достигнуты другими. - Те, которые будут достигнуты на текущем шаге/итерации/спринте (планирование шага работы). КЛАССИФИКАЦИЯ ПРОГРАММНЫХ СИСТЕМ - Встроенные программные системы, их также называют системы реально времени или социотехнические системы - Программно насыщенные системы - Вычислительно-ориентированные системы
ПРЕДСТАВЛЕНИЕ АРХИТЕКТУРЫ Представление дизайна является очень важным для проведения анализа архитектуры, также это гарантирует, что все реализовано правильно. Дизайн архитектуры должен быть представлен всем заинтересованным сторонам, включая группу разработки, системных администраторов и операторов, владельцев бизнеса и др. Существует несколько широко известных методов описания архитектуры для ее представления: - 4+1 (предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных групп описания): 1. Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования). 2. Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов. нефункциональные требования к системе, включая производительность и доступность. 3. Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы. фактическая организация модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо. 4. Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки. нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть). 5. Представление сценариев объединяет все 4 представления вместе. - Гибкое моделирование (Метод описания архитектуры программной системы, который следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей. Простота документа гарантирует активное участие заинтересованных сторон в моделировании артефактов). - ISO 42010 (ранее IEEE 1471) (Стандарт, разработанный для управления архитектурным описанием сложных систем, позволяет установить, что у деятельности, а значит и у жизненный цикл и его практик, как у любой системы, есть одна или несколько заинтересованных сторон). - UML (обеспечивает три представления модели системы): 1. Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования). 2. Статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов). 3. Представление динамического поведения (взаимодействие объектов и изменения внутреннего состояния объектов, включая диаграммы последовательностей, деятельностей и состояний). СОСТОЯНИЯ OMG Essence определяет следующие состояния для альфы "Программная система" и контрольные вопросы для проверки каждого состояния:
ВЫВОД В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Тенденции развития современных информационных технологий определяют постоянное возрастание сложности ПО ЭИС. Современные крупные проекты ЭИС характеризуют, как правило, следующие особенности: - Сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов. - Наличие совокупности тесно связанных подсистем, имеющих локальные задачи и цели функционирования. - Отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем. - Необходимость интеграции существующих и вновь разрабатываемых приложений. - Функционирование в неоднородной среде на нескольких аппаратных платформах. - Разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств. - Значительная временная протяженность проекта, обусловленная с одной стороны, ограниченными возможностями коллектива разработчиков и различной степенью готовности отдельных ее подразделений к внедрению ЭИС. Для успешной реализации проекта объект проектирования (ПО ЭИС) должен быть прежде всего адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПО, включающие совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы. ИСТОЧНИКИ http://sewiki.ru/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 https://www.sibsau.ru/sveden/edufiles/142362/ https://referatbooks.ru/referat/biznes-aspektyi-razrabotki-programmnyih-sistem/ |