INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...Alex V. Petrov
Системная инженерия, известная еще с советских времен как «системотехника», в последние десятилетия претерпела серьезные трансформации не только в России, но и за рубежом. Достаточно сказать, что на английском языке эта междисциплинарная область знаний приобрела в своем названии новый смысл: «инжиниринг системы» (англ. System Engineering) сменил «инжиниринг систем» (англ. Systems Engineering). Отечественные вузы, по объективным причинам утратившие за последние 20 лет экспертизу в области преподавания системотехники, сегодня оказались неспособны предлагать рынку выпускников, готовых, умеющих, а главное — знающих, как браться за разработку сложных систем и доводить ее до конца, отвечать за основополагающие принципы создания и функционирования таких систем, иными словами — архитектуру.
Между тем, системная инженерия возвращается в учебные планы программ подготовки магистров по таким направлениям, как «Информатика и вычислительная техника». Впрочем, строчка в учебном плане — еще не гарантия успеха в преподавании.
В своем докладе мы поделимся личным опытом преподавания системной инженерии в ведущих технических вузах столиц России: Московском государственном техническом университете (МГТУ) им. Н.Э. Баумана и Санкт-Петербургском государственном электротехническом университете «ЛЭТИ» им. В.И. Ульянова (Ленина) (СПбГЭТУ ЛЭТИ), — расскажем о контексте, в котором велась подготовка авторских учебных программ, лекционных и практических материалов, проблемах, которые возникали в ходе образовательного процесса.
Говоря о результатах, которых удалось достичь авторам с 2013/2014 уч. года и по сей день, мы остановимся на двух главных. Пер�
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...Alex V. Petrov
Системная инженерия, известная еще с советских времен как «системотехника», в последние десятилетия претерпела серьезные трансформации не только в России, но и за рубежом. Достаточно сказать, что на английском языке эта междисциплинарная область знаний приобрела в своем названии новый смысл: «инжиниринг системы» (англ. System Engineering) сменил «инжиниринг систем» (англ. Systems Engineering). Отечественные вузы, по объективным причинам утратившие за последние 20 лет экспертизу в области преподавания системотехники, сегодня оказались неспособны предлагать рынку выпускников, готовых, умеющих, а главное — знающих, как браться за разработку сложных систем и доводить ее до конца, отвечать за основополагающие принципы создания и функционирования таких систем, иными словами — архитектуру.
Между тем, системная инженерия возвращается в учебные планы программ подготовки магистров по таким направлениям, как «Информатика и вычислительная техника». Впрочем, строчка в учебном плане — еще не гарантия успеха в преподавании.
В своем докладе мы поделимся личным опытом преподавания системной инженерии в ведущих технических вузах столиц России: Московском государственном техническом университете (МГТУ) им. Н.Э. Баумана и Санкт-Петербургском государственном электротехническом университете «ЛЭТИ» им. В.И. Ульянова (Ленина) (СПбГЭТУ ЛЭТИ), — расскажем о контексте, в котором велась подготовка авторских учебных программ, лекционных и практических материалов, проблемах, которые возникали в ходе образовательного процесса.
Говоря о результатах, которых удалось достичь авторам с 2013/2014 уч. года и по сей день, мы остановимся на двух главных. Пер�
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
ПЛАН:
1. Причины неудачных проектов
2. Отсутствие моделей при разработке ПО
3. Лучшие практики разработки ПО
4. Что такое визуальное моделирование?
5. Основные понятия визуального моделирования
6. Классификация проектов по сложности
7. Основные понятия ООП
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
Эффективное объектно-ориентированное проектирование и структурное качество пр...LuxoftTraining
Алексей Петров, консультант Luxoft Training в области анализа и моделирования бизнес-процессов и проектирования баз данных, представил доклад «Эффективное объектно-ориентированное проектирование и структурное качество приложений» на Stratoplan TECH&BUSINESS Summit 2013.
В своем выступлении Алексей ответил на ряд важных вопросов:
- Что такое «структурное качество приложения»?
- Что такое «антишаблоны», и какой вред они могут нанести коду?
- Как соотносятся фундаментальные и канонические шаблоны ОО-проектирования и показатели структурного качества?
- Какую помощь в обеспечении качества приложения могут оказать современные языки ОО-программирования?
- Какие организационные мероприятия могут помочь в обеспечении структурного качества в условиях промышленной разработки?
- Реально ли повысить структурное качество уже написанного приложения?
Тезисы доклада:
«Значимой актуальной тенденцией в инженерии ПО является переход от обеспечения качества приложения путем всестороннего тестирования по завершении основной фазы его кодирования к обеспечению качества на всех этапах жизненного цикла разработки ПО. Кроме того, само понятие качества трактуется все более широко и в соответствии с общепринятыми стандартами (напр., ISO/IEC 9126) охватывает на сегодняшний день такие понятия, как безопасность, надежность, масштабируемость, удобство сопровождения.
Сформулировать соответствующие метрики качества нетрудно, гораздо труднее — добиться заданных показателей. И основную роль в этом играют не программисты, которые «изготавливают» исходный или объектный код, а аналитики и архитекторы, которые проектируют будущие артефакты с учетом оп
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
ПЛАН:
1. Причины неудачных проектов
2. Отсутствие моделей при разработке ПО
3. Лучшие практики разработки ПО
4. Что такое визуальное моделирование?
5. Основные понятия визуального моделирования
6. Классификация проектов по сложности
7. Основные понятия ООП
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
Эффективное объектно-ориентированное проектирование и структурное качество пр...LuxoftTraining
Алексей Петров, консультант Luxoft Training в области анализа и моделирования бизнес-процессов и проектирования баз данных, представил доклад «Эффективное объектно-ориентированное проектирование и структурное качество приложений» на Stratoplan TECH&BUSINESS Summit 2013.
В своем выступлении Алексей ответил на ряд важных вопросов:
- Что такое «структурное качество приложения»?
- Что такое «антишаблоны», и какой вред они могут нанести коду?
- Как соотносятся фундаментальные и канонические шаблоны ОО-проектирования и показатели структурного качества?
- Какую помощь в обеспечении качества приложения могут оказать современные языки ОО-программирования?
- Какие организационные мероприятия могут помочь в обеспечении структурного качества в условиях промышленной разработки?
- Реально ли повысить структурное качество уже написанного приложения?
Тезисы доклада:
«Значимой актуальной тенденцией в инженерии ПО является переход от обеспечения качества приложения путем всестороннего тестирования по завершении основной фазы его кодирования к обеспечению качества на всех этапах жизненного цикла разработки ПО. Кроме того, само понятие качества трактуется все более широко и в соответствии с общепринятыми стандартами (напр., ISO/IEC 9126) охватывает на сегодняшний день такие понятия, как безопасность, надежность, масштабируемость, удобство сопровождения.
Сформулировать соответствующие метрики качества нетрудно, гораздо труднее — добиться заданных показателей. И основную роль в этом играют не программисты, которые «изготавливают» исходный или объектный код, а аналитики и архитекторы, которые проектируют будущие артефакты с учетом оп
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Maxim Avdyunin
Сертификация приложений по требованиям федеральных и отраслевых регуляторов, требованиям компаний (если они есть) — необходимое условие разработки и поставки коробочного решения. Требования потребителей и пользователей современных технологий по функционалу и удобству развиваются значительно быстрее эволюции ограничений. В результате, исследования практической защищенности, если и рассматриваются, то вне темы сертификации, что порождает двойной объем работ и сложности в управлении проектами.
Презентация, подготовленная сотрудниками компании «Перспективный Мониторинг» для конференции DevCon 2015, содержит информацию о том, какие практики безопасной разработки позволяют удовлетворить как требования сертификации, так и потребности практической безопасности. Рассматриваются тонкие моменты на стыке этих задач, вопросы, в которых можно опереться на мировой опыт, а также планы регуляторов по развитию требований сертификации.
В докладе представлен опыт ЗАО «ПМ» по внедрению безопасной разработки в проекты создания и развития линейки средств защиты информации для сетевого оборудования, мобильных платформ и рабочих станций, подлежащих сертификации по требованиям регуляторов.
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Similar to STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Software Applications [RUS] (20)
2. О ЧЕМ ПОЙДЕТ РЕЧЬ?
1
2
3
4
Что такое «структурное качество» приложений?
Как соотносятся шаблоны ОО-проектирования и
показатели качества?
Что такое «анти-шаблоны»?
Какую помощь в обеспечении структурного качества
могут оказать современные языки?
Какие мероприятия могут помочь в обеспечении
структурного качества?
Реально ли повысить структурное качество уже написанных
приложений?
3. НЕФОРМАЛЬНОЕ ВВЕДЕНИЕ
1
2
3
4
Качество — это…
… «степень соответствия присущих характеристик <…>
изделия или продукта потребностям, ожиданиям»
(ГОСТ Р ИСО 9000). Различают качество программного
обеспечения (ПО) и исходного кода.
Основная задача
… планировать и осуществлять мероприятия по анализу и
повышению структурного качества исходного программного
кода как артефакта в процессах разработки ПО
Актуальность
Итеративные методы разработки; распространение методов
обеспечения и контроля качества на все этапы разработки
ПО; распространение методов ОО-анализа, проектирования
и разработки; применение UML и CASE-средств.
Первые результаты
Повышение качества управления рисками и затратами на
всех этапах жизненного цикла ПО
4. МОДЕЛИ КАЧЕСТВА ПО
Модели качества ПО — это упорядоченные
системы атрибутов, значимых для
заинтересованных сторон проекта
разработки ПО
Общий принцип — числовое выражение фактора:
линейная комбинация взвешенных влияющих
метрик
4,8𝒇𝒊 = 𝒘𝒊𝒋 𝒎𝒋
𝒋
Критерии
точка зрения
разработчика
точка зрения
пользователя
Факторы
Метрики
атрибуты
модели
Дж.
МакКол
Б. Боэм
ISO
9126
20
стр.
5. ВОПРОС #1
Что такое «качественное ПО»?
1
2
Что такое «качественное ПО»?
– Ответьте, используя не более шести слов.
Какие характеристики ПО, на ваш взгляд, можно
назвать структурными?
– Ответьте, используя не более шести слов.
20
стр.
6. МОДЕЛЬ КАЧЕСТВА ISO / IEC 9126
1991
2001
6
целей
ожидание
от ПО
21
атрибут
близость к
достижению
цели
ISO / IEC 9126
ISO 25000:2005
SQuaRE — Software product
Quality Requirements and
Evaluation
5
структурных
характеристик
ПО
❶Надежность
прочность, устойчивость;
степень риска, сопряженного с
использованием системы
❷Эффективность
производительность операций;
управление ресурсами; правила
кодирования
❸Безопасность правила кодирования;
обработка ошибок и исключений
документация в коде; удобство чтения
кода; отсутствие «грязных» техник;
переносимость кода
❹Удобство сопровождения
оценка трудозатрат в
ретроспективе и перспективе
❺Размер кода
7. МЕТРИКИ КАЧЕСТВА В МОДЕЛИ ISO / IEC 9126
1991
2001
6
целей
ожидание
от ПО
21
атрибут
близость к
достижению
цели
ISO / IEC 9126
SQuaRE — Software product
Quality Requirements and
Evaluation
ISO 9126-2, ISO 9126-3
Метрики
качества
Полнота и корректность
реализации функций
Отношение числа найденных
дефектов к прогнозному
Отношение числа проведенных
тестов к общему их числу
…
В трактовке ISO 9126,
качество ПО можно повысить,
не внося в него изменений
8. ЛАНДШАФТ МЕТОДОВ ОЦЕНКИ КАЧЕСТВА ПО
1
2
3
Необходим «запуск» объекта
исследования?
По анализируемым
артефактам
По способу
изучения
статические
динамические
формальные модели
исходный программный код
объектный коддокументация
инструментальный анализ
целенаправленная
инспекция (desk-checking)
рефакторинг
9. ВОПРОС #2
Ограничения статического
анализа
Возможно ли путем статического анализа установить
степень реализации следующих атрибутов качества
ПО? Ответьте «да» или «нет»
– Защищенность ________________________
– Понятность ________________________
– Правильность, точность ________________________
– Привлекательность ________________________
– Работоспособность ________________________
– Удобство анализа ________________________
– Удобство обучения ________________________
20
стр.
10. СТАТИЧЕСКИЙ АНАЛИЗ И СТРУКТУРНЫЕ
ПОКАЗАТЕЛИ КАЧЕСТВА
1
2
3
Статический
анализ:
Нефункциональные
требования:
Оценка качества:
удобство чтения низкая сложность
корректность обработки исключений
отсутствие предупреждений при компиляции
легкость отладки, тестирования, исправления
ошибок, поддержки и внесения изменений
полнота краткость
понятность надежность
структурированность
удобство сопровождения
компонентная структура
платформа архитектура
исходный код схема БД
11. МЕТРИКИ В АРТЕФАКТАХ
1
2
3
4
Архитектура
Соблюдение стандартов разработки архитектуры;
реализация шаблонов проектирования разного уровня;
показатели связности и повторного использования
компонентов
Транзакции и алгоритмы
Сложность транзакций и алгоритмов;
сложность приемов программирования и отсутствие
«грязных» техник
Исходный код
Соблюдение правил оформления кода;
обработка ошибок и исключений;
соответствие выбранной парадигме
Техническая документация
Удобство чтения и структурированность;
объем документации
12. БОРЬБА СО СЛОЖНОСТЬЮ: РАУНД 1
1
2
3
4
Сложность — это…
…атрибут качества, опосредованно оцениваемый через
количество, размер и связность единиц трансляции,
соблюдение правил и соглашений о проектировании,
моделировании, кодировании продукта
Снижению сложности способствуют…
…предварительное проектирование архитектуры
в соответствии с заданными критериями качества
с учетом ее реализуемости на выбранном языке
«Несложный» код:
«Несложный» код обеспечивает…
…снижение совокупной стоимости владения ПО
лаконичность модульность
использование шаблонов
слабая связанность
соблюдение правил
оформления кода
систематическая обработка ошибок
20
стр.
13. БОРЬБА СО СЛОЖНОСТЬЮ: РАУНД 2
1
2
3
4
Самодокументируемость кода
Обеспечивает понятность кода без обращения к
документации;
способствует соответствию исходного кода «внутренней
программной документации»
Композиция объектов компонентная разработка
Не порождает сильной связи суперклассов с подклассами;
не вызывает проблемы «хрупких» базовых классов (fragile
base class)
Контрактное программирование
Принцип «корректность по построению»
Подразумевает применение методов проектирования,
автоматически гарантирующих корректность получаемого
продукта
14. ВОПРОС #3
«Контракты» в коде и
качество ПО
1
2
Что вы знаете о контрактном программировании?
– Предложите свое определение контрактного
программирования, содержащее не более пяти слов.
Какие структурные показатели качества улучшает
применение «контрактов» в исходном коде?
– Ответьте, используя не более четырех слов.
20
стр.
15. ЗНАКОМЬТЕСЬ: ПРАКТИЧЕСКИЕ ПРИМЕРЫ
1
2
3
Стандарты и стили кода
Открытые: Google C++ Style Guide,
Code Conventions for the Java Programming
Language;
частные: корпоративные, командные и т.д.
Шаблоны проектирования
Фундаментальные (базовые);
GoF, Gang of Four (Э. Гамма и др.);
GRASP (К. Ларман);
PoEAA (М. Фаулер)
Автоматическая генерация, рефакторинг,
комментирование и документирование кода
CASE- и ALM-средства (в составе Microsoft Visual Studio,
Eclipse IDE, IntelliJ IDEA и т.д.);
Doxygen, javadoc и т.д.
16. ФУНДАМЕНТАЛЬНЫЕ ШАБЛОНЫ ОО-
ПРОЕКТИРОВАНИЯ. ШАБЛОНЫ GOF И GRASP
1
2
3
Цель ОО-проектирования
Разработка архитектуры согласно выбранным критериям
качества и с учетом ее реализуемости на выбранном языке
Типичные компромиссы
Соответствие дизайна задаче общность дизайна;
доступность элементов системы безопасность;
удобство вызова возможность тонкой настройки
Шаблоны (паттерны) проектирования —это…
…типовые архитектурные решения задач, в том числе:
фундаментальные шаблоны:
наследование, делегирование и др.;
шаблоны «банды четырех» (GoF):
стратегия, адаптер и др.;
шаблоны GRASP, PoEAA и др.
18. ПРИМЕР #2:
ШАБЛОНЫ ОО-ПРОЕКТИРОВАНИЯ (JAVA)
public class Singleton {
private static final Singleton instance =
new Singleton();
private Singleton() {
// …
}
public static Singleton getInstance() {
return instance;
}
}
19. ВОПРОС #4
Проблемы архитектуры и
качество ПО
20
стр.
Какие показатели качества ПО страдают от наличия
следующих проблем в архитектуре системы? Ответьте
полно, насколько это возможно. Время на ответ —
3 минуты.
– Наличие «божественных» классов или объектов
_______________________________________________
– Сильная связанность классов или объектов
_______________________________________________
– Невозможность замены способа выполнения операции
(запроса)
_______________________________________________
20. КАК СООТНОСЯТСЯ ШАБЛОНЫ
ПРОЕКТИРОВАНИЯ И КАЧЕСТВО
ПРИЛОЖЕНИЙ? (1 / 3)
Проблема Пример шаблона
Чрезмерное количество используемых
классов, объектов или глобальных
переменных системы
Наследование, прототип,
одиночка, посредник,
приспособленец
«Хрупкие» базовые классы Композиция
«Божественные» объекты
Декоратор, состояние,
стратегия
Слабая инкапсуляция (локализация) имен
или зависимость от имен
Абстрактная фабрика,
прототип, фабричный метод,
фасад, шаблонный метод
Слабая инкапсуляция (локализация) кода
или структур данных
Итератор, мост, наблюдатель
(менеджер), состояние,
стратегия, строитель, фасад,
шаблонный метод
Каждый шаблон (справа) призван решать проблемы в
архитектуре системы, последовательно устраняя
важнейшие причины перепроектирования (слева)
20
стр.
21. Проблема Пример шаблона
Дублирование кода
Наследование, композиция,
мост, шаблонный метод
Невозможность замены способа
выполнения запроса, сложность сочетания
поведений или динамического
конфигурирования системы
Декоратор, делегирование
(композиция), наблюдатель,
посредник, прототип,
состояние, стратегия
Потребность в универсальном или
альтернативном способе доступа (системе
запросов), абстрактном типе данных (ADT)
Адаптер, интерфейс, итератор,
компоновщик, наблюдатель,
посетитель
Потребность в глобальной точке доступа Одиночка
Потребность в константном объекте Неизменяемый объект
Зависимость системы от программной или
аппаратной платформы
Абстрактная фабрика, мост
Зависимость клиента от алгоритмов,
представления или реализации объекта
Итератор, мост
КАК СООТНОСЯТСЯ ШАБЛОНЫ
ПРОЕКТИРОВАНИЯ И КАЧЕСТВО
ПРИЛОЖЕНИЙ? (2 / 3)
20
стр.
22. КАК СООТНОСЯТСЯ ШАБЛОНЫ
ПРОЕКТИРОВАНИЯ И КАЧЕСТВО
ПРИЛОЖЕНИЙ? (3 / 3)
Проблема Пример шаблона
Сильная связанность классов или объектов
Команда, мост, посредник,
фасад
Чрезмерное использование наследования Декоратор, композиция
Недостаточная скорость выполнения
инициализирующих операций
Заместитель, отложенная
инициализация
Необходимость широковещательных
коммуникаций
Наблюдатель
Недостаточная расширяемость,
переносимость и безопасность
Заместитель, команда, мост,
фасад
Сложность архитектуры и компрометация
уровней многоуровневой системы
Наблюдатель, фасад
20
стр.
23. ЧТО ТАКОЕ «АНТИ-ШАБЛОНЫ»…?
Загадочный код (Cryptic code)
умышленное или неумышленное несоблюдение принципа
самодокументируемости исходного кода
Божественный объект (God object)
монолитный артефакт большого размера в исходном коде
Жесткий код (Hard code)
имена, адреса и пр. числовые и символьные литералы,
наличие которых затрудняет (делает невозможным)
конфигурирование системы
Магические числа (Magic numbers)
константы с трудно постижимой семантикой
24. … И ЧТО ТАКОЕ «ГРЯЗНЫЕ ТЕХНИКИ»?
«Мертвый» или пустой код
кодовые фрагменты, которые не используются в текущей
сборке (версии) приложения, устарели или сделаны «про
запас»
Архитектурно необоснованные заглушки
методы или функции, не выполняющие роль пустых
неабстрактных методов, шаблонных методов (GoF) или
операций-«зацепок» (hook operations)
Код с непредсказуемым поведением
обращение к неинициализированным
переменным, «трюки» в управлении
памятью, неконтролируемое
переполнение буферов и т.д.
25. ВОПРОС #5
Языки ООП и качество
исходного кода
20
стр.
1
2
Какие «внеязыковые» возможности современных
сред разработки могут помочь в обеспечении
структурного качества исходного кода?
Какие возможности языков ОО-программирования
вносят свой вклад в обеспечение структурного
качества кода?
– Ответьте полно, насколько это возможно. Время на ответ —
2 минуты.
26. КАКУЮ ПОМОЩЬ МОГУТ ОКАЗАТЬ
СОВРЕМЕННЫЕ ЯЗЫКИ
ПРОГРАММИРОВАНИЯ? (1 / 2)
C++ Java
Исполнение управляемого кода в
защищенной программной среде
быстро,
небезопасно
медленно,
безопасно
«Родные» методы
(выполняют код вне защищенной среды,
имеют доступ ко всем системным
ресурсам)
—
быстро, небезоп.,
непереносимо
Строгая типизация
Запрет автоматического приведения
(преобразования) типов
част., особ. в C++11
Средства динамической идентификации
типов времени выполнения (RTTI)
dynamic_cast,
typeid
instanceof
Отладочные утверждения (assertions)
времени компиляции (исполнения)
Автоматическая сборка мусора
эмулируется
20
стр.
27. КАКУЮ ПОМОЩЬ МОГУТ ОКАЗАТЬ
СОВРЕМЕННЫЕ ЯЗЫКИ
ПРОГРАММИРОВАНИЯ? (2 / 2)
C++ Java
Обобщенное программирование с
поддержкой безопасности типов данных
шаблоны
обобщения
Элементы рефлексии в исходном коде
характеристики
типов
аннотации
Расширенная поддержка ОО-парадигмы
(абстрактные классы, «листовые» классы /
методы, «удаленные» методы)
особ. в C++11
Обработка исключительных ситуаций.
Стандартные и пользовательские классы-
исключения
Спецификация типов исключений,
возбуждаемых методами классов
на усмотрение
разработчика
существуют
непроверяемые
Алгоритмы и структуры данных в составе
стандартных библиотек
20
стр.
28. ЭЛЕМЕНТЫ РЕФЛЕКСИИ В ИСХОДНОМ КОДЕ
1
2
3
4
Предотвращают…
…некорректное использование библиотек, ошибки при
выборе (типов) фактических параметров, непреднамеренные
ошибки в сигнатурах методов (архитектуре классов) и пр.
Выделяют и принуждают…
… к отказу от использования устаревающих элементов
архитектуры
Упрощают…
… работу с атомарными характеристиками типов и позволяют
предельно оптимизировать специализированные версии
универсальных функций и методов
Сопровождают…
… намеренно сохраненные в итоговой сборке кода
предупреждения при компиляции
29. АЛГОРИТМЫ И КОНТЕЙНЕРЫ В СОСТАВЕ
СТАНДАРТНЫХ БИБЛИОТЕК
1
Позволяют…
работать с эффективным готовым исходным кодом;
ускорить процессы разработки;
снизить издержки на сопровождение продукта
2
Предоставляют…
строгие гарантии вычислительной сложности операций
(напр., поиск элемента списка требует линейного времени)
широкие возможности повторного использования кода;
расширяемые, удобные, взаимозаменяемые программные
модули с унифицированными интерфейсами
3
Обеспечивают…
вариативность решения задачи с учетом предпочтений
разработчика;
структурную несовместимость контейнеров и алгоритмов,
неэффективных при совместной работе
𝑂 𝑁
30. ПРИМЕР #3: СТАНДАРТНЫЕ АЛГОРИТМЫ
СОРТИРОВКИ (STD. TEMPLATE LIBRARY, C++)
1
std::sort (вариант quicksort)
нестабильная сортировка на месте;
среднее время — 𝑶 𝑵 log 𝑵 ;
наибольшее время — 𝑶 𝑵 𝟐
2
std::partial_sort (вариант heapsort)
нестабильная сортировка на месте;
допускает получение отсортированного поддиапазона
длины 𝒌 < 𝑵;
наибольшее время — 𝑶 𝑵 log 𝑵 или 𝑶 𝑵 log 𝒌
3
std::stable_sort (вариант mergesort)
стабильная сортировка на месте;
адаптируется к ограничениям памяти (оптимальный объем
памяти — под 𝑵 𝟐 элементов);
наибольшее время — от 𝑶 𝑵 log 𝑵 до 𝑶 𝑵 log 𝑵 𝟐
31. КАКИЕ ОРГАНИЗАЦИОННЫЕ МЕРОПРИЯТИЯ
МОГУТ ПОМОЧЬ В ОБЕСПЕЧЕНИИ КАЧЕСТВА?
Выбор и внедрение модели качества ПО
Выбор модели и атрибутов качества, определение метрик
качества и их сравнительной значимости («весов»);
принятие модели качества в «обязывающей» форме;
утверждение и внедрение регламента регулярной оценки
качества
Программа повышения квалификации
(Принятая) модель и атрибуты структурного качества ПО;
расширенные возможности языков моделирования (UML),
запросов к БД (SQL) и языков программирования;
поддержка качественного проектирования и разработки
CASE-средствами, языками и инструментами
Соглашения о проектировании, моделировании,
кодировании
Активное применение языков моделирования и CASE-
технологий; автоматическая генерация исходного кода и
технической документации по нему
1
2
3
4
Аудит наличной архитектуры и кодовой базы
Разработка и реализация плана рефакторинга архитектуры
системы и ее исходного программного кода
32. РЕАЛЬНО ЛИ ПОВЫСИТЬ СТРУКТУРНОЕ
КАЧЕСТВО УЖЕ НАПИСАННЫХ ПРИЛОЖЕНИЙ?
Да!
❶ Провести комплекс
организационных мероприятий
❷ Запустить систематический
рефакторинг архитектуры
и исходного кода
❸ Провести дополнительное
тестирование приложения
❹ На регулярной основе пересматривать
и ужесточать требования действующей
модели качества приложения
❺ Держаться курса, чего бы это ни стоило!