Занимаюсь по работе активно технологическим развитием заказчиков из финансового сектора и в частности страховых компаний. Даже написал статью в журнал "Современные страховые технологии" про основные тренды в мировом ИТ и их отображении на страхование. Собственно сама статья тут, правда доступ к ней платный ... http://www.consult-cct.ru/strahovanie/It-adaptaciya-trendy-v-razvitii-informacionnyh-tehnologij.html. Уточню в редакции, можно ли будет ее публиковать у себя в блоге.
пятница, 27 декабря 2013 г.
воскресенье, 10 марта 2013 г.
Методология, свод знаний, процессный фреймворк, нотация, стандарт ... как тут не запутаться?
Почитал обсуждение на UML2.RU, по его мотивам решил немного порассуждать по этой теме. Собственно вопрос в том, что иногда возникает в головах путаница что есть что и как эти понятия с собой соотносятся. По-хорошему для того, чтобы бы не путаться следует создавать глоссарий (или использовать готовые, англоязычные, только иногда имеет смысл делать их value added перевод :-) ).
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
воскресенье, 30 сентября 2012 г.
Анатолий Карачинский и Цукерберг ...
Таки да, бросилась в глаза заметка на CNews http://www.cnews.ru/top/2012/09/28/glava_ibs_potryasen_chto_cukerbergu_ne_stydno_vstrechatsya_s_medvedevym_504718 про возмущение основателя IBS предложением Facebook по "эвакуации талантов". Только мне не вполне понятны мотивы для такого возмущения ... анализируя возможные причины, можно предположить следующее:
1. А. Карачинскому "за державу обидно", т.е. имеем ментальные причины
2. У возмущения есть материальные причины ...
Зная специфику работы наших системных интеграторов особенно с госсектором, в духовность и прочия как-то не очень верится. А вот сожаление, что кто-то соблазнится на более комфортные условия жизни из тех, на труде которых компания сейчас зарабатывает - это вполне понятный повод для возмущения.
Тут можно много говорить о том, что и в России талантливые разработчики могут хорошо зарабатывать, но жить все-равно комфортнее там - и инфраструктура лучше и климат теплее и медицина лучше, да и продукты питания можно выбирать ОРГАНИК и даже при продажи рыбы в магазине понятно ее происхождение - дикая или выращенная на ферме... Так что тут можно не обсуждать тему....
Еще один аргумент возмущающихся - это полученное якобы за счет государства образование, которое талантливый выпускник вуза не отработал. Тут вот хотелось бы разораться ... Коль скоро ВУЗ был государственный, значит существовал в т.ч. на налоги родителей выпускника. Тогда получается, что за образование ребенка родители уже заплатили своими налогами? Тогда какие претензии?
При текущем раскладе, когда национальной идеей элиты является "делать деньги в России для комфортной жизни за границей" пытаться удерживать таланты в стране призывами к морали, чувству долга - верх цинизма. Все подобные разговоры следует рассматривать не более чем желание сохранить ресурсы, на которых можно, совершенно верно - "делать деньги в России для комфортной жизни за границей" ...
1. А. Карачинскому "за державу обидно", т.е. имеем ментальные причины
2. У возмущения есть материальные причины ...
Зная специфику работы наших системных интеграторов особенно с госсектором, в духовность и прочия как-то не очень верится. А вот сожаление, что кто-то соблазнится на более комфортные условия жизни из тех, на труде которых компания сейчас зарабатывает - это вполне понятный повод для возмущения.
Тут можно много говорить о том, что и в России талантливые разработчики могут хорошо зарабатывать, но жить все-равно комфортнее там - и инфраструктура лучше и климат теплее и медицина лучше, да и продукты питания можно выбирать ОРГАНИК и даже при продажи рыбы в магазине понятно ее происхождение - дикая или выращенная на ферме... Так что тут можно не обсуждать тему....
Еще один аргумент возмущающихся - это полученное якобы за счет государства образование, которое талантливый выпускник вуза не отработал. Тут вот хотелось бы разораться ... Коль скоро ВУЗ был государственный, значит существовал в т.ч. на налоги родителей выпускника. Тогда получается, что за образование ребенка родители уже заплатили своими налогами? Тогда какие претензии?
При текущем раскладе, когда национальной идеей элиты является "делать деньги в России для комфортной жизни за границей" пытаться удерживать таланты в стране призывами к морали, чувству долга - верх цинизма. Все подобные разговоры следует рассматривать не более чем желание сохранить ресурсы, на которых можно, совершенно верно - "делать деньги в России для комфортной жизни за границей" ...
пятница, 6 июля 2012 г.
Не попал на ЛАФ 2012 :-(
Только вернулся из отпуска ... к сожалению не смог попасть на ЛАФ 2012 в Иваново. Надеюсь на следующий год получиться!
четверг, 23 февраля 2012 г.
О дискуссии по поводу статьи А. Новичкова и Ко на uml2.ru/
С сожалением был вынужден ввязаться в дискуссию которая развернулась на форуме uml2.ru http://www.uml2.ru/forum/index.php?topic=4634.0 по поводу статьи А. Новичкова и Ко об ИТ и психологии. Для меня было интересным не столько сама публикация, сколько развернувшаяся дискуссия (хотя дискуссией ЭТО назвать достаточно сложно). Лишний раз убеждаюсь в справедливости утверждения, что там где одни видят проблемы - другие видят возможности. Тема психологии и отношений в ИТ командах на текущий момент в России особо не раскручена - не упакована как следует и не подана как товар. Я еще в свою бытность фрилансером на полном серьезе обдумывал при комплексном обучении аналитиков давать им определенные навыки психологии общения (с заказчиком и с коллегами-разработчиками). Даже помнится с Александром Байкиным мы обсуждали эту тему с одной дамой, которая делала тренинги по "психологии в бизнесе". И вот эта тема получила продолжение в том, чем занимается Александр Новичков. В то же время, один из участников дискуссии, занимающийся обучением аналитиков, в форме, далекой от цивилизованной дискуссии банально охаивал данную публикацию А. Новичкова. Я честно порекомендовал коллеге вместо "наезда" использовать эту тему и совместно с автором "доточить", упаковать и довести до состояния товара - давая дополнительные знания аналитикам. Однако коллега столь сильно увлекся самовыражением, что перестал воспринимать здравые рекомендации по расширению собственного же бизнеса - пытаясь не оставить камня на камне от публикации и автора лично. Эмоции вредят бизнесу, так же как и позиция видения проблем, там где можно найти возможности .... Хотя не удивлюсь, если через некоторое время в курсе коллеги появится соответствующий раздел о психологии общения и т.п. .... .
Изменения в карьере .... не опять, а снова :-)
Что-то я забросил свой блог совсем. Признаться времени с середины прошлого года не было вообще .... проекты сплошняком (особенно запомнилась работа по проекту НПРОД ;-))). А потом смена работы ... да, я перешел в ноябре 2011 года в компанию Microsoft, на позицию Account Technology Strategist (честно говоря я сам не понимаю как это перевести адекватно на русский, хотя у меня есть несколько идей ... - может у кого еще есть идеи ?). Теперь занимаюсь, скажем так, технологическим развитием конкретных заказчиков (за которых отвечаю я в паре с Account Manager) из банковского сектора и страховых компаний ....
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
вторник, 3 мая 2011 г.
Полезные ссылки на бронирование отелей, прокат автомобилей, авиабилеты и т.д.
Все тут: http://smarttravel.livejournal.com/ ... лично я воспользовался советами ... :-)
пятница, 18 февраля 2011 г.
Про "большое Сколково" ...
Озаглавил именно как "большое Сколково", т.к. уже несколько раз сталкивался с тем, что многие ассоциируют МШУ Сколково и "инноград" Сколково, считая что это одно и то же. Приходится пояснять, что это разные организации. Подумалось, что они разные даже по своей идее - если МШУ это скорее исследования в области развивающихся рынков, цель же иннограда, на мой взгляд, именно вытащить нас всех из этого вечного "развития" в светлое будущее "развитого капитализма" :-). Но собственно мне всегда было интересно, как "на западе", на фоне сообщений о намерениях и подписанных договорах с большими корпорациями все-таки относятся к этому проекту иннограда. В "бытовых" разговорах/переписке, мало кто из моих собеседников высказывался оптимистично по поводу перспектив большого Сколково. А тут, однажды слушая в машине радио наткнулся на передачу по Финам, в которой для беседы были приглашены два западных журналиста (одна из них - дама, как я понял родилась в России). Рассуждали про Россию и ее имидж в мире и т.п. Когда их спросили как вообще настроение на западе по их ощущениям в отношении большого Сколково - я получил лишнее подтверждение "бытовой" точке зрения - не верят в этот проект на западе. Почему меня это не удивляет?
понедельник, 13 декабря 2010 г.
Возвращаясь к вопросу о use cases и функциях ...
Читая форум UML2.RU, натолкнулся на дискуссию о том что функции системы дублируют юзкейсы, и вообще не понятно что есть что и для чего, кроме этого такие же вопросы иногда возникают у коллег по работе, и у заказчиков, для которых в силу специфики их систем, я разрабатываю еще и модель вариантов использования (Use Cases).... В данной заметке я решил дать краткое пояснение по данному вопросу, не слишком вдаваясь в формальные определения, а больше по сути вопроса.
Юзкейсы (Use Cases, варианты использования) - это взгляд с т.з. пользователя на систему, который дает ответ на вопрос какие свои задачи (в терминах того же Коберна - цели) решает пользователь при помощи системы, и что при этом делает система в ответ на действия пользователя. Юзкейсы относятся к т.н. "пользовательским требованиям" (по "классификации" Вигерса).
Функции - это некие свойства системы, или нечто полезное, что может делать система, в т.ч. для внешнего по отношению к ней пользователя. Функции системы - это, если так можно выразиться, взгляд "изнутри" системы на ее окружение. Кстати, говорить о функциях системы можно только на этапе ее проектирования. Т,е. когда речь идет о том, что эти функции уже определены и мы их перечисляем, и поясняем механизм их реализации. На этапе требований - можно говорить только о ТРЕБОВАНИЯХ к функциям (или иначе - функциональным требованиям). Т.е. на этапе разработки требований, функций системы как самостоятельных артефактов еще нет, есть только требования к ним!
О разнице м/у юзкейсами и функциями. Юзкейсы не являются функциями а) по-определению б) по своей природе. Поясню на примере - юзкейсом для системы управления корпоративной печатью вполне может быть, например, "Распечатать документ" - это цель пользователя, явная и достаточно крупная. В то же время функцией такой системы может быть "Авторизация пользователя на устройстве печати посредством смарт-карты", или "Удаление заданий из очереди печати (после распечатки)", но таких юзкейсов у системы не будет (как минимум в данном контексте). Еще одной отличительной чертой является то, что функции, в отличии от юзкейсов, могут иметь жесткую иерархию, и могут быть декомпозированы (т.е. двигаясь вниз по иерархии - они будут детализировать "верхнюю" функцию).
Основной вопрос возникает как совмещать оба подхода при разработке требований к системам. И как не допускать явного дублирования. Тут есть несколько подходов.
Есть подход "a-la RUP", в котором юзкейсы могут рассматриваться как основа требований, и дальше разрабатывается только доп. спецификация - в которой описываются те аспекты (часть функциональных требований и нефункциональные требования), которые не затронуты юзкейсами и производится трассировка их на юзкейсы.
Есть подход Вигерса - где наряду с юзкейсами описывается полноценное SRS, в котором перечисляются именно функциональные требования и они так же, могут быть оттрассированы на юзкейсы.
Есть подход без использования юзкейсов - когда можно описать всю возможную функциональность в виде иерархического списка функциональных требований, и при этом вполне могут быть такие высокоуровневые функции (для той же системы управления печатью), как "Печать документа", "Копирование документа", и т.п, которые просто будут декомпозированы. А если при этом распределить эти функции по типам пользователей, то в принципе можно получить представление о том, каким пользователям какая функциональность доступна. При этом можно говорить о формулировке требований в формате "Система должна иметь возможность ..." и "Пользователь должен иметь возможность...". В этом случае можно высокоуровневыми требованиями сделать a-la пользовательские ("Пользователь должен иметь возможность..."), и декомпозировать их чисто функциональными ("Система должна иметь возможность ...").
В любом случае, если есть сомнение "to Use Case or not ...", следует четко понимать, какую дополнительную ценность принесут юзкейсы, не только для разработки требований, но и для проектирования, тестирования и проведения приемо-сдаточных испытаний. И исходя из этого принимать решение, какой из подходов использовать.
Юзкейсы (Use Cases, варианты использования) - это взгляд с т.з. пользователя на систему, который дает ответ на вопрос какие свои задачи (в терминах того же Коберна - цели) решает пользователь при помощи системы, и что при этом делает система в ответ на действия пользователя. Юзкейсы относятся к т.н. "пользовательским требованиям" (по "классификации" Вигерса).
Функции - это некие свойства системы, или нечто полезное, что может делать система, в т.ч. для внешнего по отношению к ней пользователя. Функции системы - это, если так можно выразиться, взгляд "изнутри" системы на ее окружение. Кстати, говорить о функциях системы можно только на этапе ее проектирования. Т,е. когда речь идет о том, что эти функции уже определены и мы их перечисляем, и поясняем механизм их реализации. На этапе требований - можно говорить только о ТРЕБОВАНИЯХ к функциям (или иначе - функциональным требованиям). Т.е. на этапе разработки требований, функций системы как самостоятельных артефактов еще нет, есть только требования к ним!
О разнице м/у юзкейсами и функциями. Юзкейсы не являются функциями а) по-определению б) по своей природе. Поясню на примере - юзкейсом для системы управления корпоративной печатью вполне может быть, например, "Распечатать документ" - это цель пользователя, явная и достаточно крупная. В то же время функцией такой системы может быть "Авторизация пользователя на устройстве печати посредством смарт-карты", или "Удаление заданий из очереди печати (после распечатки)", но таких юзкейсов у системы не будет (как минимум в данном контексте). Еще одной отличительной чертой является то, что функции, в отличии от юзкейсов, могут иметь жесткую иерархию, и могут быть декомпозированы (т.е. двигаясь вниз по иерархии - они будут детализировать "верхнюю" функцию).
Основной вопрос возникает как совмещать оба подхода при разработке требований к системам. И как не допускать явного дублирования. Тут есть несколько подходов.
Есть подход "a-la RUP", в котором юзкейсы могут рассматриваться как основа требований, и дальше разрабатывается только доп. спецификация - в которой описываются те аспекты (часть функциональных требований и нефункциональные требования), которые не затронуты юзкейсами и производится трассировка их на юзкейсы.
Есть подход Вигерса - где наряду с юзкейсами описывается полноценное SRS, в котором перечисляются именно функциональные требования и они так же, могут быть оттрассированы на юзкейсы.
Есть подход без использования юзкейсов - когда можно описать всю возможную функциональность в виде иерархического списка функциональных требований, и при этом вполне могут быть такие высокоуровневые функции (для той же системы управления печатью), как "Печать документа", "Копирование документа", и т.п, которые просто будут декомпозированы. А если при этом распределить эти функции по типам пользователей, то в принципе можно получить представление о том, каким пользователям какая функциональность доступна. При этом можно говорить о формулировке требований в формате "Система должна иметь возможность ..." и "Пользователь должен иметь возможность...". В этом случае можно высокоуровневыми требованиями сделать a-la пользовательские ("Пользователь должен иметь возможность..."), и декомпозировать их чисто функциональными ("Система должна иметь возможность ...").
В любом случае, если есть сомнение "to Use Case or not ...", следует четко понимать, какую дополнительную ценность принесут юзкейсы, не только для разработки требований, но и для проектирования, тестирования и проведения приемо-сдаточных испытаний. И исходя из этого принимать решение, какой из подходов использовать.
воскресенье, 17 октября 2010 г.
Не удалось посетить SECR-2010. Я много потерял?
В этом году мне не удалось посетить конференцию SECR-2010. Честно говоря, когда я посмотрел ее программу, лично у меня она не вызвала явного интереса. Судя по некоторым отзывам - http://blogs.uml2.ru/post/SECR-2010-pervye-vpechatleniya как-то безрадостно.... Неужели все идет по принципу "Что может быть хуже чем Робот-полицейский-2?" - "Робот-полицейский-3!!!"? Интересно было бы узнать мнения посетивших ....
вторник, 5 октября 2010 г.
Почитал заметку про реакцию на новую школьную программу по информатике ...
Тут http://cnews.ru/news/top/index.shtml?2010/10/04/410981 опубликована заметка про реакцию "представителей ИТ-сообщества" на новую школьную программу по информатике. Не перестаю удивляться нашим академикам от образования ... зачем детям такой объем знаний? Больше всего мне нравятся заявления про то, что большую часть времени преподавание информатики может происходить без компьютеров (по этой программе)! Видимо авторы программы не в курсе про инициативы правительства об информатизации школ и т.п. Интересно, какие задачи призвана решать такая программа образования? Кого готовить? Будущих студентов ИТ-специальностей ВУЗов?
IMHO, на теоретические аспекты по информатике следует отдавать не более 20% времени. Более ценным для школьников было научить их печатать вслепую (страшно смотреть, когда молоденькая операционистка в банке, тычет одним пальцем, набирая мою платежку ..., а ведь изучала в школе информатику!). И научить использовать текстовые редакторы и электронные таблицы для решения прикладных задач (да хоть на примере учета расхода собственных карманных денег). Это бы позволило решить вопрос элементарной компьютерной грамотности и в большей степени способствовало бы информатизации образования, как такового. Глядишь, доживем до счастливого момента, когда ученики будут отправлять рефераты учителю по e-mail :-).
IMHO, на теоретические аспекты по информатике следует отдавать не более 20% времени. Более ценным для школьников было научить их печатать вслепую (страшно смотреть, когда молоденькая операционистка в банке, тычет одним пальцем, набирая мою платежку ..., а ведь изучала в школе информатику!). И научить использовать текстовые редакторы и электронные таблицы для решения прикладных задач (да хоть на примере учета расхода собственных карманных денег). Это бы позволило решить вопрос элементарной компьютерной грамотности и в большей степени способствовало бы информатизации образования, как такового. Глядишь, доживем до счастливого момента, когда ученики будут отправлять рефераты учителю по e-mail :-).
четверг, 15 июля 2010 г.
Летний аналитический фестиваль 2010 в Иваново
Лето выдалось нынче жаркое ... и насыщенное событиями. В прошлые выходные 10-11 июля состоялся в г. Иваново Летний Аналитический Фестиваль, на который я имел честь быть приглашенным в качестве одного из докладчиков. Хотелось бы сказать много теплых слов принимающей стороне, обеспечивших проведение фестиваля - НПО Консультант, и лично Эдуарду Галиаскарову, приютившего нас в своей квартире! Эд, спасибо!. Я добирался машиной в Иваново, и я слегка подустал, поэтому приехал только к 11 на конференцию,. хотя Эду пришлось в 4 утра вставать встречать коллег приехавших поездом из Москвы .... При этом я доделывал презентацию своего доклада еще в течении часа или двух, и не смог посетить первые доклады. Но потом все-таки выбрался ... Послушал Григория Печенкина, Илью Корнипаева ... ребята как всегда на высоте! Отдельно хотел отметить доклад Александра Белина, рассказавшего про опыт постановки процессов "по Вигерсу" в западной компании - какая была проделана колоссальная работа по выстраиванию процесса, и как я понимаю она принесла свои положительные результаты! Кроме этого посетил доклад Ирины Левенец из НПО Консультант ... заслушался :-). Порадовала уверенность и четкость изложения, да и опыт работы компании достаточно интересен.
Мой доклад был посвящен практическим аспектам работы с требованиями, на примерах преимущественно последних нескольких лет работы в HP. И хотя моя текущая работа связана больше с разработкой архитектуры решений, составной частью которой являются собственно требования к ним, тем не менее этот вопрос по-прежнему актуален для меня. В докладе я рассказал о том, чем именно мне приходится заниматься и где в этом процессе происходит активная работа с требованиями, с какими проблемами приходиться сталкиваться, какие методы решения проблем используются и в каких ситуациях, какие техники используются при работе с требованиями. Продемонстрировал несколько шаблонов документов, реально используемых на практике. Получился в какой-то степени PR компании HP :-). На моем докладе было достаточно много слушателей, но вопросов не задавали ... как говорится одно из двух.
Ниже моя презентация:
Мой доклад был посвящен практическим аспектам работы с требованиями, на примерах преимущественно последних нескольких лет работы в HP. И хотя моя текущая работа связана больше с разработкой архитектуры решений, составной частью которой являются собственно требования к ним, тем не менее этот вопрос по-прежнему актуален для меня. В докладе я рассказал о том, чем именно мне приходится заниматься и где в этом процессе происходит активная работа с требованиями, с какими проблемами приходиться сталкиваться, какие методы решения проблем используются и в каких ситуациях, какие техники используются при работе с требованиями. Продемонстрировал несколько шаблонов документов, реально используемых на практике. Получился в какой-то степени PR компании HP :-). На моем докладе было достаточно много слушателей, но вопросов не задавали ... как говорится одно из двух.
Ниже моя презентация:
воскресенье, 27 июня 2010 г.
Мелькнул на телеканале Россия 1 (региональные вести)
Буквально на днях побывал в славном и древнем городе Новгород Великий, где HP активно развивает тему социальной карты или как теперь это называется - универсальной электронной карты гражданина. На текущий момент я, как solution architect, вовлечен в данные активности. Совсем недавно мы с моим коллегой Романом Полозовым завершили пилотный проект по тематике кампусной карты в СПбГУ (кстати, репортаж о событии тут http://www.tv100.ru/news/Universalnaja-karta-studenta-26688/, но на этом торжественном мероприятии мы не присутствовали), и вот теперь на очереди Великий Новгород. 25 июня 2010 г. я с коллегами был приглашен провести презентацию концепции решения для реализации госуслуги по субсидиям за ЖКХ на социальной карте. Презентацию проводили для вице-губернатора Новгородской области - А. Смирнова. Честно говоря мы узнали, что будет снимать телевидение только непосредственно на презентации. Андрею Карташову, пришлось на ходу давать интервью журналистам :-).
Собственно о событии можно почитать тут http://novgorod.rfn.ru/region/rnews.html?id=32357&rid=321, а если нажать на ссылку "видео", то можно увидеть меня с коллегами, и Владимира Зверева - представителя одного из производителей пластиковых карт, с которым мы пересекались и по проекту в СПбГУ. А ниже - несколько снимков из Новгорода ...
Собственно о событии можно почитать тут http://novgorod.rfn.ru/region/rnews.html?id=32357&rid=321, а если нажать на ссылку "видео", то можно увидеть меня с коллегами, и Владимира Зверева - представителя одного из производителей пластиковых карт, с которым мы пересекались и по проекту в СПбГУ. А ниже - несколько снимков из Новгорода ...
суббота, 20 марта 2010 г.
Выступление на встрече Клуба архитекторов в Microsoft
В четверг, 18 марта состоялась встреча Клуба архитекторов в Москве, в офисе Microsoft, посвященная тематике UML. Я был приглашен на это встречу сделать небольшой доклад на тему "Unified Modeling Language - стандарт и практика использования". Мероприятие было анонсировано в блоге Сергея Орлика. Встреча прошла в формате презентаций и обсуждений материалов. Порадовало, что присутствовало много практиков, использующих в своей работе UML и можно было осудить с коллегами некоторые практически вопросы применения языка. Я со своей стороны, рассказал про свой опыт, про некоторые подходы к использованию UML, которые были удачными в конкретных ситуациях. Презентация моего доклада доступна и презентация Серегя Орлика доступны тут. В целом, хотел отметить, что инициатива проведения встреч именно с архитекторами, и особенно теми кто занимается Enterprise решениями мне показалась своевременной, т.к. потребность в общении и обсуждении тех или иных аспектов работы и технологий (как формально так и неформально) ощущается.
пятница, 19 марта 2010 г.
Силиконовая/кремниевая долина ... в Сколково
Вот так новость ... :-). Вот так место :-). Характерно, что называется именно "силиконовой". Видимо внешний эффект будет обеспечен :-).
суббота, 23 января 2010 г.
Из дискуссии в LinkedIn - Ivy Hooks думает о написании новой книги по RDM
В группе на LinkedIn посвященной Requirements Engineering в разделе обсуждений Ivy Hooks, автор книги "Customer Centered Products: Creating Successful Products Through Smart Requirements Management" опубликовала сообщение, в котором говорит, что ей поступило предложение заняться написанием книги по инженерии требований, и в связи с чем она интересуется у сообщества какие вопросы актуальны и достойны для освещения в книге (особенно учитывая тот факт, как отмечает Ivy Hooks, что уже есть более 60 книг по этой тематике, и в частности, известные книги Карла Вигерса, Иена Александра, Рольфа Янга). Наряду с другими участниками группы, я тоже высказал свою точку зрения по этой теме (нужно отметить активность российской части аудитории - помимо меня свои комментарии дали Илья Корнипаев и Андрей Вербицкий). Наиболее интересными темами с моей точки зрения, которым не достаточно уделено внимания в известных мне книгах являются:
1. Специфика разработки и управления требованиями при разработки коммерческих "коробочных" программных продуктов.
2. RDM в разработке систем (система - в терминах INCOSE SEBOK)
3. "Техники и приемы извлечения требований, шаг-за-шагом" (с) мой на это название :-)
4. RDM и BABOK/CMMI/SWEBOK.
5. Специфика внедрения RDM в проектах по разработке ПО, которые уже движутся, и уже существует несколько релизов ПО, которые стоят у заказчиков (включая коробочное ПО)
6. Психологические аспекты в RDM (какие skills должен иметь аналитик с т.з. личностных коммуникаций и как их получать).
Было бы интересно узнать мнение читателей по этой теме. Думаю что дискуссию по этому имеет смысл продолжить в форуме на UML2.RU, как минимум там это делать удобнее :-). Я опубликовал там соответствующее сообщение http://www.uml2.ru/forum/index.php?topic=2028.0.
1. Специфика разработки и управления требованиями при разработки коммерческих "коробочных" программных продуктов.
2. RDM в разработке систем (система - в терминах INCOSE SEBOK)
3. "Техники и приемы извлечения требований, шаг-за-шагом" (с) мой на это название :-)
4. RDM и BABOK/CMMI/SWEBOK.
5. Специфика внедрения RDM в проектах по разработке ПО, которые уже движутся, и уже существует несколько релизов ПО, которые стоят у заказчиков (включая коробочное ПО)
6. Психологические аспекты в RDM (какие skills должен иметь аналитик с т.з. личностных коммуникаций и как их получать).
Было бы интересно узнать мнение читателей по этой теме. Думаю что дискуссию по этому имеет смысл продолжить в форуме на UML2.RU, как минимум там это делать удобнее :-). Я опубликовал там соответствующее сообщение http://www.uml2.ru/forum/index.php?topic=2028.0.
четверг, 21 января 2010 г.
Новый русский сайт по SWEBOK (основы программной инженерии)
С радостью хотел бы поделиться новостью, что благдоаря усилиям и энергии Сергея Орлика запущен новый сайт посвященный основам программной инженерии, базирующийся на переводе (с комментариями и дополнениями) на русский язык IEEE Guide to SWEBOK 2004 - Руководства к своду знаний по программной инженерии. Я имел честь принимать участие как в работах по собственно переводу SWEBOK на русский язык, так и в подготовке материалов для запуска этого сайта. Сразу хотелось бы отметить, что это не вторая редакция перевода, но тем не менее, некоторые изменения были внесены в части комментариев и толкования отдельных положений SWEBOK. Спасибо всем, кто внимательно изучал ранее выложенные в блоге Сергея PDF-ы перевода, присылал свои вопросы и пожелания!
Новый сайт расположен по этой ссылке:
воскресенье, 22 ноября 2009 г.
Выступление на конференции ReqLabs-2009.
К сожалению, я не успел посетить все доклады, которые хотел - очень хотел послушать интересные доклады Ильи Корнипаева, Дениса Бескова и Стаса Калканова. Зато удалось послушать доклад про BPMN, часть доклада Сергея Нужненко, Григория Печёнкина и доклад Александра Новичкова. Александр затронул очень интересную тему - психологические аспекты отношений с заказчиком. Тема достаточно актуальна и традиционно слабо представлена в инженерии требований. Будет очень интересно, если эти вопросы получат дальнейшее развитие, и Александр сможет провести мастер-классы по этой тематике. Кстати, Александр выложил материалы своего доклада тут http://anovichkov.msk.ru/?p=278.
Григорий Печёнкин рассказывал про персональные риски аналитика. Мне доклад показался достаточно интересным, а тема, достойна дальнейшей проработки и расширения.
Что касается моего доклада ... я начал работу по анализу методов, техник и приемов, используемых в инженерии требований. Предстоит провести работу по созданию "базы знаний" по таким методам, анализу их применимости в различных "процессных областях" инженерии требований - какие из них используются преимущественно при извлечении требований, какие при анализе, документировании и утверждении, а какие относятся к управлению и собственно постановке процессов разработки и управления требованиями.
Кроме этого прорабатываются вопросы - какие из техник и приемов дополняют друг друга, а какие являются альтернативами. В каких случаях какие методы имеет смысл применять. Потенциально, база знаний будет содержать описания этих методов и методические материалы по их использованию. Собственно доклад был посвящен этим вопросам и включал краткое описание некоторых из методов. Ниже приведена моя презентация доклада.
понедельник, 14 сентября 2009 г.
Так вот ты какой системный аналитик или объявления о вакансиях ...
На сайте UML2.RU опубликованы вакансии на позицию системного аналитика ... приведу дословно объявления:
В ГК "ЛАНИТ" (http://job.lanit.ru), крупном системном интеграторе, открыта новая вакансия!
Системный аналитик/Помощник руководителя проектов
Требования:
Обязанности:
Условия:
Системный аналитик/Помощник руководителя проектов
Требования:
- В/о (техн.), англ (техн.).
- Опыт работы системным аналитиком от 3 лет.
- Опыт разработки на SQL; знание Visio, Enterprise Architect, XML SPy, ErWin, ARIS, SharePoint;
- Знание технологии .NET;
- Знание архитектуры корпоративных приложений (двухзвенная, многозвенная, SOA и т.п.); знание UML, RUP, MSF, IDEF, Aris.
- Опыт подготовки проектной и технической документации.
- Опыт работы с заказчиками, проведения обследований, выявления требований.
- Стрессоустойчивость, целеустремленность, самостоятельность, ответственность.
Обязанности:
- Самостоятельное написание качественных документов: методических материалов по ведению общекорпоративных справочников и таких документов как концепция единой системы НСИ и интеграции с бизнес-системами предприятия, техническое задание и технический проект создания системы централизованного ведения справочников, программа и методика испытаний и т.п.
- Развитие бизнеса по продаже системы Норма и услуг обучения.
- Консультативная помощь клиентам при работе с системой Норма.
- Подготовка заявок на конкурсы в госсекторе и в коммерческих структурах.
Условия:
- Стабильная заработная плата + премии.
- Соц.пакет (медицинская страховка, своя столовая, дотируемое питание, корпоративные скидки на посещение фитнес-центра).
- Компания проводит обучение и сертификацию сотрудников.
- Перспективы профессионального и карьерного роста.
- М. Авиамоторная/Семеновская (корпоративный транспорт).
В ГК "ЛАНИТ" (http://job.lanit.ru), крупном системном интеграторе, открыта новая вакансия!
Системный Аналитик
Требования:
Обязанности:
Технический пресейл:
Условия:
Системный Аналитик
Требования:
- Высшее образование (желательно технич.); английский технич.;
- Опыт работы аналитиком; опыт разработки, руководство командой разработчиков;
- Желателен опыт выполнения проектов в области IT-консалтинга; знание рынка ПО и основных принципов построения; основных принципов и технологий построения оборудования (hardware, сетевое оборудование);
- Углубленные знания разработки: клиент-серверных приложений;интернет-приложений;
- OLAP-приложений;углубленные знания технологии J2EE, СУБД Oracle, MS SQL;
- Знание Средств моделирования, CASE-средств;
- Умение разрабатывать документацию в соответствии с требованиями ГОСТ.
Обязанности:
- Проведение предконтрактной фазы проекта в части формирования технических требований;
- Разработка архитектуры решений по крупным комплексным проектам;
- Формирование спецификаций на разработку и постановка задачи разработчикам;
- Координация проектных решений между соисполнителями;
- Аудит всей проектной документации (выпускающий редактор);
- Участие в обследований предприятий и организаций;
- Разработка аналитических отчетов и проектных документов;
Технический пресейл:
- Разработка технических предложений на основании сформулированных бизнес-задач;
- Выбор оптимальных технических решений и средств реализации;
- Подготовка конкурсных предложений;
- Разработка технической части конкурсных предложений;
- Координация работы соисполнителей по разработке технической части конкурсных предложений;
- Конкурентный анализ.
Условия:
- М.Авиамоторная/Семеновская(корпоративный транспорт);
- Временный проект (6-7 месяцев), оформление по договору подряда.
- Стабильная зарплата (обсуждается с успешными кандидатами).
Просто поражает воображение - чем только не должен заниматься системный аналитик! С одной стороны требуют знание RUP, и не требуеют знания ГОСТ ... хотя вовсю оперируют терминами ГОСТ про документы "техзадание", "техпроект" (что, как мы знаем из ГОСТ 34.601 вовсе не документ а стадия, ну недосуг им об этом подумать, ладно ...). Требуя знание RUPа, пишут ахинею про то что должен делать системный аналитик ... хоть бы сами в RUP заглянули ...
И вот скажите мне кто-нибудь, что такое ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ или "постановка задач разработчикам"???? Даже представить себе не мог, что системный аналитик должен заниматься проектированием архитектуры систем и выполнять работу за менеджера проекта - координируя работу исполнителей!!!!
Гарантировано можно сказать, что работать в такой позиции я бы не хотел ... могу себе представить что твориться в этих проектах! Вот и думай - то ли в конторе такой бардак, что даже не могут описать внятно что должна делать эта роль ... то ли HR чего напутал ...
пятница, 23 января 2009 г.
Вышло второе издание книги, где я в соавторах
Еще одна приятная новость - вышло второе издание книги -- с изменениями и дополненниями, о которой я уже писал в этом блоге ""Швиденко А.З., Щепащенко Д.Г., Нильссон С.,Булуй Ю.И. Таблицы и модели хода роста и продуктивности насаждений основных лесообразующих пород Северной Евразии (нормативно-справочные материалы)". Кроме этого приятно узнать, что книга рекомендована как стандарт для лесного хозяйства России, о чем написано в новостях на сайте IISAS (www.iiasa.ac.at).
Подписаться на:
Сообщения (Atom)