10 записей с тегом "университет"

Графы это математическая формализация сетей. Поскольку я до дипломной работы перерыл много материалов, то тут буду собирать интересные доклады по этой общей теме. Эта статья составлена на основе курсов лекций Networked Life (Michael Kearns, Pennsylvania) и Social Network Analysis (Lada Adamic, Michigan) в Coursera.

Интереснейшие проблемы анализа сетей это поиск кратчайшего пути, визуализация и заражение

Терминология​

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

Программные инструменты ​

Gephi, Netlogo, iGraph, Pajek, UCINet, NodeXL, NetworkX, SoNIA.

Компоненты​

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

Особенности естественных сетей​

Кратчайший путь определяется только если сеть не имеет изолированных узлов (disconnected component). Проблема выражается в ограниченности видимости конкретного узла. Так, в социальных сетях человек ограничен знанием о своём окружении, поэтому он не видит всей картины, связывающей его с произвольным узлом остальной сети (small world effect).

Поиск пути в социальных сетях решается географическими и родственными связями (убывают по мере распространения), а дальше профессиональными и образовательными связями (увеличиваются по мере распространения).

Естественные сети (в отличие от скажем случайных сетей),  стремятся к минимизации кратчайшего пути и по мере роста числа узлов, среднее кратчайшее расстояние (диаметра сети) асимптотически уменьшается. Социальные сети на основе эмпирических исследований Траверса и Милграма (1969 г.), Лешковеца и Горвица (2008 г.) и Бэкстрома и др. (2012 г.) показывает что значение диаметра в районе 5.

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

Наконец третье свойство - длинный хвост в распределении степеней вершин (heavy tailed degree distribution, степенной закон, принцип Парето 20/80). Это проявляется в том, что в обществе есть редкие вершины, число связей у которых очень велико, а в среднем по сети "популярность" падает довольно резко и нелинейно

Заражение (перколяция, диффузия) в сетях может происходить необычайно быстро из-за пограничного свойства как структуры сети, так и свойств заражения (tipping point, threshold). Если взять случайно сгенерированный граф у которого средняя степень узла равна 4, то легко увидеть что при 100% степени заражения, порядка 90% узлов будет покрыто.

\[e=d*N/2\]

e - число рёбер
d - средняя степень узла
N - число узлов в сети

Число рёбер для ненаправленного графа

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

Скопления​

Для любой вершины можно определить степень скопления (clustering coefficient) как показатель взаимосвязанности её соседей. Если все вершины связаны, то такой подграф называется клик (clique) и имеет коэффицент 1. Теперь для расчёта коэффициента среднего скопления, достаточно просчитать коэффициент для всех вершин и взять среднее значение

\[C(u) = \frac{k+m}{k(k-1) /2 }\]

C(u) - коэффициент кластеризации вершины u
k - степень вершины
m - число связей "между друзьями"

Коэффициент кластеризации вершины

Коэффициент кластеризации имеет смысл сравнивать не просто с нулём, а со средней плотностью рёбер в графе, которая одновременно является и вероятностью что две вершины имеют общую связь

\[p = \frac{E}{N(N-1)/2}\]

p - плотность рёбер в графе
E - число рёбер в графе
N - число вершин

Плотность рёбер

Для естественных сетей C(u) значительно больше p

Моделирование скоплений​

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

\[y \sim p + (\frac{x}{N})^a\]

y - вероятность создания новой связи между двумя вершинами
p - вероятность случайной связи
x - число общих друзей между вершинами
N - размер всей сети

alpha-модель

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

Предпочтительное связывание​

Описанные модели формирование скоплений тем не менее не объясняют почему распределение степеней вершин подчиняется степенному закону. 

\[p(k) = Сk^{-\alpha}\]

p(k) - вероятность вершины иметь степень k
α, C - константы

Распределение со степенным законом

Предпочтительное связывание (preferrential attachment, cumulative advantage) объясняет неравенства возникающие в сетях, в том числе почему богатые становятся богаче, почему у поп-звёзд так много поклонников. В целом это сводится к тому, что чем больше у вершины есть ресурсов, тем легче ей получить ещё - через дополнительную рекомендацию друзей, предубеждение, славу и тп.

Навигация​

Для понимания естественных сетей, стоит поговорить о процессах навигации и распространении сигналов. Они должы учитывать как структурные особенности сети, так и алгоритм выбора оптимального пути.

Модель Клейнберга предполагает что сеть упорядочена в матрицу k на k и каждая вершина знает свои координаты. Передача сообщения в таком случае сводится к выбору соседней вершины, наиболее близкой географически к глобальной цели. При этом можно ввести сопротивление в движении 

\[p(d) \propto (1/d)^r\]

p - вероятность новой связи между двумя вершинами
d - расстояние между вершинами
r>=0 - степень, влияющая на поведение

При очень больших r, передача сообщений происходит только локально и кратчайшие расстояния до дальних вершин могут даже не существовать.

Приуменьшении r, падает сопротивление от расстояния, но увеличивается алгоритмическая сложность поиска кратчайшего расстояния

Важные вершины​

До этого всё что касалось характеристик, описывало всю сеть целиком, но единичные вершины также критично важны.

Pagerank​

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

\[R(p) = \sum_{q \in POINTS(p)} \frac {R(q)}{out(q)}\]

R(p) - pagerank вершины p
R(q) - pagerank вершины q которая ссылается на p (принадлежит множеству POINTS)
out(q) - число исходящих ссылок из q

page rank

Вот например как выглядит расчёт для некоторых вершин..

Рациональные процессы в сетях​

Модель сегрегации Шеллинга​

Шеллинг показал, что если вершины могут выступать как люди и изменять своё местоположение в матричной сети, переезжая в ближаюшую не занятую ячейку, то при случайном начальном расположении и при требовании вершины к своим соседям в 40% похожести, возникают сегрегированные области, подобно гетто-районам расовой сегрегации.

См. эмулятор.

Начальное случайное положение

Сегрегация при 40 процентах требований достигает 80 процентов похожести

Предприниматель (enterpreneur , эст. ettevõtja) - активный человек который что-либо производит или предоставляет услугу потребителю и в условиях конкуренции стремится к использованию более эффективных методов получения прибыли. Концепция предпринимателя появилась в 18 веке с развитием частного права и индустриализации.

Предпринимательство имеет несколько определений, но все соглашаются что это процесс, включающие в том числе и такие абстрактные понятия как благо, ресурсы, время и усилия, жизнь организаций, действия и возможности, услуги, культуру, рынок и проч. Однако вне зависимости от области и размеров предприятия, во всех компаниях одинаков процесс развития

1. Определение потребностей и возможного рынка (разведка)
2. Разработка товара или услуг с концентрацией и ресурсов (тут есть риск неправильной оценки рынка)
3. Развитие в зависимости от ситуации (перегруппировка сил, приспособление)

Формы предприятий (в Эстонии)​

Точно так же как кровеностная система делится по размерам артерий и вен, так и компаниями могут объединяться и работать как

• Физическое частное лицо (FIE, füüsilisest isikust ettevõtja) - предприниматель как частное лицо. Простота регистрации, упрощённая бухгалтерия, полная материальная ответсвенность, ограничение максимального капитала.
• Полное товарищество (TÜ, täisühing) - два или более владельцев, полностью отвечающих за обязательства своим имуществом, нет требования в минимальном капитале
• Договорное товарищество (UÜ, usaldusüging) - два или более владельцев, где один отвечает за обязательства своим имуществом, а остальные - в согласно договору
• Предприятие с ограниченной ответсвенностью (OÜ, osaühing) - акционерный капитал (минимум 40 тыс крон) поделен на акции между акционерами, которые не несут личной ответсвенности перед обязательствами предприятия. Минимальная цена 100 крон за акцию. При капитале более 400 тыс обязателен аудитор.
• Открытая акционерная компания (AS, aktsiaselts) - акции открыто продаются общественности, минимум 400 тыс начальный капитал., отсутсвие влияние одного человека на судьбу всей компании.

В сторонке стоят:

• Некоммерческие объединение (MTÜ, mittetulundusühing) - предприятие, стремящееся к определённым (социальным) целям, ограничено в распределении доходов между членами.
• Государственные органы и самоуправления - могут предоставлять услуги открытому сектору
• Благотворительные организации - налогами не облагаются

Компании могут объединяться в группы

• Консорциум - объединение предприятий для одной цели-продукта, где каждое предприятие оптимально в своей области.

• Картель - объединение компаний близкой рыночной области для контроля цен, оставаясь независимыми во всём остальном

• Синдикат - объединение компаний с потерей сбытовой самостоятельности

• Концерн - объединение компаний горизонтально по близкой области (все пивоварни), вертикально (весь процесс добычи-разработки-сбыта) или смешанно (конгломерат)

