Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - Denis Beskov

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
151
Компания Sybase привозит основателя концепции корпоративного хранилища данных - Ральфа Кимбалла (Ralph Kimball).

Ральф Кимбалл - это:
    * всемирно известный эксперт, основоположник концепции корпоративных хранилищ данных;
    * консультант, обладающий огромным, более чем 30-летним практическим опытом работы в данной области;
    * в прошлом возглавлял направление разработки приложений в компании Metaphor Computer Systems, основатель и исполнительный директор Red Brick Systems, основатель Ralph Kimball Associates, Inc. и Kimball Group;
    * автор множества публикаций и книг-бестселлеров по теме многомерного моделирования хранилищ данных, среди которых "The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition)"

На конференции будут рассматриваться следующие вопросы:
    * Как должно быть организовано корпоративное хранилище данных, чтобы решать задачи пользователей?
    * Преимущества использования подхода многомерного моделирования корпоративных хранилищ данных.
    * Существующие «лучшие практики» в области архитектуры корпоративного ХД. Ограничения стандартной архитектуры и причины их возникновения.
    * Есть ли путь лучший, чем «лучшие практики»?
    * 13 факторов успеха проекта построения корпоративного хранилища данных.
    * Почему традиционная оценка совокупной стоимости владения TCO не подходит при создании хранилища данных?
    * Что делать с качеством данных?

http://www.sybase.ru/Syb/corporate/events/ralph_kimball_2007.html

153
Инструмент управления проектами (web-based), очень неплохой: http://www.basecamphq.com/
Интересно, насколько ему уступает http://projects.zoho.com и open-source'ный http://www.activecollab.com/.

154
Свершилось-таки - господа из IBM прикрутили wiki к процессным сайтам, которые создаются из среды разработки процессов Eclipse Process Framework!

Теперь появилась возможность достаточно удобного перевода открытого процесса OpenUP/Basic, созданного Филиппом Крухтеном из RUP с целью минимизации формализма и привнесения принципов Agile.

Вот русскоязычный сайт процесса: http://www.epfwiki.net/wikis/openupru/

А это картина того, как организовано развитие и перевод содержимого процесса: http://www.epfwiki.net/images/epfwiki_infra_overview.jpg

Предлагаю присоединяться желающим!

155
10 апреля, в 7 часов вечера

В рамках подготовки к конференции "Российские интернет-технологии" пройдёт семинар "Оптимизация производительности БД".

Аудиторией семинара являются разработчики ИС и ПО со средним опытом, начинающие архитекторы, проектировщики систем и администраторы баз данных, IT-менеджеры.

На семинаре будут рассмотрены:
* факторы, влияющие на производительность системы
* принципы оптимизации
* бизнес-ориентированная методика оптимизации по Голдрату
* техники оптимизации на каждом из слоёв системы с акцентом на БД
* некоторые примеры
* инструменты профилирования и мониторинга.

Чтобы попасть на семинар, пришлите свои ФИО на dbperf_workshop (o) beskov.ru

Адрес проведения семинара: метро Октябрьское Поле, 1-й волоколамский проезд, д.10 строение 3, офис компании "Люксофт"

Путь от метро: первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамский проезд". Автобус останавливается напротив первой проходной.

Либо пешком от метро, идти минут 10

156
29 марта, в 7 часов вечера
UML2.ru при поддержке компании Luxoft проводит семинар на тему

"Разработка требований и состава работ - Холистический подход"

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

Традиционные и достаточно современные подходы к определению требований к системе и состава работ, изложенные в BABOK, PMBOK, SWEBOK и специализированной литературе (Вигерс, Коберн, Лефингвел), несмотря не свои очевидные достижения, не предлагают метода формирования целостного и взаимоувязанного представления о создаваемой системе, и следовательно, требований к её внешним и внутренним свойствам, а также работ, необходимых для её создания, и, что исключительно важно, эффективной эксплуатации.

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

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

Чтобы попасть на семинар, пришлите свои ФИО на rq_workshop (o) beskov.ru

Адрес проведения семинара: метро Октябрьское Поле, 1-й волоколамский проезд, д.10 строение 3

Путь от метро: первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамские проезд". Автобус останавливается напротив первой проходной.

Либо пешком от метро, идти минут 10.

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

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

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

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

158
3-4 апреля в Москве состоится конференция Software Development Best Practices Expo - http://www.sdexpo.ru/

На ней будут Брюс Экель, Бертран Мейер, Скотт Амблер, Алистер Коберн.

159
Часто встречаю ТЗ как некий структурированный список требований.

Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?

Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!

Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. - Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.

"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?

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

Отдельно стоит рассказать про проблемы ГОСТ 34.602 и главное - как их преодолевать. Но об этом позже.

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

NB: в дополнение - мой полугодичной давности пост "Типовые ошибки ТЗ".

160
В пятницу, 16-го марта пройдёт очередной семинар AgileRussia. Тема встречи - разбор case'а - "Применимость agile-методик в in-house-разработке".

