Изменения

Анатолий Левенчук в конце марта начал выкладывать материалы своего курса "системноинженерного «системноинженерного мышления в управлении жизненным циклом" циклом» http://ailev.livejournal.com/1112525.html а я сейчас прочитал все 7 частей, выложенные на настоящий момент. Это краткое, и при этом очень структурное и доступное изложение подхода системной инженерии, вернее, конструкций мышления, лежащих в основе этого метода. Особенно замечательно то, что изложение ведется не как самостоятельная теория, наоборот, весь материал позиционирован относительно других дисциплин, подходов, практик, методов и стандартов, приведен спектр применяемых терминов для различных понятий. А сами понятия хорошо позиционированы между собой.

И хотя разработка софта - софта — это не совсем то же, что разработка сложных инженерных систем, этот материал, я бы рекомендовал прочесть это всем, занимающимся проектированием и разработкой софта, включая менеджеров. Тем более, что изложено все это во многом на основе конструкций Essence of software engineering, предложенном SEMAT и сейчас утверждаемым как стандарт OMG. Тем более, что объем действительно небольшой для такого содержания, 200 с небольшим страниц 12 шрифтом. А главное - главное — Анатолий постарался сделать изложение доступным, и у него это хорошо получилось.

: ''Техническое замечание для тех, кто будет читать. Хотя файлы выложены с расширением docx, внутри - внутри — rtf. Это не очень важно в офисе (кроме размера файла), но читалки на мобильных устройствах с ними работают плохо. Так что сначала конвертируйте на компе в другой формат.''

# Левенчук позиционирует SEMAT как принципиально новый стандарт второго поколения, ориентированный прежде всего на удобство пользователей описаний (инженеров), а не на методологов - методологов — в отличие от всех предыдущих стандартов.# С точки зрения системной инженерии Левенчук относит программный код (в софтверных проектах) к альфе "определение системы" «определение системы» (то есть requirements), а не к воплощению системы (software system): "полезно «полезно помнить, что исходный код -- код — это рабочий продукт определения системы" системы» ("2«2. Основные альфы инженерного проекта"проекта», описание альфы "воплощение системы"«воплощение системы»). Правда, это точка зрения именно системной инженерии, с точки зрения программной инженерии (software engineering) код (создание кода) относится к воплощению, и OMG Essence исходит из этого. Отмечу, что такая точка зрения не является оригинальным мнением Левенчука, ее высказал в 1992 [http://www.developerdotstar.com/mag/articles/reeves_design.html Jack W.Reeves "What «What is software design"design»] ([http://lib.custis.ru/Блог:Роман_Корешков/Продукт_инженерной_деятельности_(в_разработке_ПО) русский перевод]).# В "5«5. Определение системы: требования, архитектура, неархитектурная часть проекта" проекта» дважды приведена диаграмма архитектурного описания из ISO 42010. Первый раз ближе к началу и в терминах Essence, но в несколько сокращенном виде, а ближе к концу - концу — в исходном виде. На первой диаграмме интересно посмотреть, что превратилось в альфы, а что - что — в артефакты (рабочие продукты).# В том же документе есть довольно качественный разбор про требования и архитектуру. Включая альтернативное определение от [http://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scientist) Ralf Johnson]: "Архитектура -- «Архитектура — это обо всём важном. Что бы это ни было"было».А на верхнем уровне требования - требования — это описания черного ящика, а архитектура - архитектура — описания прозрачного ящика. Но дальше идет много подробностей. # А в "6«6. Виды жизненного цикла" цикла» не менее качественные разборки с жизненным циклом и управлением им в разных аспектах. Включая прохождение гейтов и практику контрольных вопросов, фиксирующим это. При этом самим вопросам для альф инженерного проекта посвящен отдельный документ "7«7. Практика контрольных вопросов"вопросов».# Там же, в "7«7. Практика контрольных вопросов" вопросов» разобрано, что работа может строится не только на основе управления процессами или управления проектами, но и на основе case management - management — управления делами. Про case management я у Левенчука читал и ранее, но такое равноправное позиционирование не осознавал. А софтверные проекты во многом, все-таки именно такие.На этом у меня все. '''Читайте!Оно того стоит!''' [[Категория:Архитектура]]