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

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

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

Текущая версия

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

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

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

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

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

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

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

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

  • Спецификация

...

  • Верификация

...

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

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

Аналогично здесь, это академическая дисциплина или нет? Сфера применения этих методов вполне обширна и востребована:

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

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

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

Оценка процента верифицируемого аппаратного и программного обеспечения:

  • АО ~90-95
  • ПО ~1-5

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

На самом деле:

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

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

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

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

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

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

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

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

Примеры:

  • abs(MIN_INT) — ?
  • Динамическя аллокация — как описать, если внутреняя структура меняется?

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

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

  • Use cases
  • Sequence diagram
  • SDL

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

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

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


Формальная спецификация и верификация программ


Лекции

01 02 03 04 05 06 07 08 09 10 11 12 13 14


Календарь

Сентябрь
03 10 17 24
Октябрь
01 08 15 22 29
Ноябрь
12 19 26
Декабрь
03 17
Семинары

01 02 03 04 05 06


Календарь

Сентябрь
01 08 15 22 29
Октябрь
06

Оформление задач|Проведение экзамена


Эта статья является конспектом лекции.

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы