среда, 26 октября 2016 г.

Архитектура информационных систем. Эксперименты преподавания

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

1. Зачастую у преподавателя отсутствует глубокий практический опыт, но имеются отличные теоретические знания

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

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

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

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

Чтобы добиться этого, нужно сократить число задач или число студентов на одного преподавателя. А из обучения сделать игру, максимально похожую на то, что происходит в реальности. Число студентов - объективная реальность, данная нам в ощущениях, и изменению не подлежит. Потому тут два пути: или давать одну задачу на всех, или объединять студентов в команды, сокращая число задач и число студентов на единицу преподавателя.

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

Поэтому я выбрал другой путь, объединение студентов в команды и выполнение единого на команду проекта. У меня уже есть достаточно богатый опыт организации обучения в виде командного проекта, когда вся группа "нанималась" для разработки конкретного продукта. Результаты были опубликованы на конференции Объектные системы [Галиаскаров Э.Г., Умнов Д.М., Агеев М.С. Организация учебного проекта разработки программного обеспечения информационной системы]. Такие семестровые проекты организовывались на 5 курсе. Это было очень удобно. У меня был большой 200 часов курс, а к этому времени у студентов уже были пройдены практически все профильные предметы (технология программирования, теория информационных процессов, управления данными, моделирование систем, корпоративные ИС, проектирование ИС и т.п.), сделан ряд курсовых проектов, пройдены все возможные практики, выполнена защита квалификационной работы бакалавра. Таким образом, этот подход позволял мне сосредоточиться не на передаче новых знаний, а на систематизации знаний студента, на том, чтобы дать им практическую направленность, сформировать и закрепить навыки решения сложных задач, работать в команде.

Для создания духа соревновательности было решено делать не один, а несколько проектов. Количество проектов зависит от количества команд, а количество команд от общего числа студентов. Идеально иметь две команды, которые соревнуются друг с другом, но они могут быть слишком велики. Оптимальное количество студентов в команде 6-8, 10 - это уже предел. Учитывая общее количество студентов в группе, я организовал 3 команды по 9 человек.

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

Так получилось, что мне посчастливилось познакомиться с Сергеем Немеровым, удивительно талантливым и творческим человеком. Он с готовностью мне помог и набросал десяток занимательных тем. Я настолько восхитился оригинальностью мышления Сергея, что тут же попросил его стать сторонним консультантом и одновременно играть роль строгого заказчика, такой темной лошадкой, мистером Х, с которым командам нужно работать, понимать его нужды, добиваться его внимания и финансирования своего проекта. Вообщем, типичный stakeholder!

Формирование команд тоже происходило довольно неформально. Хороший каламбур получился. Для начала ребятам было предложено самим объединиться в три команды. Чтобы получить какой-то опыт взаимодействия и понять к какой команде все-таки примкнуть, предварительно были проведены несколько деловых игр. Самая значительная из них - игра в архитектора.

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

Архитектор организует работу по проекту и представляет результаты в конце заказчику. 15 минут отводится на сбор требований их анализ и формирование решения. 5-10 минут на подготовку проекта к презентации. 5 минут на презентацию проекта Заказчику.

До начала игры Заказчик выводится за дверь, и ведущий предлагает ему записать свои требования к Дому Его Мечты. Документ изымается до конца игры.

Команде объясняются правила игры: общение с заказчиком только письменно, через ведущего. Можно задавать любые вопросы, но они должны быть конкретны, не в открытой произвольной форме. Т.е. нельзя написать - Какой дом ты хочешь иметь? Можно - Сколько этажей? Какая площадь? Стены должны быть каменными? Нужна ли баня? Каков бюджет проекта? Как быстро должен быть построен дом? и т.п.

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

На презентации результатов сравниваем, что написано у заказчика, а что сделано командой. Окончательное слово остается за заказчиком.

Кстати, игра сразу показала, что стоит каждая команда. кто лидер. а кто аутсайдер. Это сохранилось и в дальнейшем.

После формирования команд происходил выбор и согласование тем. Были выбраны такие темы:
 - социальная сеть управления и пропаганды в РККА "Товарищи"



 - интернет-магазин древнего оружия "300 Спартанцев"


 - новостной портал Золотой орды "Благие вести"


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

Все свои артефакты команды хранили на GoogleDocs, а общение производили в социальной сети ВКонтакте.

Все учебные материалы и рекомендации были представлены на сайте курса учебного портала ИГХТУ. На форуме курса я подводил итоги каждой итерации, подробно прописывал выявленные недостатки или упущения, размещал рекомендации от Сергея Немерова и свои.

Результаты оценивания каждой итерации также сводились в специальную ведомость.

Необходимость оценивания с одной стороны вынужденная мера. Нужно было три раза в семестре выставлять оценку за контрольную точку и за семестр в целом. С другой стороны - это был некий критерий эффективности команды, той основой, которая позволила определить победителя. Оценка формировалась довольно сложно. Каждый студент в семестре мог иметь до 100 баллов. Общая сумма баллов на группу 2800. Эта сумма пропорционально делится по командам. Также сумма делится по возможности равномерно по итерациям. Оценка за итерацию ставится всеми преподавателями, экспертами. Эта сумма передается команде, и далее команда сама распределяла баллы между участниками. Интересно, что сначала это была стратегия равномерного распределения, но постепенно распределение баллов уже стало происходить по справедливости и по вкладу. К сожалению некоторые студенты стали филонить, игнорировать выполнения своих задач, подводить свои команды, что незамедлительно стало сказываться на общей оценке. Возможно, такая система оценок сложна и не идеальна, но она работает. Но я всегда открыт для дискуссии и новых идей, как это сделать лучше.

Процесс проектирования архитектуры включал в себя три этапа: анализ требований, функциональный анализ и синтез архитектуры.

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

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

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

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

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

В качестве инструментальной поддержки предлагалось использовать иерархические списки, таблицы, UML, диаграммы потоков данных, IDEF1x, mindmap, вообщем, все то, что студенты сочтут для себя полезным, а преподаватель намекнет или сумеет убедить их это использовать.

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

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

Второе место заняла команда "Неваляшки" с проектом новостного портала "Благие вести".

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

Отдельно хочу отметить команду, которая заняла первое место. Вообще эта команда меня приятно удивила, своей сплоченностью, нацеленностью на результат, работоспособностью, стремлением лучше понять свою задачу, проактивностью, результативностью, дисциплиной. Можно сказать единственная команда, которая вовремя предоставляла результат каждой итерации, присылала распределение оценок экспертов. Интересно, что в этой команде была одна единственная девушка и более того, она взяла на себя функцию руководителя команды, была ее лидером. А какие она письма по итогам итерации присылала! В письме кратко, но очень ясно описывался результат, который команда получила, по пунктам, сопровождая каждую тему ссылкой на материал, который нужно посмотреть эксперту, в конце письма всегда приводилась ссылка на общий репозиторий. Это очень экономило время при знакомстве с результатами итерации. Я очень надеюсь, что эту талантливую девушку ждет интересное будущее. Обращайтесь, если хотите видеть ее в своей команде прямо сейчас, пока Яндекс не переманил.

Что не удалось сделать, но хотелось бы.
Научиться оценивать архитектурные решения. Т.е. провести сессии, при которых команды конкуренты оценивают проект своего конкурента в соответствии с заданной методикой типа АТАМ.

Также следует проработать и получить минимальный набор артефактов и подготовить шаблоны оформления документации.

Также нужна помощь и поддержка сторонних специалистов на стадии функционального анализа и выработки архитектурных решений. Возможно, делу помог бы атлас архитектурных решений, но увы его в сколь-нибудь организованном виде не существует. Правда, в какой-то степени можно воспользоваться подборкой на wiki: https://en.wikipedia.org/wiki/Architectural_pattern.

