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

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

---

Версия 15:04, 12 сентября 2008

Пргрммня инрженерия

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

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

На английском языке 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

...

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

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

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