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

×


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

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


Сообщения - Denis Beskov

1006
17-го декабря буду в Питере на http://clubs.ya.ru/ya-events/replies.xml?item_no=181
(и 18-го)

1007
Тренинг будет.
Форма оплаты действительно не указана.

1008
Школа Системного Анализа проводит однодневный тренинг
«Практика разработки требований к ПО»,
адресованный всем участникам ИТ-проектов, работающим с требованиями.

Что получат участники

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

Начинающие специалисты смогут получить твердый минимум знаний и навыков для разработки требований:
— научатся отличать основные шаги и техники в процессе разработки требований от дополнительных и взаимозаменяемых;
— смогут отличать плохие требования от хороших и определять более глубокие характеристики качества требований.

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

Узнать подробнее о программе, ценах и записаться можно на странице тренинга.

Чтобы получить дополнительную информацию, можно задать вопросы
на почту obuchenie @ system-analysis.ru или через форму.

1009
Отзыв на грани этики, но очень смешной )

1010
При чём тут конференции — не понял.

1011
Я тут на днях делал подборку рекомендаций книг по требованиям: http://bagcheck.com/bag/1377--

Из более фундаментальных могу назвать Оптнера с его "Системный анализ в решении деловых и промышленных проблем" 1960-го года.

1012
Software Design
Блог посвящён вопросам проектирования ПО. Автор делится своим личным опытом, детально разбирает конкретные примеры проектирования, предлагает и излагает свою методику, которая сформирована на базе 15-летнего опыта коммерческой разработки ПО. Никаких абстрактных, отдалённых от реальности теоретических изысканий. Все рекомендации проверены практикой.
http://askofen.blogspot.com/
А почему автор пишет о себе в 3-м лице? Доабстрагировался на досуге?

1013
Ничего не понял про "красную нить" и что там куда проходит.

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

Если же 2-й документ изменяет ряд требований первого то, возможно, вам будет проще взять RQM-инструмент типа Enterprise Architect, импортировать документ, указать версии для требований и сгенерить документы заново.

Elf должно быть имела в виду SVN, а не VPN.

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

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

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

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

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

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

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

Я вижу следующие соотношения:

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

Также и Интегральный подход (как мировоззрение) может включать в себя интегральный метод и интегральный анализ последовательно.

Откуда инфа 100%, что системный анализ – это вообще наука? Из классификаторов РАН?

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

1016
Категоричность is my second name

Да, интегральщики утверждают, что смотрят шире, чем системщики)
Стоят на плечах гигантов, тскать

1017
Но у системного подхода и интегрального подхода различные объекты исследования!?
Не слишком ли Вы категоричны насчет "полки истории"?
Очень жду вашего ответа с перечнем актуальных проблем системного аанлиза

1018
Например, интегральному подходу

1019
У науки "Системный анализ" сейчас уже нет никаких проблем, она заняла свое место на полке истории и уступила поле боя более современным подходам.

1020
Я не видел и мне ни разу не давали знать, что мой опыт программирования на C и Prolog во время обучения и на PL/SQL во время работы как-то вредил мне как аналитику потом.

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