Ну и напоследок хочу привести несколько отзывов студентов:

Отзыв 1:
Формат проведения данного курса показался очень необычным, с точки зрения обычного обучения в ВУЗе, а с другой стороны, очень познавательный, т. к. позволил поработать в довольно большой команде, выполняя поставленную преподавателем (заказчиком) задачу.
Здесь конечно же проявились как плюсы, так и минусы.

К минусам я бы отнесла, во-первых, невозможность работы с реальным заказчиком, от которого мы бы могли получить его конкретные требования, пожелания, вместо этого приходилось изучать исторические моменты, характеры и идеологию личностей и народа того времени. Это очень помогало, но все равно не удалась избежать недопонимания в команде. Мы смотрели на то общество с точки зрения нашей повседневности, и нам было трудно представить наличие гаджетов, доступа к интернету у военнослужащих РККА: возможно они бы их использовали совершенно иначе, чем мы?
Во-вторых, я бы отнесла к минусам и объединение в команды людей с совершенно разной мотивацией, и, как следствие, работоспособности и дисциплины отдельных членов команд. Некоторые не были заинтересованы в получении практики (из-за отсутствия времени и, возможно, интереса к данному виду работы в команде).
В-третьих, мне показалось недостаточным интерес со стороны стороннего эксперта, возможно, из-за отсутствия времени или возможностей. Мое мнение, возможно он оценивал нас как UX-дизайнеров, от него не получила почти никакого взаимодействия, ответов на писем.
И последний минус: как мне показалось, сначала было очень сложно понять, что от нас конкретно требуется. Полное отсутствие опыта делало нас очень "заторможенными" в понимании того, что мы делали. Но благодаря живому общению с преподавателем, а также комментариев и заметок к документам, изучению статей, книг, мы пытались исправлять свои ошибки, тем самым набираясь опыта и знаниями.

К плюсам конечно же относится возможность командного проектирования ИС. Мы изучали информацию, статьи, делились ими между собой, пытались объяснять друг другу непонятные моменты, высказывали свои точки зрения, выбирали наилучшие. Иногда даже были небольшие столкновения и недопонимания, что позволяло искать аргументы, доказательства своей правоты, желание сделать что-либо лучше. 
Так же к плюсам я бы отнесла  то, что все-таки у большинства появился азарт, соперничество между командами, борьба за баллы, что, как мне показалось, моделировало реальные условия разработки ИС: получение прибыли от продукта, конкуренция между компаниями.
И последний плюс, лично от меня, как от представителя и руководителя команды: мне было очень интересно координировать работу команды, пытаться ставить перед ней конкретные задачи, мотивировать на их выполнение. Очень приятно что все члены команды принимали участие, кто-то в большей мере, кто-то в меньшей, но все старались внести свой вклад. 

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

В целом, курсом осталась довольна, и если бы мне пришлось пройти его снова, то уже бы подошла к нему с более высокого уровня знаний, что позволило бы ощутить его дополнительные достоинства. Работа архитектора мне понравилась, но нужен очень большой опыт и знания, чтобы с ней справиться.
Отзыв 2:
В целом курс понравился, но есть не мало минусов. В основном эти минусы по проведению. Не очень понравилось работать в группах по 8-9 человек, некоторые вообще ничего не делали и получалось, что мы очень отставали. Так же не понравилось, что плохо поддерживали связь с внешним заказчиком, вроде человек взял ответственность на себя, что будет поддерживать связь, но под конец пропал у него видимо интерес, что очень расстроило. Хоть и объемный курс, много вопросов появляется во время реализации задания, но все же, наверное, лучше по 3-4 человека работать.Из всего курса очень понравилось реализовывать сам сайт, хотя это скорее всего, потому что я человек творческий и мне больше нравится что-то "творить" :) Работа архитектором мне была интересна, многое для себя нового открыла. Были моменты, которые я немного не понимала: можно даже начать с тем, когда я их увидела, то вообще никак не могла понять их смысла и долго очень привыкала к интернет-магазину в Спарте ) поэтому в начале курса были небольшие проблемы с заданиями.Еще понравилась идея с внешним заказчиком, хоть и не часто с ним общались, но было бы, я думаю, интересно пообщаться с ним даже в том же скайпе и рассказать все наши идеи, а не в документах представлять. Все же при общение больше говоришь, нежели в письменном виде.
А так, курс интересный, сложновато конечно, но в целом было познавательно. 

Отзыв 3:
Это очень интересный и важный предмет. На счет формата проведения - это Вы здорово придумали =) Здоровая конкуренция это хорошо =) 
На самом деле я не особо разобралась в том, что же делает архитектор =( Нет, я понимаю, что он строит саму архитектуру, так сказать "каркас", но не особо поняла в чем же он заключается. Возможно я просто плохо слушала 

воскресенье, 26 июня 2016 г.

Список литературы, рекомендуемой студентам по категории

Общая теория систем. Теория информационных процессов и систем


Работа с требованиями

UML и объектно-ориентированная разработка


Архитектура ПО и ИС

Управление данными и SQL

ФайлФайлФайл

понедельник, 7 апреля 2014 г.

Прецеденты в Архитектуре информационных систем

Готовлюсь читать "Архитектуру информационных систем" в университете. Решил создать на  linkedin тему "Use Cases in Architecture of Information Systems".

Английский у меня так себе, сформулировал вопрос так. Чур не смеяться.

It so happend that I have to teach Architecture of Information Systems (ISA) for our students. I have read a lot of books and arcticles but all of them is devoted to software architecture but none to ISA. Then I mage conclusion SWA = ISA.
Thus UCs can be applied for development of architecture. Could you share how it do?Links, arcticles, books welcome!

Получил интересный ответ от John Watson

Let’s start with the idea that Use Case ovals in a Use Case diagram represent the functions of the SuD but do not represent components of the SuD. 
Now consider an Automatic Telling machine (ATM) system that has the actors Customer, Maintainer, and Bank. 
The ATM functions of interest (Use Cases) from the Customer viewpoint are Get Cash, Get Account Balance, and Transfer Funds. The Bank actor provides validation services in relation to the Customer functions. 
The ATM functions of interest from the Maintainer viewpoint are Replenish Consumables and Get Audit reports which both require Bank services as well. 
Both Customer and Maintainer use a Manage Access service of the ATM which also uses Bank services. 
The human actor roles are Customer and Maintainer. There is one non-human actor role; Bank. 
In order to allow human and ATM interaction, a Human Interface (HI) software component is required. The HI component provides, via interfaces, services like readKeyboard, writeToScreen, issueCash, printOutput. 
In order to allow machine and ATM interaction, a System Interface (SI) software component is required. The SI component, via interfaces, provides services like validateAccessCredentials, validateTransaction. 
The Use Case Manage Access is realised via a Security Services (Sec) component which, via interfaces, provides services like logOn, logoff. The Customer Transaction Handler via interfaces provides services like getCash, getBalance, transferFunds. 
The Maintenance Transaction Handler via interfaces provides services like replenishConsumables and getAuditReports. 
I would use a Component Diagram to illustrate the above architecture. The components would be related via Required Interface “cups” and Supplied Interface “ball” relationships. 
The Component Diagram would be supported by a Class Diagram and perhaps a Package Diagram. To make the transition from Class to both Package and Component Diagrams I would probably produce Sequence Diagrams.

Коллега заметил:

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

Я все-таки решил визуализировать то, что описал уважаемый John Watson. 

Now consider an Automatic Telling machine (ATM) system that has the actors Customer, Maintainer, and Bank. 

The ATM functions of interest (Use Cases) from the Customer viewpoint are Get Cash, Get Account Balance, and Transfer Funds. The Bank actor provides validation services in relation to the Customer functions. 

The ATM functions of interest from the Maintainer viewpoint are Replenish Consumables and Get Audit reports which both require Bank services as well. 

Both Customer and Maintainer use a Manage Access service of the ATM which also uses Bank services. 
fig 1
In order to allow human and ATM interaction, a Human Interface (HI) software component is required. The HI component provides, via interfaces, services like readKeyboard, writeToScreen, issueCash, printOutput. 
In order to allow machine and ATM interaction, a System Interface (SI) software component is required. The SI component, via interfaces, provides services like validateAccessCredentials, validateTransaction.
The Use Case Manage Access is realised via a Security Services (Sec) component which, via interfaces, provides services like logOn, logoff. 
The Customer Transaction Handler via interfaces provides services like getCash, getBalance, transferFunds. 
The Maintenance Transaction Handler via interfaces provides services like replenishConsumables and getAuditReports. 
fig 2

четверг, 25 июля 2013 г.

Викторина по 3SL Cradle

Hello Alexandra, Alexey and Eduard

Congratulations on your success in the Cradle quiz organised by Yulia from SATURS!

Everyone in 3SL would like to thank you for taking part in the quiz and for the very high scores that you all achieved. We are very pleased that you have learnt so much about Cradle!

Yulia from SATURS will provide your prizes very soon.

We hope that you will obtain real benefits from using Cradle and - even though it is 'work' and not 'play', we hope that you will enjoy using it!

With very best wishes

Mark
By Mark Walker

воскресенье, 7 июля 2013 г.

ЛАФ 2013. Кирилл Шишаев. Бокс vs Айкидо или о том как правильно задавать вопросы

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

Не скажу, что тема для меня не знакома, но именно в такой подаче я ее слушал впервые. Искусство задавать вопросы важная часть любой практики ведения интервью и переговоров. Не так давно я читал книгу Ричарда Шелла "Удачные переговоры. Уортонский метод" и потому многие моменты мне казались спорными. Ведь все определяется контекстом, той ситуацией, в которой вы находитесь, целями, которые вы пытаетесь достичь.

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

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




ЛАФ 2013. Наталья Желнова. Ошибки аналитиков при определении нефункциональных требований

Ну, Наталья Желнова - известный оратор и тренер. Я знаю, что она работала или сотрудничала с учебным центром "ТЕКАМА", активно проводит тренинги по требованиям и не только в разных уголках нашей страны.

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

Единственное, что я не совсем понял, а какие ошибки допускают аналитики при определении этих требований и как с этим бороться.

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






ЛАФ 2013. Юрий Куприянов. Стандарт OMG Essence - в чем польза для аналитика?

С интересной темой и весьма виртуозно выступил Юрий Куприянов. Отличный оратор, где-то даже актер. Уверено держит себя с аудиторией, четко понимает что и кому говорит.

Доклад посвящен не так давно начатой Иваром Якобсоном инициативе, названной им SEMAT.   При этом инициатива переросла во что-то большоеНе хочу пересказывать, то, что было в докладе, кому интересно посмотрите презентацию. В скором будущем, надеюсь, будет и видеозапись выступления.

Тема меня заинтересовала, с SEMAT я немного знаком. Как относится к этому явлению не понятно. Хотя ряд ответом можно найти в блоге Анатолия Левенчука, который довольно активно использует стандарт в обучении. Также отсылаю к его презентации. Более того, я пытаюсь на базе читаемых курсов вести учебные проекты, в которых задействованы все студенты группы. Формализации порой не хватает, с другой стороны неплохо иметь некоторую основу для конструирования своих процессов. Статья на тему реализации учебных проектов вскоре будет опубликована на сайте конференции "Объектные системы".

И хотя SEMAT или OMG Essence пока еще не является стандартом, тем не менее некоторые концепции вполне можно применять, хотя бы как основа для формализации своих регламентов и походов.