Редактирование: МФСП, 01 лекция (от 03 сентября)

Материал из eSyr's wiki.

Версия от 20:22, 29 сентября 2010; 212.192.253.132 (Обсуждение)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

ПРЕДУПРЕЖДЕНИЕ: Вы редактируете устаревшую версию данной страницы. После сохранения страницы будут потеряны изменения, сделанные в последующих версиях.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

* '''Аудиозапись:''' http://esyr.org/lections/audio/mfsp_2008_winter/MFSP_08_09_03.ogg

Пргрммня инженерия
* ОО анализ и проектирование
* Верификация и м.
* ФСВП
* Тестирование
* Внедрение
** Интеграция с окружением
* Сопровождение
* Требование

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

На английском языке programming == coding. На русском оно имеет ещё один смысл.

Вообще, все 5 курсов есть, но не  все из них уложены в сетку ВМК.

Тестирование на моделях не читается нигде.

Ещё одно замечание методического плана. Цель преподавания --- передать знания. И чтобы мы в этом курсе научились, потребуется достаточно много энергии, лектор этому мешать не будет. В чём это будет выражаться: в лекционном материале почти ничего не будет про язык спецификации, его необходимо изучить самим.

Необходимо самостоятельно пострить кластеры двух понятий. (Кластер --- такя картинка, в середине которой рисуется овальчик и то понятие, которе нужно рассмотреть, например кластер "медицина", и от этого кружочка строите ассоциации, если косвенные, строить косвенные ассоциации, перекрёстные связи тоже желательны). Необходимо нарисовать два кластера --- "спецификация" и "верификация".

* Спецификация
...

* Верификация
...

В конце занятия лектор постарается выделить 4 минуты, чтобы мы эти кластеры пополнили. Это инструмент, который в конце некоего сеанса разговора позволяет разложить по полочкам те  знания, которые в этот период получили. Выписывание такого рода кластеров до и после, и получение дельты очень помогает усвоению материала. А кто этим не пользуется, лишает себя этой возможности.

Для того, чтобы всё это понимать, усваивать и использовать в жизни, хорошо  иметь представление, зачем это нужно. Многие классические курсы (матан, урматы) этой части уделяют мало внимания, хотя в реальной жизни многими подвергается сомнению, стоит ли учить подобным наукам студентов-программистов в таком объёме, и идут активные дискуссии.

Аналогично здесь, это академическая дисциплина или нет? Лектор сказал бы так: сфера применения этих методов вполне обширна и востербована:
* Ответственные  системы --- те, в которых риски ненадёжнсти, отказов очень высоки. Эти высокие риски бывают двух видов:
** Либо в экономических категориях (сумм ущерба)
** Либо в неколичественных характеристиках, определяющих безопасность

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

Системы подобного качества --- достаточный аргумент для использования методов спецификации и верификации? Если достаточно, то есть некий нонсенс: количество людей, которые понимают, что такое спецификация/верификация можно оценить как количество людей, которые это прослушали --- сотни тысяч. Реально работают порядка 10  тысяч преподавателей  и 10 тысяч в продакшене. А программистов миллионы.

Оценка процента верифицируемого аппаратного и программного обеспечения:
* АО ~90-95
* ПО ~1-5

Важно отметить, что верификация точно отвечает на вопрос, тестирование приблизительно.

На самом деле:
* HW --- IBM, Intel --- отдельные блоки, при этом самое большое достижение ---- блок работы с плавающей точкой, умножение и деление
* SW --- некоторые компьютерные верификации --- например, системы управления шлюзами, которые охраняют Голландию от навднения.

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

Если есть достаточно денег и есть достаточно признаков, то мы займёмся верификацией Этого достаточно?

Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет.

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

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

Поэтому верификация всегда идёт бок о бок с валидацией.

У заказчик есть требования и ожидания, неформальные. На основании требований можно строить спецификацию. Кроме того в реальной жизни на основе разговора с заказчиком можно делать и реализацию. Мы должны проверить соответствие между спецификациями требований (по анг. specification --- просто описание) и реализации. Эта проверка называется верификацией. А проверка между требования и ожиданиями заказчика и реализацией называется валидацией. Проверка соответствия спецификации требованиям и ожиданиям это тоже валидация, но это совершенно разные валидации. Целью первой является реализация. Вторя же должна рассматривать гораздо больше аспектов --- ... .

...

Примеры:
* abs(MIN_INT) --- ?
* Динамическя аллокация --- как описать, если внутреняя структура меняется?

Очень коротко о тех подходах, которые будут рассматриваться.

Почти всегда при решении сложных задач челвечество пользуется методом "разделять и властвовать". Например, нужно разработать крупную, хорошую программную систему. Для того, чтобы дну проблему решить, нужно разбить её на две части: спецификация и верификация. В реальной жизни, в результате того, что спецификации сделаны качественно, для разработчика нет тёмных пятен, он представляет как что делать, и верификация не нужна. Процесс спецификации мжет быть существенно более трудоёмким чем разработка, и общее количество ошибок вылавливается на этом этапе. Этот процесс это не просто написание бумаг, это процесс, связанный с анализом. Верификация --- задача тн. простая, поскольку мы задаёмся вопросом "как проверить соответствие". В спецификации есть два аспекта, связанных между собой, и  как их решать, надо придумывать каждый раз: что специфицировать и как специфицировать. Причём момент что тоже разделяется на две части: как неоформленные требования, потр., знания предметной области передать разработчикам спецификации и реализации. Понятно, что надо писать не всё. Документ должен быть компактным. Знания предметной области должны быть, но какие знания --- вопрос. Имеется три основных подхода, ответа на вопрос, как писать спецификацию:
* Use cases
* Sequence diagram
* SDL

...

--- написание посредника между спецификацией и прототипом. Это не всегда возможно, но это работает.

В любом случае между спецификацией и реализацией есть прослойка.

Для оценки нужно иметь зачёт по практикуму, суммарная оценка на экзамене складывается из оценки на коллоквиуме, на экзамене и, возможно, за практикум.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/%D0%9C%D0%A4%D0%A1%D0%9F%2C_01_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_03_%D1%81%D0%B5%D0%BD%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29