Изменения

м
Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}
{{RightNote|[[:Категория:Архитектура|Еще про архитектуру]]}}Анатолий Левенчук в конце марта начал выкладывать материалы своего курса "системноинженерного «системноинженерного мышления в управлении жизненным циклом" циклом» http://ailev.livejournal.com/1112525.html а я сейчас прочитал все 7 частей, выложенные на настоящий момент. Это краткое, и при этом очень структурное и доступное изложение подхода системной инженерии, вернее, конструкций мышления, лежащих в основе этого метода. Особенно замечательно то, что изложение ведется не как самостоятельная теория, наоборот, весь материал позиционирован относительно других дисциплин, подходов, практик, методов и стандартов, приведен дано много ссылок на книги и другие источники. Приведен спектр применяемых терминов для различных понятий. А , а сами понятия хорошо позиционированы между собой.
И хотя разработка софта - софта — это не совсем то же, что разработка сложных инженерных систем, этот материал, я бы рекомендовал прочесть это всем, занимающимся проектированием и разработкой софта, включая менеджеров. Тем более, что изложено все это во многом на основе конструкций Essence of software engineering, предложенном SEMAT и сейчас утверждаемым как стандарт OMG. Тем более, что объем действительно небольшой для такого содержания, 200 с небольшим страниц 12 шрифтом. А главное - главное — Анатолий постарался сделать изложение доступным, и у него это хорошо получилось.
: ''Техническое замечание для техА еще все это можно применить к развитию собственной компании, кто будет читатьрассматривая ее как целевую человеко-компьютерную систему, задачей которой является производство продукта или оказание услуг - или к частям этой компании. Наверное, она не сложнее атомной станции, тоже рассматриваемой со всем обслуживающим персоналом. Хотя файлы выложены с расширением docx, внутри конечно, железная часть у нее сильно меньше и это накладывает свои отпечатки - rtfможно мыслить проще. Это не очень важно в офисе Но тут как с использованием моделей для проектирования: Фаулер писал, что если Вы занимаетесь простыми проектами, то Вам это (кроме размера файлаdomain model)не нужно, ибо сложно, но читалки на мобильных устройствах с ними работают плохосам он использует их и в простых проектах тоже, ибо когда освоил, преодолел порог входа - то и простые проекты выполняются быстрее, проще и эффективнее. Так И если Вы освоили правильное мышление, производя и внедряя сложный софт, то почему бы не применить это мышление к развитию компании. А то, что сначала конвертируйте на компе в другой форматоснове лежат методы программной инженерии - позволит легко это сделать. Кстати, Левенчук пишет, что методы программной инженерии приходят в системную с отставанием примерно в 10 лет и сейчас там как раз осваивают Agile.''
: ''Техническое замечание для тех, кто будет читать. Хотя файлы выложены с расширением docx, внутри — rtf. Это не очень важно в офисе (кроме размера файла), но читалки на мобильных устройствах с ними работают плохо. Так что сначала конвертируйте на компе в другой формат.''
 
[[Файл:Ailev-arch-desc.png|right|400px]]
Ввиду большой плотности текста пересказывать содержание совершенно бесполезно. Я отмечу лишь отдельные утверждения, на которые обратил внимание.
# Левенчук позиционирует 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 я у Левенчука читал и ранее, но такое равноправное позиционирование не осознавал. А софтверные проекты во многом, все-таки именно такие.# А еще в «7. Практика контрольных вопросов» - типовые состояния альф. И не только тех, которые непосредственно нацелены на создания целевой системы - определение и воплощение системы, работа, команда, но и стоящих вокруг и часто рассматриваемых без состояний - стейкхолдеры, технологии, возможности. Это состояния не их жизненного цикла (стейкхолдер рождается, живет и умирает, а технология придумывается, создается и устаревает), а относительно целевой системы: стейкхолдеров мы определяем, вовлекаем, сотрудничаем и удовлетворяем, а технологии - выбираем и используем. Ну а возможности - это про то, зачем целевая система нужна, какое функциональное(?) место она займет на рынке, и у них тоже есть состояния и время жизни - за которое надо успеть создать систему.  На этом у меня все. '''Читайте!Оно того стоит!''' <noinclude>[[Категория:Архитектура]]</noinclude> 
{{wl-publish: 2014-05-27 01:03:23 +0400 | MaksTsepkov }}