Ситуация:
* много разных проектов
* много разных технологий
* небольшой коллектив разработчиков

Я буду представлять интересы такого коллектива, эксперты по Agile - предлагать методики и обсуждать их применимость.

Подробности и записываться здесь - http://agilerussia.ru/index.php?option=com_content&task=view&id=32&Itemid=27

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

Немногие знают, что в рамках движения к открытости и прозрачности Электронного Государства, в 2005-2006 годах Министерство Экономического Развития и Торговли РФ создало на своём сайте раздел и выложило в нём проектную документацию по множеству проектов разработки информационных систем, создаваемых по программе "Электронная Россия":

http://aisup.economy.gov.ru/pubportal/

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

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

Если ГОСТ для чего и создавался - то именно для такого рода проектов.

Ряд документов успешно использует UML и ARIS.

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

Таким образом будут решены следующие задачи:
1. Извлечены знания - типовые и просто удачные решения.
2. Получены образцы "эталонных" документов.
3. Получен материал для обсуждения.

Я предлагаю начать с ТЗ, как наиболее массовой и проблематичной темы.

163
30 Марта IBM проводит традиционный форум "Инновации в области программного обеспечения" (там нужно кликнуть по 2-му дню).

Я скорее всего буду как-то распределяться между 1-й и 5-й секциями: SOA и PLM + возможно ещё загляну на MDM и социосети.

164
Я сегодня переводил оглавление BABOK'а для нашего файлохранилища, и с удивлением обнаружил, что он посвящён в основном работе с требованиями. Вот это оглавление:

Цитировать
   1. Анализ предприятия
         1. Создание и управление бизнес-архитектурой
         2. Проведение исследований реализуемости
         3. Определение рамок проекта
         4. Подготовка экономического обоснования
         5. Проведение первоначального выявления рисков
         6. Подготовка пакета решений
         7. Выбор, запуск, управление и контроль хода проектов
   2. Планирование и управление требованиями
         1. Командные роли
         2. Стратегия разделения работы группы бизнес-аналитиков
         3. Определение подхода к управлению рисками требований
         4. Выбор видов деятельности по требованиям
         5. Управление масштабом требований
         6. Управление изменениями требований
   3. Выявление требований. Техники
         1. Мозговой штурм
         2. Анализ документации
         3. Фокус-группы
         4. Анализ интерфейсов
         5. Интервью
         6. Наблюдение
         7. Прототипирование
         8. Семинар
         9. Инженерный анализ
        10. Опросы, анкетирование
   4. Анализ и документирование требований
         1. Структурирование пакетов требований
         2. Создание модели предметной области
         3. Анализ пользовательских требований
         4. Анализ функциональных требований
         5. Анализ качества требований к уровню обслуживания
         6. Определение предположений и ограничений
         7. Определение атрибутов требований
         8. Документирование требований
         9. Валидация требований
        10. Проверка требований
        11. Модели данных и поведения
        12. Модели процессов и потоков
        13. Модели использования
   5. Передача требований
         1. Создание плана распространения требований
         2. Разрешение конфликтов требований
         3. Определение подходящего формата требований
         4. Создание пакета требований
         5. Проведение презентации требований
         6. Проведение формального пересмотра требований
         7. Заключение соглашения о требованиях
   6. Проверка решения
         1. Разработка альтернативных решений
         2. Оценка технологических возможностей
         3. Помощь в выборе решения
         4. Обеспечение удобства решения
         5. Поддержка процесса обеспечения качества
         6. Поддержка процесса реализации решения
         7. Передача сведений о влиянии решения
         8. Обзор и проверка реализации решений
   7. Основы бизнес-анализа
         1. Коммуникационные навыки
         2. Лидерские навыки
         3. Навыки решения проблем
         4. Знание бизнеса
         5. Знание IT
   8. Словарь

165
Конференции Семинары и Тренинги / РИТ-2007
« : 15 Февраля 2007, 11:17:18 »
16-17 апреля 2007 года в Москве пройдёт первая конференция "Российские интернет-технологии" РИТ-2007.

Конференция будет состоять из 12 секций:
* “Разработка больших Интернет-сайтов”
* “Использование CMS и фреймворков”
* "Ведение бизнеса в веб-разработке"
* “Клиент”
* “Веб-безопасность”
* “Базы данных”
* “Аспекты разработки”
* “Будущее”
* “Управление техническими проектами”
* “Программирование”
* “Мобильные технологии”
* “Шаблонизаторы”

Организаторы предложили нам поучаствовать в качестве докладчиков и, возможно, кураторов одной из секций (скорее всего, "Аспекты разработки"), либо создать свою секцию. Я с коллегами по отрасли курирую секцию "Базы данных", сейчас готовлю доклады по "Оптимизации БД" и "Планированию проекта", желающие могут присоединиться. Со всеми вопросам можно обращаться ко мне.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »