2041

Сообщество Аналитиков / Re: Система рекомендаций профлитературы: Постановка задачи

« : 30 Апреля 2007, 21:30:21 »

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

См. мои слова ниже: "Полезность книги практически невозможно оценить объективно, хотя и есть книги и авторы, обладающие высоким профессиональным авторитетом" %)

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

Какие-такие "книги Буча"? Я только одну сейчас у него книгу на русском языке вижу - UML. Классика CS

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

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

2042

О Сайте и Форуме / Re: Логотип сайта

« : 29 Апреля 2007, 00:23:34 »

А зачем переделывали логотип вообще?

2043

Обучение / Re: Проблемы преподавания программной инженерии в вузах России

« : 28 Апреля 2007, 11:35:56 »

Я так понял, что буквально на днях Комитетом по образованию в области ИТ Ассоциации Предприятий Компьютерных и Информационных Технологий опубликован русский перевод Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering.

Называется это всё "Рекомендации по преподаванию программной инженерии и информатики в университетах".

http://www.apkit.ru/default.asp?artID=5684

2044

ПО Аналитика / Re: Каким инструментом для рисования BPMN пользоваться?

« : 26 Апреля 2007, 22:28:10 »

Зачем (переносить тему) Вопрос то про CASE - что использовать.

А как обсуждение инструментов моделирования в нотации BPMN вписывается в раздел  "Unified Modeling Language > CASE-средства"?

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

2045

Консалтинг и Внедрение / Дневник внедрения Аксапты

« : 25 Апреля 2007, 10:06:49 »

250 записей, полезно почитать на досуге

http://1c.realnet.ru/kuban/165502.html

2046

UML SysML и пр. / Re: Отличие UML от OMT

« : 25 Апреля 2007, 10:00:29 »

не поможем, более того, таких "колюнь" имхо надо гнать поганой метлой

2047

Консалтинг и Внедрение / Re: Консалтинг на практике

« : 25 Апреля 2007, 09:53:44 »

А как называется консалтинг по формированию ИТ-инфраструктуры?

Да хоть груздём Зачем вам название? Устоявшихся мне неизвестно, узковат и неустоявшийся рынок.

Именно то, что я хотел услышать. Т.е. для консалтинга по внедрению на выходе должен формироваться документ Vision? Где можно было бы посмотреть правила (стандарт) оформления этого документа?

Типы и форматы документов зависят от специфики проекта.

Если заказчик старой советской закалки или ему сильно импонирует слово "ГОСТ" - то делаем по ГОСТу (Отчёт об обследовании, Концепция, ТЭО, ТЗ, Комплект докуменации по ЭП/ТП, Комплект рабочей документации). См. ГОСТ 34 и РД 50-34.698-90

Если заказчику главное - эффективность, то тут вы выбирате и предлагаете сами - хотите, делаете системный проект по Калянову, хотите - Vision, SRS по RUP/Вигерсу/IEEE, если нужно - описываете решения по IEEE/ISO.

Общая рекомендация такая - сначала смотрите ГОСТы по своей теме, если чего-то не хватает - смотрите западные стандарты. Я стандартов по IT-инфраструктуре не смотрел, но скорее всего в вашем случае нужно очень хорошо знать, что такое и опираться в работе на ITIL.

Я о Vision, например. Может где-нибудь можно посмотреть или кто-то готов показать реальные примеры готовых документов (можно с искаженной информацией)?

Я не думаю, что кто-то в здравом уме будет это делать.

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

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

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

Вот пример документа, который мы делали с AlexTheRaven на проекте по выбору системы построения гибких отчётов: http://beskov.ru/isi/ISI-BI-Research-2005-04-11.pdf

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

2048

Проектирование / Ральф Кимбал в МСК 15 мая

« : 24 Апреля 2007, 09:59:10 »

Компания 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

2049

Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"

« : 20 Апреля 2007, 23:48:52 »

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

Ещё раз - серьёзным проектам - серьёзные методы.

Дальше так же непонятно, как следить за временем и ресурсоемкостью задач. Простой вопрос: сколько продлится проект, спланированный с использованием холистического метода (а не в MS Project, например).

Во-первых, я не пытался объять необъятное, я искал то, с помощью чего можно выработать Vision (requirements baseline) и связать его с задачами, определив их.

Что нужно для того, чтобы построить план работ?
1. Определить состав работ.
2. Определить взаимосвязи работ.
3. Определить ограничения длительности работ.
4. Определить трудоёмкости работ.
5. Назначить ресурсы.
6. Перераспределить и соптимизировать сетевой график, выделив критический путь.

Я сконцентрировался на 1. И только. Потому что пока нет состава работ, всё остальное бессмысленно и от качества этого 1 зависит многое.

Во-вторых, например такой продукт, как MindManager позволяет выставлять сроки и длительность узлам как задачам.

Как только мы начнем на него отвечать, как снова вылезет взгляд на проект из ресурсной диаграммы и диаграммы Гантта, и представление проекта снова потеряет целостность. Я не принимаю отговорки, что метод не рассматривает вопросы времени по той причине, что в большинстве реальных проектов одним из основных требований, трассируемых из целей будут ограничения на временные рамки проекта в целом (точнее, привязка стадий ЖЗ продукта к временным интервалам). И в жизни после моделирования временных параметров плана мы часто бываем вынуждены вернуться к требованиям и целям и что-то в них изменить.

В-третьих, MindManager прекрасно импортирует и экспортирует в MS Project, никто не мешает выгрузить MindMap в Project, выполнить там пункты 2-6, и загрузить обратно.

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

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

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

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

И последний вопрос: сколько стоит проект (как карта на него отвечает)?
И еще много других вопросов...

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

Ты можешь дать конкретную ссылку на статью Архангельского с mindmap?

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

2050

Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"

« : 20 Апреля 2007, 23:19:45 »

Boatman, большое спасибо за детальную рецензию! На семинаре я действительно показывал и обсуждал всё вживую, а демонстрацию лишь предложил в качестве дополняющей теорбазы.

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

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

Новизна
- Идея ЖЦ продукта на сегодняшний день является хрестоматийной категорией.
- Дерево целей в различных вариациях на сегодня тоже является одним из хрестоматийных инструментов инженера и менеджера.
- Идея о том, что источником требований будет весь ЖЦ продукта (а не один маленький его компонент) явно или неявно применяется на практике всеми инженерами очень давно. Возможно, в ИТ (в силу молодости) не так давно, но любое (к примеру) машиностроительное изделие проектируется с учетом всего: от изготовления, доставки, монтажа...через эксплуатацию, ремонт и модернизацию ...до утилизации.
- Технология mindmap описана в литературе и применяется давно.
- Идея о том, что требования трассируются из элементов объекта автоматизации (автоматизируемых процессов), а конкретные работы проекта могут разбиваться в соответствие с разбиением на функции/фичи/модули применяется в управлении проектами.

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

У разработчика нет представления о том, насколько ему это УП нужно, если нужно - то откуда начинать и в какой степени погружаться, что изучать и использовать, нет времени и возможности 3 года учиться или платить по 1k за 3-хдневные курсы, к тому же его интерес - получать удовольствие от реализации идеи и делать хороший продукт, а не учиться управлять проектами или уметь управлять различными проектами.

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

Вот ты пишешь, что "источником требований является весь ЖЦ продукта" - неужели тебе действительно это давали как методику выявления требований на твоей кафедре? Нам, насколько я помнию, нет. Да, про ЖЦ конечно рассказывали, но как именно, на основании чего создавать продукт (в нашем случае - САПР) - нет. Поэтому считай что я закрываю этим методом дыру своей собственной безграмотности и заодно предоставляю реалистичный, как я надеюсь, инструмент тем, кто не получил или не получает ВО.

2051

Проектирование / Re: Методички - Моделирование структуры ПрОбл и логическое проектирование БД

« : 20 Апреля 2007, 13:06:47 »

Я предпочитаю, чтобы люди шли от своей реальной задачи, а не от выдуманных примеров.

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

2052

Проектирование / Методички - Моделирование структуры ПрОбл и логическое проектирование БД

« : 20 Апреля 2007, 10:18:44 »

Выкладываю пару своих методичек (PDF, 7-12 страниц):

1. Анализ и моделирование предметной области

2. Проектирование логической модели БД

2053

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 16 Апреля 2007, 22:39:53 »

Во-многих случаях "постановка" выгладит так - "создать эффективную систему такую-то". Как из этого получить задачи?

2054

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 16 Апреля 2007, 22:37:08 »

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

Ну это же и есть описанный мной метод А.

Т.е. идентифицировать задачи, которые нужно выполнить для достижения цели

Т.е. определить состав необходимых работ можно, если ты раньше делал похожие проекты. А если проект новый?

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

Кем включено, когда включено, что включено? Т.е. вы на позицию (роль) менеджера себя никогда не ставили, я правильно понмиаю?

"Разработчику не знать". Сейчас время стартапов. Есть три человека с хорошей идеей и мозгами (допустим, Галоген, Бас и Я). Кому из нас при определении работ по проекту незачем знать про маркетинг? Разработчик, который не работаёт наёмным работником в офисной клетке - это что, не разработчик?

У меня есть друг, который занимается научными проектами - работает в теме ЭРД. Он постоянно мониторит рынок проектов по своей тематике ищет работы на стороне. Одним из критериев подбора проекта является именно составление WBS. Он говорит, что берется за проект только в том случае, когда он приблизительно знает как за это взяться, какие шаги нужно предпринять для его выполнения.

Опять нечто из серии астрологии и "менеджмент - это искусство". Откуда появляется понимание того, что делать? Из астрала, как стихи? Из предыдущего опыта? Если человек делает только то, что делал раньше - то он всё время делает одно и то же?

2055

Системный Анализ и Требования / Re: Анкетирование

« : 16 Апреля 2007, 22:23:40 »

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