Редактирование: МФСП, 01 лекция (от 03 сентября)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 1: | Строка 1: | ||
* '''Аудиозапись:''' http://esyr.org/lections/audio/mfsp_2008_winter/MFSP_08_09_03.ogg | * '''Аудиозапись:''' http://esyr.org/lections/audio/mfsp_2008_winter/MFSP_08_09_03.ogg | ||
- | + | Пргрммня инрженерия | |
- | * | + | * ОО анализ и проектирование |
- | * Верификация и | + | * Верификация и м. |
* ФСВП | * ФСВП | ||
* Тестирование | * Тестирование | ||
- | * | + | * Внедерние |
** Интеграция с окружением | ** Интеграция с окружением | ||
- | * | + | * Сопровождление |
* Требование | * Требование | ||
- | + | Внедерние, Интеграция с окружением, Сопровождление, Требование --- бычно называют технологиями программирования | |
На английском языке programming == coding. На русском оно имеет ещё один смысл. | На английском языке programming == coding. На русском оно имеет ещё один смысл. | ||
Строка 17: | Строка 17: | ||
Вообще, все 5 курсов есть, но не все из них уложены в сетку ВМК. | Вообще, все 5 курсов есть, но не все из них уложены в сетку ВМК. | ||
- | Тестирование на | + | Тестирование на мделях нечитется нигде. |
- | Ещё одно | + | Ещё одно замечние методического плана. Цель преподавания --- передать знания. И чтобы мы в этом курсе научились, потребуется дстаточно много энергии, лектор этому мешать не будет. В чём это будет выржаться: в лекционном материале почти ничего не будет про язык спецификации, его небх. изучить самим. |
- | + | Необх. самост. пострить кластеры двух понятий. (Кластер --- такя картинка, в середине которой рисуется овальчик и то понятие, которе нужн рассмотреть, например кластер "медицина", и от этого кружочк строите ассоциации, если ксвенные, строить косвенные ассоциации, перекр. связи тоже желтельны). Необх. нарисовать два кластера --- "спецификация" и "верификция". | |
* Спецификация | * Спецификация | ||
Строка 29: | Строка 29: | ||
... | ... | ||
- | + | В конце занятия лектр постарается выделить 4 минуты, чтбы мы эти кластеры пполнили. Это интсрумент, который в конце некоего сеанс разговор позв. рзлжить по полочкам те знания, которые в этот период получили. Выписывание такого рода клстеров до и псле, и получение дельты очень помогает усвоению материала. А кт этим не пользуется, лишает себя этой возможности. | |
- | Для того, чтобы всё это понимать, | + | Для того, чтобы всё это понимать, усвивать и исп. в жизни, хорошо иметь представление, зачем это нужно. Многие классмяеские курсы (матан, урматы) этой части уделяют мало внимания, хотя в реальной жизни многими подвергается сомнению, стоит ли учить подобным нукам студентв-программиств в таком объёме, и идут активные дискуссии. |
- | Аналогично здесь, это | + | Аналогично здесь, это академическя дисциплина или нет? Лектор сказал бы так: сфера применения этих методов вплне обширна и востербована: |
- | * Ответственные | + | * Ответственные системы --- те, в которых риски ненадёжнсти, отказов очень высоки. Эти высокие риски бывают двух видов: |
** Либо в экономических категориях (сумм ущерба) | ** Либо в экономических категориях (сумм ущерба) | ||
** Либо в неколичественных характеристиках, определяющих безопасность | ** Либо в неколичественных характеристиках, определяющих безопасность | ||
- | Заметьте, что здесь | + | Заметьте, что здесь лектор нмеренно не написал "программные системы", нас интересуют системы упрвления, а это не только программы, и забывать ни один из факторов нельзя --- машины, линии связи, протоколы, системное ПО, прикладное ПО --- всё это должно быть высокого качества в отв. системе. |
- | Системы подобного | + | Системы подобного качества --- достаточный аргумент для исп. методов спецификации и верификации? Если достаточно, то есть некий нонсенс: количество людей, которые понимют, что таке спец./вериф. можно оценить как количество людей, которые это прослушали --- сотни тысяч. Реально рботают порядка 10 тысяч преподавателей и 10 тысяч в продакшне. А программистов миллионы. |
- | Оценка процента | + | Оценка процента верифицируемоно апп. и прогр. обесп.: |
* АО ~90-95 | * АО ~90-95 | ||
* ПО ~1-5 | * ПО ~1-5 | ||
- | Важно отметить, что | + | Важно отметить, что верификция точно отвечает на вопрос, тестирование приблизительно. |
На самом деле: | На самом деле: | ||
- | * | + | * HW --- IBM, Intel --- отдельные блоки, при этом самое большое достижение ---- блок работы с пл. точкой, умножение и деление |
- | * | + | * SW --- некоторые комп. вериф. --- напр., системы упр. шлюзами, которые охр. Голландию от навднения. |
- | + | Верифицирванное ПО будет стоить минимум в 20 рз дороже. В самой вериф. высоки риски, что рез. вериф. не даст 100-прцентной гарантии, поск. там делуются мат. точные выч. н осн. неких предп., и всё зависит от них. Кроме того, это соц. и человеч. фактор. Обл. молодая, и в случе, когда мало специалиств, риски велики. | |
- | Если есть | + | Если есть дост. денег и есть дост. признаков, то мы займёмся вериф. Этого достаточно? |
Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет. | Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет. | ||
- | + | Верификция на самом деле это очень просто. Но для этого нужна спецификация, а она есть не всегда. | |
- | Сейчас самый ходовой | + | Сейчас самый ходовой пролдукт --- порталы. Для заказчикв этих порталов сказать, что они там хотят видеть, абсолютно невозможно. А когда разраб. делает по крайней мере прототип, то уже можно сказать, чт нравится, что нет. |
- | Поэтому | + | Поэтому вериф. всегда идёт бок о бок с влидацией. |
- | У заказчик есть требования и ожидания, | + | У заказчик есть требования и ожидания, нефромальные. На основании требований можно строить специфкацию. Кроме того в реальной жизни на основе разг. с заказчиком можно делать и реализцию. Мы должны проверить соответствие между спецификациями требований (по анг. specification --- просто описание) и реализц. Эта проверка называется верификацией. А прверка между треб. и ожид. заказчика и реализацией наз. валидацией. Проверка соотв. спец. треб. и ожид. это тоже валидация, но это соверш. разные вали дации. Целью первой является реализация. Вторя же должна рассм. гораздо больше аспектов --- ... . |
- | + | ... | |
Примеры: | Примеры: | ||
- | * abs(MIN_INT) | + | * abs(MIN_INT) --- ? |
- | * Динамическя | + | * Динамическя аллокация --- как описать, если внутр. структура меняется? |
Очень коротко о тех подходах, которые будут рассматриваться. | Очень коротко о тех подходах, которые будут рассматриваться. | ||
- | Почти всегда при решении сложных задач челвечество | + | Почти всегда при решении сложных задач челвечество польз. методом "разделять и властвовать". Например, нужно разработать крупную, хорошую прогр. систему. Для того, чтобы дну проблему решить, нужно разбить её на две чсти: спецификация и верификация. В реальной жизни, в резуьлтате того, что спец. сделаны качественно, для разработчика нет тёмных пятен, он предст. как что делать, и вериф. не нужна. Процесс спец. мжет быть сущ. более трудёмким чем разработка, и общее количество ошибок вылавливается на этом этапе. Этот процесс это не просто написание бумаг, это процесс, связанный с анализом. Вериф --- задача тн. прстая, поск. мы задаёмся вопросом "как проверить соотв.". В спец. есть два асп., связанных между собой, и как их решать, надо придумываь каждый раз: что специфицировать и как специфицирвать. Причём момент что тоже разд. на две части: как неоформленные требования, потр., знания предм. бласти передать разработчикам спец. и реализац.. Понятно, что надо пистаь не всё. Документ должен быть компактным. Знания предм. области должны быть, но какие знания --- вопрос. Имеется три осн. подхода, ответа на вопрс, как писать спецификацию: |
* Use cases | * Use cases | ||
* Sequence diagram | * Sequence diagram | ||
* SDL | * SDL | ||
- | + | ... | |
+ | |||
+ | --- написание поср. между спец. и прототипм. Это не всегда возм., но это работает. | ||
+ | |||
+ | В любм случае между спепц. и релзи. есть прслойка. | ||
- | — написание посредника между спецификацией и прототипом. Это не всегда возможно, но это работает. | ||
- | + | Для оценки нужно иметь зачёт по практикуму, суммарная ценка н экза. склад. из оценки на колке, н экз. и возм. за практикум. | |
- | Для оценки нужно иметь зачёт по практикуму, суммарная оценка на экзамене складывается из оценки на коллоквиуме, на экзамене и, возможно, за практикум. | ||
{{МФСП}} | {{МФСП}} | ||
{{Lection-stub}} | {{Lection-stub}} |