1. Автономное ПО. Устанавливается на одиночные компьютеры. Не имеет связи с другими программами. Например, Word, Excel.
2. Встроенное ПО. Уникальное приложение, которое требует для своей работы некоторые аппаратные средства. Например, автомобильный компьютер.
3. ПО реального времени. ПО, реагирующее в предсказуемое время на непредсказуемое появление внешних событий. Например, ПО для управления ядерным реактором.
4. Сетевое ПО. ПО, которое использует для своей работы вычислительные сети. Например, распределённая система вычислений.
Типичная схема разработки:
- Понять природу и сферу применения предлагаемого продукта
- Выбрать процесс разработки и создать план (как минимум разработать расписание)
- Собрать требования. (Выяснить требования и на их основе разработать спецификацию требований)
- Спроектировать и собрать продукт
- Выполнить тестирование продукта
- Поставить (выпустить) продукт и обеспечить его сопровождение
Шаги 1 и 2 выполняются 1 раз. Шаги 3-5 могут повторяться.
Компьютерные программы в дизайнерской работе: какие и для чего нужны
Дополнительный процесс – разработка документации.
Он выполняется на протяжении всего проекта на шагах 1-6.
С пункта 3 начинается разработка эксплуатационной документации, т.е.
той, которая поставляется вместе с продуктом.
Техническое задание – первый документ, который нужно разрабатывать.
Спецификация требований – второй документ, который нужно разрабатывать.
2. Жизненный цикл разработки программного обеспечения. Модели жизненного цикла программных продуктов. Классификации моделей жизненного цикла. Классификация технологических подходов, область применения групп подходов. Подходы со слабой формализацией, строгие (классические) подходы, гибкие (адаптивные, легкие) подходы.
ЖЦПО — весь период разработки и эксплуатации программного обеспечения, начинающийся с момента замысла и заканчивающийся завершением всех циклов его использования.
1. Модели со слабой формализацией — не используют явных технологий. Применяются для небольших проектов, которые часто завершаются созданием демонстрационного прототипа.
2. Строгие или классические (жёсткие) модели. Используются для средних, больших и гигантских проектов с фиксированным объёмом работ.
3. Гибкие адаптивные модели. Используются для небольших и средних проектов в случае неясных или изменяющихся требований.
Процесс — совокупность взаимосвязанных действий, потребляющих некоторые входные данные и преобразующие их в выходные
Стадия — Часть процесса работы над проектом, которая характеризуется вехой, завершающей стадию
Веха — контрольная точка проекта. Одномоментное идентифицируемое событие, сопровождающееся появлением некоторого отчуждаемого артефакта
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
«Дополнительные общеразвивающие программы нового поколения: нормативные требования, особенности прое
Обзор автономных приложений
Чтобы просматривать веб-сайт, нужно подключиться к интернету. На сегодняшний день все это знают. Так зачем же тогда нужно рассматривать автономные приложения? Как будто мы собираемся вернуться в прошлое столетие. В конце концов, разве на своем пути к мировому господству веб-приложения не сбросили владычество нескольких поколений автономных настольных приложений?
Осуществление множества разнообразных задач — от записей в социальной сети до покупки книг в интернет-магазине — просто невозможно без подключения к интернету. Но не стоит забывать, что даже веб-приложения не предназначены для обязательного постоянного пребывания в Сети. В них заложена возможность продолжать работу в периоды временного отсутствия подключения к интернету. Иными словами, автономное веб-приложение допускает временные сетевые отказы.
Это обстоятельство имеет особо важное значение для посетителей, пользующихся для доступа к сети портативными устройствами, такими как смартфоны и планшетные компьютеры с возможностью веб-доступа. Чтобы понять суть данной проблемы, представьте себе, что вы работаете с веб-приложением на одном из таких устройств, находясь в поезде, и в это время поезд въезжает в туннель. Шансы велики, что ваше веб-приложение выдаст сообщение о неисправимом сбое и вам придется начать все заново, когда поезд выедет из туннеля и восстановится подключение к интернету.
А вот автономное веб-приложение позволит избежать такого неблагоприятного развития событий. Хотя некоторые возможности могут стать временно недоступными, приложение в основном останется работоспособным. (Опять же, некоторые туннели длиннее других. Амбициозное автономное приложение может продолжать работу на протяжении трехчасового авиарейса или трехнедельного путешествия по Африке, если это то, что вам нужно. По сути, время нахождения в автономном режиме ничем не ограничено.)
Кэширование файлов с помощью манифеста
Основным техническим приемом, который делает автономный режим работы возможным, является кэширование — загрузка файла с веб-сервера и сохранение его копии на жестком диске клиента. Таким образом, при потере интернет-подключения браузер сможет использовать копию страницы, сохраненную в кэше.
Для создания страницы с возможностью работы в автономном режиме нужно выполнить следующие три шага:
- Создать файл манифеста. —- это специальный файл, в котором хранится информация, указывающая браузерам, какие файлы следует сохранять, какие не сохранять, а какие файлы заменять каким-либо другим содержимым. Этот пакет кэшируемого содержимого называется автономным приложением (offline application).
- Модифицировать веб-страницу, чтобы она обращалась к манифесту. Таким образом, браузер будет знать, что при запросе страницы нужно загрузить файл манифеста.
- Настроить веб-сервер. Самое важное — веб-сервер должен предоставлять файл манифеста с правильным MIME-типом.
В области веб-разработки кэширование не представляет собой ничего нового. Браузеры регулярно кэшируют содержимое, чтобы не загружать повторно одни и те же файлы. В конце концов, если несколько страниц веб-сайта используют один и тот же файл таблицы стилей, зачем загружать его для каждой страницы? Но механизм управления этим типом кэширования отличается от механизма работы автономных приложений.
Традиционное кэширование выполняется, когда вместе с запрошенным браузером файлом веб-сервер отправляет дополнительную информацию, которая называется . Эти заголовки предоставляют браузеру информацию о том, следует ли кэшировать данный файл и на протяжении какого времени использовать котированную копию, прежде чем запрашивать у веб-сервера, не изменился ли этот файл. Обычно, кэшированная копия содержимого веб-страниц хранится короткое время; намного дольше хранятся кэшированные копии ресурсов, используемых вебстраницами, таких как таблицы стилей, изображения и файлы сценариев.
В противовес, автономное приложение управляется отдельным файлом — манифестом, и длительность его хранения не управляется временными лимитами. Вместо временных лимитов используется следующее правило: если веб-страница является частью автономного приложения, если имеется кэшированная копия этого приложения и если определение этого приложения не претерпело никаких изменений, тогда используется кэшированная копия.
Веб-разработчик может добавить к этому правилу определенные исключения и дополнения, например, указать браузеру не кэшировать определенные файлы или заменить один файл каким-либо другим. Но ему нет надобности заботиться о сроках хранения и других, потенциально проблематичных подробностях.
Создание манифеста
Манифест является центральной частью предоставления автономной работы HTML5. Это текстовый файл, содержащий список файлов, которые нужно кэшировать. Файл манифеста всегда начинается словами (прописными буквами):
CACHE MANIFEST
После этого заголовка следует список файлов, которые нужно кэшировать. Далее приведен пример файла манифеста для кэширования двух веб-страниц:
CACHE MANIFEST MyPage1.html MyPage2.html
Интервалы (как пустая строка в приведенном примере манифеста) не обязательны, можете вставлять их в любом месте.
Для автономного приложения браузер должен кэшировать все, что может потребоваться этому приложению: веб-страницы и ресурсы, используемые этими вебстраницами (например, сценарии, графику, таблицы стилей и встроенные шрифты). Далее приведен пример более подробного манифеста со всеми типами файлов:
CACHE MANIFEST # pages MyPage1.html MyPage2.html # styles https://professorweb.ru/my/html/html5/level6/6_1.php» target=»_blank»]professorweb.ru[/mask_link]
Автономность или автоматизация?
Современное программное обеспечение продолжает эволюционировать, обещая новые возможности, многие из которых имеют все шансы оказать глубокое влияние на развитие отрасли. Следующее поколение системного и прикладного ПО может стать основой так называемых автономных операционных систем, систем управления и бизнес-приложений, прежде всего – облачных, например, СУБД или ERP-систем. Задействованные в них технологии машинного обучения и искусственного интеллекта (ИИ) будут использоваться для автоматизации управления, устранения ручных операций и исключения человеческих ошибок. Результатами должны стать повышение производительности, доступности и безопасности, снижение затрат на администрирование ИТ.
По прогнозу Forrester, автоматизация «окажется на острие цифровой трансформации, затрагивая буквально все — от инфраструктуры до обслуживания клиентов и появления новых бизнес-моделей». Как ожидается, в течение ближайшего года автоматизация устранит до 20% обращений в службы поддержки благодаря успешному сочетанию когнитивных систем, технологий RPA и чат-ботов. Сегодня отрасль выходит за рамки простой автоматизации, но еще не достигла уровня автономности, который позволил бы ИТ-системам функционировать полностью самостоятельно, без участия человека.
Автоматизация и автономность: в чем разница?
Автономность нередко путают с автоматизацией. Оба направления нацелены на избавление человека от рутинной работы. Между тем от автоматизации до автономности – путь неблизкий. Автоматизация обычно означает «процесс, выполняемый без помощи человека» по заданным правилам, в то время как автономия подразумевает «способность функционирования системы в неопределенных заранее условиях и устранять сбои без внешнего вмешательства».
Автоматизированные системы обычно работают в пределах четко определенного набора параметров и правил, они ограничены в своих действиях. Они созданы для многократного и эффективного выполнения определенной функции, могут предпринимать определенные действия для устранения проблемы, но это не означает, что они автономны.
Тем временем автономные ИТ-системы уже научились прогнозировать сбои, управлять операциями и адаптироваться к работе пользователя. И наверняка эти системы в конечном итоге станут еще более независимыми. Они способны определять, какое решение или действие будет наиболее правильным в недетерминированной среде, но все еще требуют участия человека для программирования набора правил или обучения моделей в системах машинного обучения. Им еще предстоит научиться сопоставлять события, выявлять закономерности, предсказывать сбои и предпринимать действия независимо от людей, адаптироваться к изменяющимся условиям и целям.
Что эффективнее?
Автономная система обучается и адаптируется к динамически меняющимся средам, способна извлекать уроки из накапливаемых наборов данных. Однако, если нужна система с высокой предсказуемостью и многократно выполняющая одну и ту же функцию, то оптимальный вариант — автоматизированная система, поскольку она проще, требует меньше ресурсов, ее легче обслуживать.
Автономные системы демонстрируют свои лучшие качества в средах, где неизвестны заранее все условия, и нужна адаптация/обучение по мере изменения среды и входных данных. Однако из-за высокой стоимости и сложности их применение считается избыточным для решения задач, с которыми справляются средства автоматизации.
В целом мониторинг и автоматизация достаточны для устранения относительно простых проблем в ИТ-системах, а для решения более сложных, комплексных проблем может потребоваться применение ИИ.
Автономность в ИТ
Примером автономной системы является система обнаружений вторжений путем поиска аномалий в сетевом трафике. Автономные системы наиболее эффективны в постоянно меняющемся ландшафте угроз, например, когда появляются новые векторы атаки, но им необходим доступ к наборам данных, на которых можно обучаться. Они используют машинное обучение (ML), чтобы блокировать попытки атак, способны находить эксплойты нулевого дня.
Для работы в постоянно меняющейся среде с растущим числом векторов атак без какой-либо формы встроенного интеллекта не обойтись. Когда злоумышленники меняют методы атаки, эти системы учатся идентифицировать их, используя дополнительные данные, улучшенные алгоритмы или более продвинутые методы обучения.
Между тем машинное обучение может применяться как в автоматизированных, так и в автономных системах. Его можно использовать для повышения «уровня интеллекта», чтобы свести к минимуму количество ложных срабатываний, а также предвидеть потенциальные отказы и сбои.
Новые автономные технологии — самоуправляемые базы данных и другие высокоавтоматизированные сервисы облачных платформ — используют алгоритмы машинного обучения для непрерывного самоисправления, самонастройки, резервного копирования и самобновления без вмешательства человека, прямо во время работы системы.
Например, как утверждают разработчики, облачная автономная база данных Oracle Autonomous Database берет на себя такие ранее выполняемые вручную и подверженные ошибкам задачи как обновление системы, ее защита, конфигурирование и настройка — все это без простоев и вмешательства человека. Эта же технология стала основой ОС Oracle Autonomous Linux. Исправления и обновление система выполняет автоматически.
ИИ встроен в систему управления HPE Infosight. Задача этого специализированного ПО — решать проблемы в ИТ до того, как они нанесут ущерб бизнесу. С увеличением объемов обрабатываемых данных усложняется и ИТ-инфраструктура. Большое количество серверов, систем хранения, коммуникационного оборудования и приложений не всегда корректно взаимодействуют друг с другом.
Это приводит к проблемам и простоям. В такой ситуации на помощь приходит ИИ. Подобных примеров становится все больше.
Аналитики Gartner прогнозируют, что только в 2021 году внедрение ИИ принесет бизнесу 2,9 трлн. долларов. Со временем системы с ИИ станут более надежными и эффективными, обретут способность справляться с большими сложностями, получат большую самостоятельность при принятии решений.
Коментарии: 2
Комментировать могут только авторизованные пользователи.
Предлагаем Вам войти в систему или зарегистрироваться.
Рейтинг: 13
ПК ГПИ Челябинскгражданпроект
Начальник отдела автоматизации проектирования
23.01.2020 09:12
Новые технологии, это интересно, но вы забыли упомянуть, что между автоматизацией на классических алгоритмах и автономностью, использующей технологии нейронных сетей, есть ещё одно существенное отличие.
В случае незапланированного или ошибочного поведения систему автоматизации на классическом алгоритме можно проанализировать и устранить её неправильное поведение, исправив алгоритм. А вот в случае с автономной системой, которая строится на базе нейронной сети, такой анализ на сегодняшний день провести практически невозможно, поскольку полного понимания того, как внутри функционирует нейронная сеть, у нас до сих пор нет. Мы научились их обучать и использовать на практике, но не можем однозначно предсказывать их поведение, как это можно сделать с классической алгоритмической системой.
Да, нейронную сеть можно дообучить, чтобы исключить выявленные ложные срабатывания. Но это при условии, что первичное обучение тоже проводилось именно вами, а не поставщиком системы, поскольку в последнем случае вы получаете ваш ИИ как некий «чёрный ящик» с уже заданными поставщиком свойствами.
Ещё одна проблема, которая отсюда вытекает, это невозможность определить, какие на самом деле функции и возможности, помимо заявленных, заложены в поставляемую вам систему. То есть, тут остаётся только верить поставщику системы на слово. Согласен, что сегодня подобный тщательный контроль поведения алгоритмических систем тоже мало кто проводит.
Но есть целый класс задач, где это делается. Поэтому многие серьёзные профессиональные системы поставляются вместе с исходным кодом. В том же мире UNIX/Linux это давно устоявшаяся практика. А в случае с автономной системой, построенной на базе нейронных сетей, исходный код программы вам ничего не даст, поскольку поведение системы определяется на программным кодом, а матрицей коэффициентов нейронной сети. И глядя на эти многомерные массивы чисел мы на данный момент не можем однозначно определять поведение нейронной сети и не можем однозначно предсказать, как изменение того или иного коэффициента повлияет на общее поведение нашей системы.
Рейтинг: 56
Независимый эксперт
10.02.2020 16:42
Здравствуйте, Дмитрий! Спасибо за комментарий. Вы правы, есть такая проблема. Однако существуют ситуации, когда точные алгоритмы могут быть менее эффективными, например, в системах безопасности при обнаружении угроз. Кроме того, совершенствование алоритмов ML позволяет настолько снизить риски, что им доверяют весьма ответственные задачи, как, например, анализ изображений в беспилотных автомобилях.
Источник: globalcio.ru