7158
правок
Изменения
м
Нет описания правки
Анатолий Левенчук в конце марта начал выкладывать материалы своего курса «системноинженерного мышления в управлении жизненным циклом» http://ailev.livejournal.com/1112525.html а я сейчас прочитал все 7 частей, выложенные на настоящий момент. Это краткое, и при этом очень структурное и доступное изложение подхода системной инженерии, вернее, конструкций мышления, лежащих в основе этого метода. Особенно замечательно то, что изложение ведется не как самостоятельная теория, наоборот, весь материал позиционирован относительно других дисциплин, подходов, практик, методов и стандартов, приведен дано много ссылок на книги и другие источники. Приведен спектр применяемых терминов для различных понятий. А , а сами понятия хорошо позиционированы между собой.
И хотя разработка софта — это не совсем то же, что разработка сложных инженерных систем, этот материал, я бы рекомендовал прочесть это всем, занимающимся проектированием и разработкой софта, включая менеджеров. Тем более, что изложено все это во многом на основе конструкций Essence of software engineering, предложенном SEMAT и сейчас утверждаемым как стандарт OMG. Тем более, что объем действительно небольшой для такого содержания, 200 с небольшим страниц 12 шрифтом. А главное — Анатолий постарался сделать изложение доступным, и у него это хорошо получилось.
А еще все это можно применить к развитию собственной компании, рассматривая ее как целевую человеко-компьютерную систему, задачей которой является производство продукта или оказание услуг - или к частям этой компании. Наверное, она не сложнее атомной станции, тоже рассматриваемой со всем обслуживающим персоналом. Хотя, конечно, железная часть у нее сильно меньше и это накладывает свои отпечатки - можно мыслить проще. Но тут как с использованием моделей для проектирования: Фаулер писал, что если Вы занимаетесь простыми проектами, то Вам это (domain model) не нужно, ибо сложно, но сам он использует их и в простых проектах тоже, ибо когда освоил, преодолел порог входа - то и простые проекты выполняются быстрее, проще и эффективнее. И если Вы освоили правильное мышление, производя и внедряя сложный софт, то почему бы не применить это мышление к развитию компании. А то, что в основе лежат методы программной инженерии - позволит легко это сделать. Кстати, Левенчук пишет, что методы программной инженерии приходят в системную с отставанием примерно в 10 лет и сейчас там как раз осваивают Agile.
: ''Техническое замечание для тех, кто будет читать. Хотя файлы выложены с расширением docx, внутри — rtf. Это не очень важно в офисе (кроме размера файла), но читалки на мобильных устройствах с ними работают плохо. Так что сначала конвертируйте на компе в другой формат.''
[[Файл:Ailev-arch-desc.png|right|400px]]
Ввиду большой плотности текста пересказывать содержание совершенно бесполезно. Я отмечу лишь отдельные утверждения, на которые обратил внимание.
# Левенчук позиционирует SEMAT как принципиально новый стандарт второго поколения, ориентированный прежде всего на удобство пользователей описаний (инженеров), а не на методологов — в отличие от всех предыдущих стандартов.
# А в «6. Виды жизненного цикла» не менее качественные разборки с жизненным циклом и управлением им в разных аспектах. Включая прохождение гейтов и практику контрольных вопросов, фиксирующим это. При этом самим вопросам для альф инженерного проекта посвящен отдельный документ «7. Практика контрольных вопросов».
# Там же, в «7. Практика контрольных вопросов» разобрано, что работа может строится не только на основе управления процессами или управления проектами, но и на основе case management — управления делами. Про case management я у Левенчука читал и ранее, но такое равноправное позиционирование не осознавал. А софтверные проекты во многом, все-таки именно такие.
# А еще в «7. Практика контрольных вопросов» - типовые состояния альф. И не только тех, которые непосредственно нацелены на создания целевой системы - определение и воплощение системы, работа, команда, но и стоящих вокруг и часто рассматриваемых без состояний - стейкхолдеры, технологии, возможности. Это состояния не их жизненного цикла (стейкхолдер рождается, живет и умирает, а технология придумывается, создается и устаревает), а относительно целевой системы: стейкхолдеров мы определяем, вовлекаем, сотрудничаем и удовлетворяем, а технологии - выбираем и используем. Ну а возможности - это про то, зачем целевая система нужна, какое функциональное(?) место она займет на рынке, и у них тоже есть состояния и время жизни - за которое надо успеть создать систему.
На этом у меня все. '''Читайте! Оно того стоит!'''
