ailev.ru

Обсуждение

В архиве: 21 комментарий.

Читать и комментировать в ЖЖ ↗

Имя не сохранено · 23 октября 2009

Комментарий

Как это будет реализовано? Как можно присоединится к курсу?

Анатолий Левенчук · 23 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 23 октября 2009

Комментарий

Аммм. От елки палки. Меня с моей оранжевой пропиской ни инвестором не пустят в атомную ни на работу не возьмут :-) Хорошо! Будем надеятся на публикацию в некотором светлом будущем.

Ответ на комментарий

Анатолий Левенчук · 23 октября 2009

Re: Ок, тогда что можно почитать на английском

Читайте современные версии CMMI (уже не CMM), они там последние десять лет интенсивно развивались ;) Тут нужно учесть, что я сознательно концентрируюсь на системной инженерии (т.е. с включение практик работы с "железом", а не только софтом), а не программной инженерии. Так что с CMMI и другими типовыми наборами практик есть существенные пересечения и не менее существенные различия. А вообще, странно получить запрос на "что почитать" в комментах к постингу, который содержит список литературы. Вся эта литература есть, конечно, не только по-русски, но и в английских оригиналах. Нет проблем с английским чтивом. Члены INCOSE получают эту литературу для обсуждения и критики, fair use ;)

Ответ на комментарий

Анатолий Левенчук · 23 октября 2009

Комментарий

Но литературу-то и сейчас можно изучать. Члены Русского отделения INCOSE ее получают, а для членства прописку не спрашивают.

Ответ на комментарий

Имя не сохранено · 23 октября 2009

Комментарий

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

Анатолий Левенчук · 23 октября 2009

Комментарий

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

Ответ на комментарий

Анатолий Левенчук · 23 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 24 октября 2009

Комментарий

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

Анатолий Левенчук · 24 октября 2009

Комментарий

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

Анатолий Левенчук · 24 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 24 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 24 октября 2009

Комментарий

Я о другом. Чтоб, что-то понять, надо разобрать, как работают несколько альтернатив. А так, большой проект - большой риск. То, что не удалось отладить на десятке тысяч, не будет работать и на миллионе. И чем больше затраты, тем больше увязаешь в колее. Летом один мужик рассказывал, что кой-какие концерны решили "медленно спуститься с горы" В результате крутое логистическое решение стоит, детали на складах лежат, что с этим делать, никто не знает.

Ответ на комментарий

Анатолий Левенчук · 24 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 24 октября 2009

Комментарий

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

Ответ на комментарий

Имя не сохранено · 24 октября 2009

Комментарий

А какая-то открытая информация есть об этой инициативе? Кириенко говорит о каком-то 6d проектировании... Это не вы? :)

Ответ на комментарий