• Франчайзер-франчайзи - предоставление права использования торговой марки и технологий ведения бизнеса, как правило при строгих условиях (например McDonald's, Columbia sportsware, 1C)

• Филиал - представительство иностранной компании

Компания как объект экономической системы состоит из

1. Внутренней среды - управляющие, владельцы и работники
2. Внешней микросреды - потребители, подрядчики, конкуренты, человеческие ресурсы (потенциальные работники), финансовые ресурсы (потенциальные инвесторы)
3. Внешней макросреды - политической, экономической, социальной, технологической, природной и международной обстановки. Законодательное влияние воплощено в законах о трудовом договоре, конкуренции, налогообложении, Acquis Communautaire

Бизнес идея и бизнес план​

Бизнес-идея не возникает из ниоткуда. Всё появляется на основе уже существующего опыта. Бизнес идея воплощаясь в бизнес-плане отвечает на множество вопросов — что, кому, как, когда, кем (производится продукт или услуга).

Новая идея это:

• инновация (техническое воплощение научных открытий)

• эмоции (сделать более человечески приятный подход к клиенту)

• функции (больше, удобней, легче)

• морфология (другие цвета, форма упаковки, дизайн-идея, реклама, персонализация)

• дешевле (оптимизация, скидки)

Все эти идеи приходят либо от старых продуктов (71%), халтур или хобби (7%), системных поисков решения (4%), путешествий (1%) и проч. Однако, наличие бизнес-идеи не говорит об успешной бизнес-возможности.

Анализ бизнес-возможностей дело не простое — сколько у целевой аудитории денег, кто они по возрастам, профессиям, как лучше всего им продавать товар, как изменяются потребности и демография потребителей со временем и местом. И в зависимости какой товар (нишевый он или массовый, эстетически ценный, cверх-функциональный, модный, прочный, надёжный, экологичный) надо продумать весь жизненный цикл (как он устанавливается, используется, обслуживается, обновляется)

На каждом этапе жизненного цикла продукта он имеет свою цену:

• Производство - воплощение форма товара и его переработка (recycling)

• Транспорт - пространственная ценность (сколько места занимает в автомобиле)

• Логистика - ценность пространственного и временного перемещения (насколько далеко и быстро можно перевозить)

• Торговля - ценность владения

SWOT-таблица (Strengths,Weaknesses,Opportunities,Threats) в бизнес-плане это хороший способ увидеть перспективы продукта на рынке. Он включает и анализ рынка и состояние микро-макро среды предприятие, возможные изменения

Маркетинг​

Торговля (marketing) это часть процесса управления предприятием с целями нахождения и продажи продукта/услуги потребителю (или более общими словами - в удовлетворении спроса предложением). Есть несколько психологических способов продаж (концепций):

1. Производственная — масштабное конвейерное производство. В больших объёмах выходит дешевле, а универсальность охватывает многие аудитории (телефоны, автомобили)

2. Продуктная — идёт работа над улучшением качества одной линейки продуктов (skype, windows)

3. Рекламная — клиент не купит покуда не узнает (продукты питания, косметика)

4. Торговая — сделать лучше чем у конкурентов (телефонная связь)

5. Социальная — направленная на конкретную (узкую) аудиторию (магазин комиксов)

6. Общительная — создание постоянной связи с клиентом (парихмахер, юрист, дантист)

7. Ценностная

Теория 4P говорит о маркетинговом планировании с помощью четырёх «координат продукта» (продукта, цены, продвижения и местоположения), тогда как теория 4C говорит больше о клиенте (потребитель, цена, удобство, связь). Товарный знак/марка — предмет права интеллектуальной собственности и служит для обозначения товара.

Цена товара может формироваться несколькими способами

1. Сколько клиент готов платить
2. Сколько стоит у конкурентов
3. Принцип самоокупаемости

Бостонская матрица — один из способов описания состояния продукта на рынке и его динамику. В идеале продукт должен находится в области «дойной коровы», тогда наблюдается постоянная прибыль с малыми изменениями на рынке. Продукты-«звёзды» это потенциальные победители в скачках, покуда индустрия не успокоится. «Трудные дети» это стартапы — они могут захватить рынок при нужном управлении

Налоги в Эстонии​

Прямые налоги:

• Налог с оборота (käibemaks = НДС = VAT) — 20% от стоимости товара или услуги (с 1 июля 2009 г.) платит продавец государству (но включает налог уже в цену) каждый месяц 20го числа. Если у продавца оборот менее 18 тыс евро в год, то налог не платится.
• Социальный налог — 33% от заработной платы работника (c 2003 г.) платится работодателем государству, которое пускает его на пенсионное обеспечение (20%) и медицинское страхование (13%).
• Налог по безработице — 1.5% от брутто-зарплаты работника (формально 0.5% от работодателя и 1% от работника)

Косвенные налоги:

• Подоходный налог (tulumaks) — 21% от выплачиваемой прибыли работникам (kasum), выплачиваются государству 10 числа каждого месяца. Если все доходы остаются в компании то платить не надо
• Акцизы — дополнительные налоги на второстепенные товары (алкоголь, табак, топливо, автомобили, упаковку)
• Таможенные пошлины (tollimaks) — взимается с импорта

Бухгалтерия​

У бухгалтера сложная работа, потому что постоянно надо писать отчёты в Maksu- ja Tolliamet, поэтому выгодней нанимать профессионала, что бы не сесть в лужу с этими "простыми" расчётами.

1. Каждый год — отчёт за хозяйственный год (вместе с управленческим отчётом). Состоит из баланса, отчёта о прибыли, отчёт о денежных потоках, а также отчёт об изменении собственного капитала.

2. Каждое 10 число месяца - декларация уплаты налогов с зарплаты (TSD, INF1, INF11)

3. Каждое 20 число месяца - декларация уплаты налогов с оборота

А вот основные формулы:
Имущество = обязательства + собственный капитал
Доход = общая прибыль - общие расходы
Оборот = кредит - дебит

Баланс​

Баланс показывает финансовое состояние предприятия на определённый промежуток времени. Состоит из двух равных частей:

Баланс Актива и Пассива появляется за счёт разницы - Собственного капитала, который показывает какая часть имущества принадлежит владельцам после погашения обязательств.

Отчёт о прибыли​

Ещё один вид отчёта показывает движение капитала за период времени. Заметьте что в себестоимость проданной продукции не числится в качестве расходов. Чистая прибыль предприятия может выплачиваться акционерам в качестве дивидентов.

По теме

• Enterprise Estonia
• Activa
• IN

Работа расширяется и как правило превышает отпущенное на неё времяПервый закон Паркинсона

Проект - делопроизводство с вовлечением человеческих, финансовых и материальных ресурсов и организованный с тем что-бы уложиться в рамки ресурсов и времени и достичь поставленные тестируемые требования

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

Типы проектов

• низкотехнологичные, основанные на существующих стандартах (например ERP, CMS)

• технологичные, основывающиеся на практически готовых технологиях (дополнения существующих проектов)

• высокотехнологичные, практическое большинство написано специально для проекта (программы для военных, софт для мобильных аппаратов)

• super high-tech

Оценка успешности проекта

• по времени, расходам, качеству выполненной работы до завершения проекта
• влияние на краткосрочную прибыль клиента
• по полученному положению (преимуществу) в сравнении с конкурентами
• по личному отношению клиента к выполненной работе

Цикл жизни и опыт коллектива​

Методы подхода к реализации проекта можно разделить на:

• Sashimi waterfall

• Staged Delivery

• Controlled Iteration

• Spiral

• RUP

• XP

• Scrum

• Evolutionary Prototyping

• Code and Fix

• Agile|- PMBOK - описывает область знаний и прилегающие области необходимые при выполнении проекта. Включает стандарты, общие требования к знаниям

• MPMM -

• Prince2|

Жизненный цикл проекта определяет время начала, конца и промежуточные периоды. Эти периоды (итерации, фазы) в зависимости от выбранной методологии и проекта могут быть к примеру:

• Необходимость, планирование,создание, проверка, завершение
• Дизайн, программирование, тестирование, обучение, выпуск

В свою очередь вне зависимости от масштаба периода, вплоть до элементарной задачи сотрудника, можно выделить мировоззрение PDCA - планировании, действии, проверке и докладу.

Оценка сложности​

Происходит по аналогии либо по анализу. По аналогии соответсвенно похожие задачи были некогда проделаны и общее время известно. По анализу просчитывается количество функций, требований, сложности и действий с умножением на некую среднюю величину. Существует также и метод оценки PERT, работающий по формуле:

Оценка (чел/час) = (оптимистичная + 4 * ожидаемая + пессимистичная) /6

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

Оценка должна учитывать в контексте системы четыре аспекта:

1. Разрабатываемый продукт для клиента
2. Бумажную работу и проволочки внутри фирмы (т.н. издержки на организацию работы)
3. Услуги и работы которые необходимо будет делать после завершения проекта (поддержка, обучение и тп.)

Сортировка задач по времени наглядно видна в MS Project, но в общем там заметны элегантные очевидности - параллельность выполняемых задач (leads) разными людьми в одно и то же вермя и необходимость в запасном времени (lag). Кроме очевидных зависимостей (Конец-Начало) между задачами, теоретически ведь возможны и разные комбинации, когда задачи должны либо завериться одновременно, либо хотя бы немного начаться.

Тем кто захочет создать универсальный планировщих задач прийдётся много попотеть. Ведь недостаточно получить число человеко-часов, надо перевести это на календарь с учётом зависимостей и параллельности задач. В простом случае такую оценку можно получить пройдясь по "критическому пути" - наиболее длинной по времени последовательности взаимосвязанных задач.

Согласно E. Goldratt'у оценка буфера проекта должна составлять 50% от длины критического пути. Если при разработке появляется опоздание в размере более чем 15-20% от критического пути, и невозможно привлечь дополнительные ресурсы, то необходимо делать компромисс между качеством, масштабу работ или оплатой. Потеря ключевого работника может внести опоздание дополнительно в 4-9 недель.

Оценка качества​

Качество это тестируемая характеристика выполненной работы, выражающаяся в отношении предоставляемый возможностей к изначальным требованиям. По качеству продукта клиент автоматически судит о брэнде товара или компании.

Основные стандарты качества:

• Six Sigma - статистический метод от Motorola

• ISO 10006 - Guidelines to quality in project management

• TQM

• CMM

Очень показательны и методы планирования качества. Например анализ расходов (Cost-benefit analysis) можно наблюдать в фильме "Fight Club", где расходы на отзыв автомобилей был бы больше чем бездействие с ежекратной уплатой пострадавшим в авариях по страховке. Анализ расходов на достижение качества (Cost of Quality) с другой стороны показывает сколько надо тратить на всевозможные проверки, тестирование, стандартизацию, исправления, гарантии до выхода продукта.

В таком разнообразном мире много всевозможных переменных и не только в физическом мире, но и в программном обеспечении. Поэтому существует понятие риска, его вероятности и критичности. Стратегии по улучшению качества включают не только минимизацию риска, но и их смягчение, чёрные сценарии. В инфосистемах это можно наблюдать всюду - в валидации форм, ошибках 404, резервном копировании хостинга, подсказках (tips), подтверждениях (are you sure?), транзакциях с финансовыми операциями и тп.

Качество напрямую связано с тестерами. А они в свою очередь знакомы с некоторыми темами:

• Диаграммы причин-следствий (Ishikawa)
• Оценка на основе статистической выборке
• Японской философии постоянного совершенствования Kaizen
• Benchmarking, т.е. проверка на скорость реальной системы
• Принципом Парето 80-20

Проблемы можно классифицировать не только по сложности (слышали про гейзен-баги?) но и по человеческим причинам возникновения:

• "Без батареек". Человек спешил или самоуверенно не читал чужой код или документацию
• Смесь третьего ПО. Технократизм программера или архитектора, по гордости или глупости решившего использовать технологии без понимания их совместной работы (см. CORBA, COM и тп.)
• "А давайте добавим". Слишком большие энтузиасты-управляющие или ленивые программисты часто любят предложить дополнительную работу, не видя общего графика и желая оставить приятное впечатление.
• Несинхронная архитектура. Как правило затрагивает огромные проекты, где аналитический отдел и программисты не успевают друг за другом, а архитектура меняется на ходу. Причина - отсутсвие нормального управления архитектурой
• Убивающая Демо-версия. Отдел маркетинга ставит большую важность на демонстрацию системы как зацепляющего клиентов объект, из-за чего комманда разработчиков постоянно занята развитием и поддержкой прототипа самой новой версии и не занимается реальными проектами.
• Неправильный цикл. Большая контора, но цикл разработки ПО выбран неправильно, отсюда - нестыковки в графике, неизвестное состояние проекта, завышенные расходы.
• Клиент всегда прав. Постоянные дополнения вносимые управляющим проектом от клиента. В результате - нестабильный дизайн и куча ошибок, незаконченность или взаимосвязанность. Возникает из-за несфокусированности на целевых аудиториях.
• "Кольцо всевластья". Для универсальности и увеличения продуктивности в фирме все проекты подстраиваются под одну гребёнку, в результате у мелких проектов появляются лишние задачи.
• Эффект Домино. Ключевого разработчика/дизайнера/аналитика временно переводят на другой проект "помочь", поскольку пока проект отлично успевает. В результате всё идёт ещё хуже - ключевой человек забывает и не имеет понятия о состоянии старого проекта, но и не втянулся в новый проект. Причина - растущая компания, слишком много работы, зависимость от ключевых фигур.
• Угодить всем. Управляющие вмешиваются в проект в обход управляющего проектом, возникают параллельные задачи, стресс, изменения в планах.

Общение в коллективе​

В больших компаниях (более 20 человек) идёт активное разделение и иерархия коллектива на роли и группы. Роли согласно RUP - аналитики, разработчики, тестеры, управляющие и остальные. Но для эффективной работы, создаются группы скажем "CMS PHP team", ".NET gps project team" и тд.

Во главе такой группы технарей стаит управляющий группой (team leader), который координирует работу внутри группы и с управляющим проектами. У нас в компании походая схема и зачастую возникает вопрос - к кому и как обращаться если возникли вопросы по проекту или что-то не так. Трясти постоянно team-leader'а не лучшее решение, он сам не железный, а просто так за спиной подходить к дизайнерам "ребят, исправьте тут работы на пару часов только.." тоже не совсем правильно.

Вообще существует несколько схем организации такой работы и общения.

1. Функциональная схема предполагает что работа идёт тому, кто наиболее опытен в этой сфере. Проект переходит от одной комманды к другой. Сначала анализ, потом дизайн, потом программирование и тп. Такую систему также сложно поддерживать, расширять или кардинально менять. Общаться практически ни скем не надо.

2. Безструктурная схема - небольшая анархия. Разговаривать приходится когда попало и с кем угодно, порой по разным проектам одновременно. Из-за этого возникает низкая продуктивность, невозможность предсказать времена.

3. Уровневая схема. Комманда разработчиков организована по уровню опытности со смешанными ролями. Так что верхние слои отвечают за архитектуру в целом, а нижние за менее важные и более приземлённые части. Работники принадлежат одновременно нескольким группам.

Информационный канал можно тоже упорядочить по степени пропускаемости: Бумажное письмо (без диалога), email, аудио-запись (без диалога), видео (без диалога), телефон, видео конференция, диалог возле доски.

По эволюции комманды с проектом, можно составить следующие психологические ступени:

1. Создание комманды (Forming), определение целей проекта, ролей участников и задач
2. Выяснение границ компетентности (Storming), поиск единого стиля
3. Нормализация отношений (Norming), доверие и спокойная совместная работа
4. Производственные отношения (Performing), вмешательство управляющих минимально

Оценка безопасности​

По ISO существует несколько характеристик действий работника с системой.

1. Identification: who are you?
2. Authentication: how do I know your identity is true?
3. Authorization: are you allowed to perform this transaction?
4. Integrity: is the data you sent the same as the data I received?
5. Confidentiality: are we sure that nobody read the data you sent me?
6. Auditing: record of all transactions so we can look for security problems after the fact
7. Non-repudiation: both sender and receiver can provide legal proof to a third party (e.g. judge) that the sender did send the message, and the receiver received the identical message
8. Privacy: addresses the access purpose and data owner choice

Это была статья с вольным переводом основных тем лекций по предмету управления IT-проектами в ТТУ ( IDU3390 - Infos?steemi projekti juhtimine). В заключение - небольшой клип о том что может произойти в офисе если не соблюдать технику стрессовой безопасности и оптимизма

вторник, 13 мая 2008 г. в 19:26:38

Данный предмет (IDU0080 - Web-teenused ja internetilahenduste arhitektuur) преподаётся в ТТУ будующим бакалаврам Информатики профессором Enn Õunapuu, а практические задачи ведутся работниками из Webmedia.

Практические занятия и представляют в данном предмете наибольшую сложность (и опыт). За время семестра разбирается тестовый проект и работа ведётся в Eclipse IDE с Java. Первым заданием даётся возможность составить документацию самому, а в остальных заданиях рассматривается уже наполовину готовая программа.

Проект представляет из себя систему вымышленного производителя одежды "Schmancy panties", при этом общение производится между складом (warehouse), управлением (sales), цехом (production), двумя поставщиками (melaka, hindusilk) и двумя магазинами (beijing, tokyo).

• Java RMI и FTP
• REST
• Web-сервисы (via SOAP & WSDL). Генерация сервера с помощью xfire

Перевожу список вопросов-ответов для контрольной по предмету Andmebaasi võrguliidesed который в ТТУ ведёт сейчас Erika Matsak и где основная тема - работа с Oracle из Java посредством JDeveloper. Впрочем я думаю и незнакомым с этой темой будет интересно…

Модели данных​

1. Плоская. Одна таблица (сущность/класс) (MS Excel, телефонная книга). Есть заголовки таблиц, типы и собственно данные
2. Иерархия. Много сущностей (классов/node'ов) между которыми есть только отношения 1:N. Например меню, страны-города-регионы и тд.
3. Сеть. Объекты могут связаны N:M отношениями. Люди в соц.сетях, ссылочное ранжирование.
4. Реляционная модель - расширенная модель сети, где связей может быть несколько.
5. Продукционная модель - набор правил которые могут быть представлены в виде IF (условие) THEN (действие). Используется в промышленных экспертных системах. Наглядно, модульно, однозначно
6. Семантическая сеть - расширенная модель сети, где отношения фиксированы и производятся над понятиями объектов и классов (иерархические, функциональные, количественные, пространственные, временные, логические и тп.)
7. Фреймы Минского - собирательный образ данных для представления человеческого абстрактного восприятия. Состоит из структур, ролей, сценариев, ситуаций. Фреймы можно наследовать

Основы реляционных БД​

Таблица считается в первой нормальной форме , если её поля атомарны и у неё есть primary key. Таблица считается во второй нормальной форме, если все поля зависят от primary key, но не зависят от его частей. Таблица в третьей нормальной форме, когда primary key полностью идентифицирует ряд.

Некоторые свойства таблиц:

1. Порядок рядов в таблице не имеет значения - это множество

2. Объекты уникальны

3. Объекты могут идентифицироваться через минимальный ключ (primary key) или несколько ключей (keys)

4. Объекты можно связать друг с другом внешними ключами (foreign key)

5. Любой параметр ряда может иметь значение NULL

Oracle и доступ из интернета​

Из интернета редактируется в Enterprise Manager = Apex = HTML DB. Также есть SQL*Plus - консоль с расширенными SQL-коммандами (например DESCRIBE)
Пользователь может иметь

• Системную привилегию, например на создание таблиц/пользователей/соединения

• Объектную привилегию на доступк конкретной таблице

• Группы привелегий. Например RESOURCE группирует в себе создание триггеров и процедур, DBA - привилегии админов

Основы SQL​

Комманды можно разделить на:

• SELECT/INSERT/UPDATE/DELETE - основные комманды принципа CRUD.
• WHERE/HAVING/IF/CASE/THEN/IN/LIKE/EXISTS - основные комманды логической фильтрации
• ORDER/GROUP - аггрегирующие и сортирующие комманды
• SYSDATE/TO_CHAR/ROUND/...- функции работающие с одним рядом
• JOIN - объединение таблиц

PL/SQL​

Очень похож на Pascal/Delphi. Используется для обработки данных в таблицах.

DECLARE a NUMBER; b NUMBER; d VARCHAR(20); //инициализация c NUMBER := 3; //присваивание ``BEGIN SELECT e,f INTO a,b FROM T1 WHERE e>1; //чтение в переменные INSERT INTO T1 VALUES(b,a); END;

БД, Java и роль JDeveloper​

Соединение создаётся через класс DriverManager.getConnection. В Jdeveloper'е большинство кода можно генерировать визуальными компонентами.

Java beans​

Это java-классы, созданные по правилам:

• конструктор без аргументов
• параметры имеют методы доступа (get/set/is)
• наследуют интерфейс java.io.Serializeable

На основе таких правил созданы большинство компонентов графических библиотек Swing. Благодаря своей иерархической структуре, IDE могут легко анализировать и показывать внутренности визуальных компонентов.

Oracle JDBC драйверы​

JDBC имеет четыре типа драйверов для работы с БД (библиотеки java.sql и javax.sql) - т.н. толстые (нуждающиеся в дополнительных библиотеках - OCI к примеру) и тонкие (написанные полностью на java - thin). Рекомендуется использовать thin-драйверы. От этого часто говорят о "тонком клиенте".

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

Предмет Infos?steemide Strateegiline Anal??s (IDU0021) в ТТУ преподаётся лектором Mart Roost'ом и практующим Ants Torim'мом. В практической части предполагается что студенты смогут описать инфосистему организации согласно предлагаемым в лекциях условиям.

Описывать инфосистему значит моделировать её, тоесть абстрагироваться от конкретных задач и пописывать в целом, с разных сторон.

В данном предмете предлагается такой костяк для проекта:

• Деловые процессы (как ИС смотрит глава компании)

  • Области ответсвенности лиц, роли (программисты, аналитики, бухгалтера) (p?devusalad)

    • цели
    • ответсвенности
    • необходимости
    • процессы
    • термины (бизнес-объекты, например "договор")

  • Функциональные подсистемы, департаменты (маркетинг, research&development, финансы) (alls?steemid). Описываются точно так-же все цели, процессы и тп.

  • Регистры, аналоги таблиц баз данных, только без посредтсвенных таблиц связей и ID'шников. Работают по элементарным CRUD -функциям.

    • Практическая реализация. SQL-схема.
    • Связи с подсистемами
    • Концептуальная классовая диаграмма
• Архитектура технологий (как на ИС смотрит инженер)
• Развитие организации (как финансисты общаются с технарями)

  • Стратегия и временной план

  • Проекты и оценка рисков

  • Оценки ресурсов

Мы с коллегой решили что проще описать систему небольшой фирмы, занимающейся хостингом. Ролей в такой фирме мало - администратор, бухгалтер и глава компании. Единственные данные которыми можно разнообразить UML-диаграммы это регистры договоров с клиентами и счетов. В качестве функциональных диаграмм инетересна разве что процедура оплаты.

На экзамене мы получили двойку, потому что было мало регистров (минимум надо 5), на концептуальной диаграмме стрелки вместо ассоциации были обобщения. На диаграмме процессов было мало действующих ролей и отсутсвовали бизнес-объекты, заносимые в регистры.

Читайте также:

• О том, кто виноват, когда заказчик сам не знает чего хочет и сколько стоит создание нормального ТЗ.

Защита диплома в ТТУ дело обыкновенное - достаточно сделать презентацию на 15 минут о том какая проблема решалась. Ввиду специфики области (академическая защита) и ограниченность по времени (всё идёт как по конвейеру), надо постараться выжать самый концентрат сока.

В общем надо ответить на три вопроса

1. Какая проблема?
2. На каких теоретических и практических исследованиях работа основывалась, есть ли соавторы
3. Какие получены новые результаты и какие последствия открываются для будующего поколения учёных

Если презентация делается на 15 минут, то надо не более 15 слайдов где по минимуму будет содержание. Помните, что вы не энциклопедию передаёте поколению, а делаете для себя визуальную помощь. Заранее скажите как вы будете отвечать на вопросы (сразу или в конце).

суббота, 3 февраля 2007 г. в 16:47:12

Этот предмет в ТТУ (Sissejuhatus infosusteemidesse, IDU3530) знакомит студента с таким немаловажным аспектом работы в большом коллективе, как проектирование проекта. На данный момент пусть неважно, что именно за проект - будь то тяжкая работа сантехника, которую решили закрепить на бумаге, или же программка "Тетрис" студента Васи.

Чтобы изложить понятные каждому неискушённому человеку пункты о том Что делает модель/система, Как она устроена и Каким образом идёт взаимодействие, используется разработанный для таких дел Унифицированный Язык Моделирования. Буквально это стандартизированные правила о том как рисовать одну часть модели и как к ней пририсовать другую.

UML можно рисовать как от руки, на доске, так и в специальных программах - MS Visio, Rational Rose, Argo UML. Наибольшее применение разумеется UML для нас будет иметься при проектировании программ, но в данном курсе упор делается на проектирование бизнес-структуры какой-либо организации на примере её сайта.

Для успешного получения зачёта вам прийдётся быстренько изучить Rational Rose либо в универе, либо скачать с инета бесплатную 30дневную версию. Для того чтобы разобраться в UML можно таким же образом взять книжку из библиотеки..

Если кратко, то существует много возможных диаграмм, но основные это..

• Use-Case описывает возможности модели, которые доступны для конечного пользователя, будь то заказ, переписка или получение рассылки. Обозначения - человечек как Actor и возможности в виде овалов.

• Class diagramm описывает уже подробно внутреннюю структуру модели, переменные, функции. Тут видимо подразумевается разбиение элементов на Объекты.

• Sequence Diagram описывает динамику системы, т.н. общение объектов. Например вызов функции поиска поискового объекта.

• Component Diagram показывает физическое представление отдельных частей модели. Для микросхемы это были бы отдельные чипы.

Кроме того существуют STATE diagram, Collaboration diagram и прочие

Algoritmid ja andmestruktuurid для IASB ведет Виктор Леппиксон.

Его минусы:

• Практические уроки отсутсвуют. Всё в руках студента - сам пусть учит.
• Безразличие до проблем студентов, в частности если на экзамен все места зарегистрированы.

Немного внешнего материала..

• Карточка предмета IAG0090
• Материалы от преподавателя
• Материалы от Allik
• Материалы от Серёги Шенберга

Экзамен. Теория​

1. Что такое сериализация, где необходимо её использовать.
2. Сложность некоего алгоритма была оценена как функция T(n), что она собой значит?
3. (тут график нужен) Есть многоуровневая структура быстрого поиска (Мои пояснения.. Например нижняя цепочка проходит через все элементы 5-6-7-10-13-15, а верхняя только 5-7-13). Как быть если необходимо добавить новый элемент в эту структуру?
4. Как освобождается память, отведённая под двоичное дерево.
5. Постройте "2-3-4" дерево из элементов, которые поступили в порядке.. 200 100 120 80 10 30 210 220 230 140 130 150
6. Oletame, et kettal paikneva andmestruktuuri realiseerimiseks B-puu, kuidas te valiksite puude jargu?
7. Нарисуйте 3-х дерево из слов: liiga liider liiklus liialdus liikluvus liim liimipulk
8. Lineaarne proovimise meetod (paiskpaigutus)
9. Nullmeetodil sortimise algoritm
10. В оперативной памяти находится две фотографии, на которой под один пиксель отведён 1 байт. Оба файла одинакового размера. На одной горы (?), на другой - карнавал в Рио-де-Жанейро. Оба файла сжимаются кодированием Хаффмана. Какая займёт меньше памяти, почему.

Экзамен. Практика​

Есть такие структуры..

struct Student {char *pName,*pCode; char **pSubjects;}; struct Subject {char *pName,*pCode, *pTeacher; double nPoints; struct Subject *pNext;}

Из них составляется два массива всех студентов и всех предметов.. Известны
*pSubjectList, *pStudentList.
Необходимо написать функцию с прототипом

int NewSubject (struct Student **pStudentList, struct Subject *pSubjectList, char *pStudentCode, char *pSubjectCode)

Причём работает она таким образом..
Для получения ссылки на нужного студента - есть функция, возвращающая значение индекса в массиве студентов с прототипом
int HashFun (char*)

Таким образом NewSubject() должна проверить сначала есть ли такой студент, потом - есть ли такой предмет, потом надо хитро посмотреть сколько у данного студента есть занятых мест в Student.pSubjects, куда помещается максимум 5 мест. Так вот надо найти свободное место, выделить под него память и скопировать в него код предмета (pSubjectCode). В случае если какой-то шаг не удался - функция возвращает ноль.

О предмете​

Диагностика в целом это не наука, это философия, т.е. присущая многим дисциплинам методология. Диагностика занимается анализом системы, обнаружением ошибок, процессов, их причин и их местонахождением. Применимо к дигитальным системам, т.е. фактически к электронным цепям построенным по булевой двоичной логике на транзисторных микросхемах, диагностика занимается

• развитием теоретической части с применением всевозможных теорий графов и математического аппарата
• созданием алгоритмов для автоматической проверки микросхемы программно, поскольку  в современный век непрактично более проверять вручную схему, выпускающуюся на конвейре

В Таллиннском Техническом Университете лектор по этому предмету (IAF0050) - Раймонд Убар, подошедший хорошо с теоретической и материальной частью к образованию, поскольку всё доступно из сети:

• Слайды на английском языке
• Три лабораторных
• Сложнейшая домашняя работа

Лабораторные работы​

Первая называется Test generation и состоит в практике генерировать вручную и программно векторы (сигналы на входах) так, чтобы те покрывали все возможные ошибки в схеме. Лабораторная разделяется на три части, по схемам - достаточно простая (вариант которой вы получаете в задании), где необходимо ввести вручную 14 векторов взяв их с потолка и добиться 100% покрытия ошибок, потом алгоритмически смотря на схему, добиться значительно лучшего результата (см. ниже).

Работа может происходить как на Sun-ах с Open Windows оболочкой, так и с Common Desktop Enviroment, так и на простой Windows 98/XP/...
Для Windows тогда необходимо скачать пакет программ Turbo Tester чтобы практиковаться дома. На лабораторных же все программы уже встроены и можно сразу вводить комманды.

Для работы с первым заданием достаточно сохранить source-файл с расширением agm к себе в папку и открыть его коммандой vecmanager. Далее вводим векторы и проводим fault simulation. Смотрим сколько покрыто ошибок и т.д.

Второе задание посложней, схема представляет собой "full 8-bit ripple-carry adder" и состоит в том что-бы сопоставить техники автоматического выбора векторов а также алгоритмически выбрать некоторые вектора (см. ниже).. Автоматический подбор осуществляется коммандами generate, random, genetic. Время генерации и число векторов и надо сопоставить.

Третья схема ещё сложней, но по сути - самая лёгкая. Для неё надо выпонить те же три комманды, получить статистику и посчитать "цену" для каждой процедуры.. Genetic всегда получается самой дешёвой например. Альфа =1 , Beta=0.1 Gamma=10 кажись.

Теперь об алгоритмическом решении первой схемы.. Как говорят лекции и англоязычная документация лабораторной, у нас есть простая комбинационная схема из AND, OR, NAND, NOR, NOT элементов. Нам необходимо проверить схему на наличие неисправностей. Предполагаем что неисправности ограничиваются поломками соединений так, что возможные ошибки это константа ноль ( =0 ) и константа единица ( =1 ). Теперь чтобы проверить все соединения, будем проверять соединения не по одиночке, а соединения при логических элементах. Легко видеть, что элементы с двумя входами AND, NAND, OR, NOR полностью проверяются на наличие неисправностей тремя векторами во всех соединениях. Элементы с тремя входами нуждаются в четырёх векторах.

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

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

Алгоритмическое решение второго задания.
Каждый сумматор состоит из двоичных элементарных сумматоров, где на входе a0 , b0 - двочные разряды которые надо сложить и c0 - значение переноса с предыдущего сумматора. Имея 8 подобных сумматоров и выстроив их один за другим, нарисуем табличку

в каждом блоке сумматор проверяется на все 8 возможных значений со входа, которые дальше передаются в следующий сумматор.. так мы проверяем весь сумматор сохраняя число нужных векторов для проверки элементарного сумматора. Достигается это чередованием 4 и 5го векторов.. Заметьте что значение c1 зависит от значений предыдущих c0, a0, b0.

Получив в результате таблицу для 8ми сумматоров, открываем vecmanager, и видим что он хочет вектор в виде
Cin b7 a7 ...
Поэтому все эти значения (Cin - в нашем случае c0) получаем из таблички. Таким образом 8 векторов (длинной в 17 бит) покрывают 100% ошибок, о чём и должен со счастьем сообщить vecmanager после ввода и симуляции.

Вторая лабораторная.
Получив и сохранив схему (в моём случае, d4), написав комманды

xtimport -paths -tool cadence d4.edi ams.lib xtimport -spec -tool cadence d4.edi ams.lib generate d4 prediag d4

мы задали в результирующей схеме некую ошибку в одном элементе, т.е. считается что один из элементов схемы ведёт себя по-другому, причём он может быть один из NOR, NAND, OR или AND.
Задача тестирования в первой лабе сводилась к получения ответа на вопрос "есть ли ошибка?", теперь же вопрос стоит "где находится ошибка?". После введения последней комманды prediag, мы получаем элементы подозрительные на наличие этой ошибки.
Вопрос - как обнаружить какой из них ошибочный и какой ошибочный в действительности в данном случае самый главный. Легко заметить, что все подозрительные элементы группируются на ветке одного из выходов. Легко заметить что последний элемент в этой ветке как правило тоже подозрителен.
По тому как я разбирался в алгоритме, я примерно понял, что алгоритмов несколько, или хотябы каждый понимает его по-своему и объяснить в обобществлённой форме этого неможет. К примеру есть вариант где идёт разбиение элементов на группы по принципу "что влияет на OK на выходе и что невлияет", после чего идёт выявление подозреваемой группы.
Мой вариант, возможно неправильный, возможно идентичный тому что выше, но сводится примерно к 3-5 векторам или более.. Основан на таблицах истинности элементов.
Берём самый последний элемент в ветке, который у самого Y стоит.. Тестируем его на три-четыре вектора 00, 01, 11, 10. Последний не очень обязателен, но всё же.. То как вы эти векторы получите в самом начале, уже другая история, но главное это проползти так чтобы конфликтов не получилось. Протестировав эти векторы, мы обязательно получим ошибку.. Скажем ошибка будет на 00, а элемент этот последний - OR, это значит..
Последний OR элемент:
A B Q
0 0 0 <-тут выдалось ERR 0 1 1
1 0 1
1 1 1

Поскольку Error на первой комбинации, то на выходе схемы вместо нуля мы получили единицу из-за ошибки какого-то элемента. Это значит что либо этот самый последний OR элемент ведёт себя так что на выходе всегда даёт единицу, что мы исключаем по условию, либо ошибка затаилась где-то раньше.
Таким образом мы вычёркиваем последний элемент.

Во время создания этого условия чтобы на этот OR поступили именно такие векторы, мы в некоторых случаях вольны выбирать любые значения на некоторых элементах. Имеет смысл выбирать их как можно разнообразней.
Когда у вас имеется 4 вектора, то может легко получиться что остальные элементы тоже прошли все возможные комбинации 00,01,10,11 как вышеназванный OR.

Вычеркнув последний элемент из списка подозреваемых, движемся глубже в схему..
Можем набрести на
NOT
A Q
1 0
0 1 ->ERR
0 1 ->OK
Легко понять, что этот элемент впорядке, поскольку если бы он работал ненормально, то место OK была бы тоже ERR.

Ещё пример OR:
A B Q
0 0 0 ->OK
0 1 1 ->OK
1 0 1 ->ERR
1 1 1 ->OK
Очевидно, что OR не может вести себя как сложная смесь XOR и AND, впрочем я уверен что для него имеется своё название, но суть в том, что в множестве допустимых вариантов AND,NAND и NOR, он ни к чему не подходит, поэтому он в порядке.

Ну и что-бы не вводить в заблуждение что все элементы так уж вычёркиваются, привожу свой ошибочный элемент.. AND
A B Q
1 1 1
1 0 0 ->ERR
0 0 0
Так уж получилось, что два раза вектора совпали, что не дало всех вариантов, но видно, что AND очень уж стремится стать OR-ом.
Задав ещё один, пятый вектор, получил подтверждение, что
0 1 ->ERR
что и дало подтвердило мои подозрения. Удачи.

Домашняя работа​

В качестве объекта выбирается микросхема, реализующая простую комбинационную схему, т.е. схема имеющая множество входов X, логические элементы AND, OR, NOT и выход Y.  Функция для каждого учащегося своя, очевидно что-бы никто не списал.

1. Необходимо составить функцию с которой будет вся работа идти.

2. Нарисовать функцию в схематическом редакторе Cadence, на Solaris-платформе (установлены в IT-корпусе). Использовать надо элементы из HRDLIB библиотеки, причём при создании схемы каждое отрицание над элементом в функции означает обязательный элемент отрицания в схеме. Открываем файл .cshrc и раскомментирываем там строчки
   setenv DFW_97a setenv AMS setenv DFWII
   создаём каталог под домашнюю работу, и там вводим комманду

   ams_cds -tech csx -mode ds
   она видимо подготавливает и вываливает в каталог кучу файлов.
   Дальше прогу можно запускать просто ams_cds коммандой. Cadence запустилась, открываем из меню New Lib. Называем, выбираем don't need...
   Потом создаём новую схему из меню New Cell View.
   Далее разбираемся, ставим входы (красненькие) x1, x2.. x6 , инверторы и прочие логические элементы можно поставить из HARDLIB (называются они соотв. OR22, NA22..). Схему составляем по заданным формулам, в итоге в конце получаем выходы y1, y6 (это для моего случая), их надо объединить элементом OR и сделать один выход Y.

3. Решить дифференциальное уравнение ?Y/?xk, где xk - некий фиксированный номер/элемент. Зачем? Показать насколько сложно и непрактично создавать тест-вектор таким методом.

   Мысль заключается в том что если в математике дифференциал означает скорость изменения функции на участке бесконечно малом и близком к x, то на дискретном пространстве дифференциал означает изменение функции при изменении входа, а функцию изменения входа можно представить как XOR той же функции но с разным значением дифференцируемого входа (XOR=1 если функции различны) :
   ?Y/?xk = Y(xk=0)?Y(xk=1)

   Теперь используя теорию, принимаем что функция Y зависит от xk и любое изменение xk отобразится на значении Y, т.е. ?Y/?xk = 1. Решаем это уравнение и находим все остальные X, которые могут быть и неопределёнными, в итоге получаем тест-вектор, или же возможно что тест вектор получить неполучится, что в свою очередь значит что ?Y/?xk = 0, т.е. этот элемент нетестируем.

4. Создать Structurally Synthesized Binary Decision Diagramm по главной функции Y, который представляет из себя граф, в котором

   • Вершины это входы в конкретный элемент и нумеруются в зависимости от входа в схему, т.е. если в формуле был блок x1(x3+x1)x2x3 ,то для структурного графа это представляет из себя x11(x31+x12)x21x32
   • Движение по вершинам слева направо означает AND-логику и ведёт к 1
   • Движение вниз по вершинам означает OR-логику и ведёт к 0

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

5. Binary Decision Diagramm не учитывает структуры схемы и она используется только для тестирования входов. Создаётся BDD по достаточно простому принципу разложения Шеннона, например:
   Y=x1+x2x3=x2(x1+x3)+!x2(x1+x3)

6. Сгенерировать тест-вектора для всех элементов из Y. Используется SSBDD, полученная в задании 4. См. слайды что-бы понять как конкретно происходит path-activation и fault propagation для SSBDD. Для тестирования элемента на constant 0 выбирается конкретный элемент и по графу выбирается такой путь вправо (к y=1), что-бы он проходил через выбранный элемент. Выбранный путь и есть вектор, однако что-бы элемент был тестируем, надо сделать доступным и альтернативный путь вниз (к y=0). Для того что-бы протестировать все элементы таким образом надо проделать достаточно большую работу по созданию графов с активацией обоих путей (как в обычной ситуации, так и для ошибочной версии) для всех элементов.
   В итоге задания получается таблица вида

   	элементы (x11 x12 x13 x21..)
   векторы	проверяемые неисправности ( =0 =1 X X X )

7. Сгенерировать тесты, обнаруживающие неисправность, вызванную замыканиями парой входов. Принцип - при замыкании входов где 0 и 1 в итоге на обоих будет сигнал 0.

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

9. Протестировать заданные вектора и указать какие ошибки они тестируют

10. Вбить полученную в 6м пункте табличку с векторами в vecmanager и получить на сколько тестируется схема согласно cadence. До этого надо из cadence экспортировать схему в EDIF 2.0.0 из основного меню.
    Помимо правильных полей дизайна, ещё должны быть

    external libraries: HRDLIB design name: название дизайна, любое, хоть свой матриклинумбер output file: imjafaila.edi output format: Netlist Netlist format: FLAT
    затем, лезем в консоль и пишем:
    xtimport -paths -tool cadence imjafaila.edi ams.lib
    xtimport -spec -tool cadence imjafaila.edi ams.lib

    в принципе, можно попробовать указать оба ключа - и paths и spec одновременно, но у некоторых личностей такой способ не сработал - требовалось отдельно две строчки.

    эти две команды создадут 3 файла:
    imjafaila.agm, imjafaila.pat, imjafaila.spec

11. задача в том что.. допустим вектор 1 и 2 говорят что y ошибочен, а все остальные векторы говорят что всё в порядке. смотрим на таблицу открываемых ошибок этими векторами..
    например таблица неисправностей выглядит так..
    10XXXX11100011
    X1XXX10XXX1XX
    111XX1XXXXXXX

    объединяем первый и второй вектора и получаем
    1&XXX1&110&011
    (поскольку неисправности 1 и 0 одновременно не могут быть на одном и том же элементе)
    теперь сравниваем полученную строку с остальными векторами, получаем
    &&XXX&&110&011
    где & значит что на этом элементе ошибки быть не может
    X значит что элемент не тестируется
    1 или 0 значит что на этом элементе есть подозрение.

    В итоге цель задания - обнаружение элемента на котором ошибка имеется, т.е. получение диагноза. Могут быть как несколько элементов, так и вообще не иметься.

Что-бы работать удалённо - из дома делается ssh соединение и дальше (согласно Юре Богданову) из линукса консоль выглядит примерно так

westvleteren:/home/tXXXXXX>mkdir testcad10 westvleteren:/home/tXXXXXX>cd testcad10/ Directory: /home/tXXXXXX/testcad10 /home/tXXXXXX/testcad10 westvleteren:/home/tXXXXXX/testcad10>cad Select your CAD tools: 1) MENTOR 2010 version 2) MENTOR 2004 version 3) SYNOPSYS 2010 version 4) CADENCE 2002 & SYNOPSYS 5) XILINX ISE 12.2 6) XILINX ISE 10.1.3 7) MENTOR 2007 version 8) CADENCE 2005 version 9) CADENCE 08/09 version 0) CADENCE 2009/2010 IC/SYS combined with AMS designkit v3.70 q) no selection ----> 0 Environment ready for Cadence 2009/2010. westvleteren:/home/tXXXXXX/testcad10>ams_cds -mode fb -tech cxq [1] 7998 icfb : HIT-Kit=3.70 tech=cxq

Что-бы распечатать нарисованную схему надо экспортировать схему в PS формат. Для этого надо

1. открыть Design->Plot->Submit.
2. убрать header->Plot
3. установить Options landscape
4. center plot
5. fit to page
6. send plot only to file: imjafaila.ps
7. убрать mail log to

перевести ps в pdf можно коммандой в консоли
ps2pdf imjafaila.ps

Экзамен​

Вариант Антона.. 

1. genereerida diagnostikapuu antud rikketabelile
   Таблица представлена действительно в виде таблицы, мне же лень вырисовывать, поэтому напишу так:
   всего 9 нарушений и 4 вектора. единицы расположены так:
   T1: 1, 4, 5, 9
   T2: 2, 4, 7, 8
   T3: 5, 6, 7, 9
   T4: 1, 3, 4, 6, 7
2. дана схема (см рисунок). задание: genereerida kaks testvektorit kahe boole'i v?rrandis?steemi dy1/dz1 = 1 ja dy1/dz2 = 1 lahendamise teel, kasutades ahelv?rrandis?steemi lahendamise meetodit.
3. teoreetiline kysimus: testide genereerimine mikroprotsessoritele.

Вариант Дана.. 

1. Транизсторная схема + вероятность закорачивания в двух местах (ЭФ). Найти тествектор который выявляет ЭФ.
2. генерация теста по методу DNF
3. Sequuential Fault Diagnosis

Вариант Вадима

1. поставить диагноз маленькому уравнениею используя Булев полный дифференциал.
2. по данному уравнению составить бинарную диаграмму и найти на входе х3 константные ошибки
3. представление операционного автомата с помощью отсустус диаграмм 

Мой вариант..

1. Нарисовать SSBDD по формуле и протестировать с её помощью один из элементов.

2. Дана схема и два вектора. Написать на что они тестируют элементы.. т.е. нарисовать табличку.

3. Теоретический вопрос (там было порядка 15ти), мне попался первый - полное дифференциальное уравнение, обнаружение ошибки.

Потом посмотрел домашку, я чуток порассказывал. Поспрашивал что значат hhlhlhH в таблице, которую vecmanager выдаёт и почему некоторые буквы большие (я про фронты начал говорить, а это просто ноль и единица на входах и на выходе). Потом на задании 2 показал два провода - допустим тут замыкание, как это протестировать. Я то помнил что надо разные значения кидать, но думал что единица будет ноль перезаписывать, но когда high(1) и земля(0), то всё в землю уходит и на обоих будут нули.