Открытый семинар для студентов в компании CUSTIS (25 сентября 2014 года).
Лектор: Игорь Беспальчук, руководитель проектов дирекции технологического развития.
Аннотация: Уже больше тридцати лет термин «архитектура» широко используется в разработке программного обеспечения. Без сомнения, архитектура — это нечто очень значительное, сложное, а может быть, и самое важное при создании качественного ПО. Но на вопрос о четком определении и критериях значимости архитектуры даже специалисты с большим опытом обычно отвечают уклончиво, умножая абстракции и не добавляя ясности в понимание. Неудивительно, что без четкого представления о том, что такое архитектура, нельзя сказать, какой она должна быть, как ее создать и как проверить, иными словами — как управлять архитектурой. На семинаре мы постараемся разобраться со всеми этими вопросами.
Видеозапись семинара: https://vimeo.com/107810012.
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++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
Открытый семинар для студентов в компании CUSTIS (25 сентября 2014 года).
Лектор: Игорь Беспальчук, руководитель проектов дирекции технологического развития.
Аннотация: Уже больше тридцати лет термин «архитектура» широко используется в разработке программного обеспечения. Без сомнения, архитектура — это нечто очень значительное, сложное, а может быть, и самое важное при создании качественного ПО. Но на вопрос о четком определении и критериях значимости архитектуры даже специалисты с большим опытом обычно отвечают уклончиво, умножая абстракции и не добавляя ясности в понимание. Неудивительно, что без четкого представления о том, что такое архитектура, нельзя сказать, какой она должна быть, как ее создать и как проверить, иными словами — как управлять архитектурой. На семинаре мы постараемся разобраться со всеми этими вопросами.
Видеозапись семинара: https://vimeo.com/107810012.
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++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
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
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
OrgLan: компактификация методов описания предпринятияAnatoly Levenchuk
Доклад А.Левенчука "ОргЛан: компактификация ситуационной инженерии методов, архитектуры предприятия, адаптивного управления кейсами в одном подходе" на 62 заседании Русского отделения INCOSE, 25 апреля 2012г.
Cистемная инженерия безопасности объектов недвижимости и бизнес-процессов.Yuri Bubnov
Структура метода системной инженерии безопасности объектов недвижимости и бизнес-процессов, основанного на международных стандартах ISO 24744, ISO 31000, ISO 22301, Archimate, OMG Essence и работах видных зарубежных учёных Nancy Leveson (MIT), Donald Firesmith (SEI).
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
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
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
OrgLan: компактификация методов описания предпринятияAnatoly Levenchuk
Доклад А.Левенчука "ОргЛан: компактификация ситуационной инженерии методов, архитектуры предприятия, адаптивного управления кейсами в одном подходе" на 62 заседании Русского отделения INCOSE, 25 апреля 2012г.
Cистемная инженерия безопасности объектов недвижимости и бизнес-процессов.Yuri Bubnov
Структура метода системной инженерии безопасности объектов недвижимости и бизнес-процессов, основанного на международных стандартах ISO 24744, ISO 31000, ISO 22301, Archimate, OMG Essence и работах видных зарубежных учёных Nancy Leveson (MIT), Donald Firesmith (SEI).
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
Управление заинтересованными сторонами — одна из ключевых техник бизнес-анализа, которая обсуждалась на «Вечере системного и бизнес-анализа» в С.-Петербурге 06 июня 2015 г. Ключевые вопросы: заинтересованные стороны и их интересы, точки зрения и представления; основные шаги управления заинтересованными сторонами, шаблон карты заинтересованных сторон по TOGAF9.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
"Новый подход к улучшениям в организации. Что видят "разбуженные". Как выйти из Матрицы, преодолеть её наследие и создать успешную компанию". Маркушина Елена Геннадьевна, руководитель Управляющего Центра Международной Гильдии Лидеров Перемен Kinsmark провела семинар в Новосибирском Отделении АН (Академгородок).
10 марта 2016
Докладчик: старший научный сотрудник Центра экономики Севера и Арктики СОПС к.э.н. А. В. Котов
Тема: Современный опыт региональной промышленной политики Германии: в какой степени возможен его трансфер в Россию?
http://mse-msu.ru/category/nauchnieseminary/
DIRECTUM: возможности системы электронного документооборотаDIRECTUM
Более подробная информация о модулях, бизнес-решениях и функциональных возможностях ECM-системы DIRECTUM на сайте http://www.directum.ru/system
Содержание:
- О системе
- Бизнес-решения
- Бизнес-консалтинг и внедрение
- Преимущества DIRECTUM
- Сообщество DIRECTUM
- Клиенты
- О разработчике
Softline — один из лидеров на рынке решений САПР/ГИС. Мы выполняем полный спектр работ по внедрению современных средств автоматизированного
проектирования ведущих зарубежных и отечественных производителей.
Основополагающий принцип автоматизированного проектирования — комплексный подход к решению задач. Размер наших проектов — от мелких доработок функционала сред проектирования до масштабного внедрения информационных систем поддержки процесса проектирования.
Представляем Вашему вниманию презентацию «Преодоление разрыва между программным управлением и системным инжинирингом», подготовленную специалистами Университета Управления Проектами для открытого семинара PMI.
Что такое системный инжиниринг? Что такое управление программами? Какое из представленных составляющих управления более важно для достижения цели? Ответы могут значительно отличаться, в зависимости от того, кто отвечает на эти вопросы. Вместе с тем, именно системный инжиниринг совместно с управлением программами способен обеспечить результат, который удовлетворит все заинтересованные стороны и будет достигнут в утвержденный срок и бюджет. Международный Совет по Системному Инжинирингу (INCOSE) и Институт Управления Проектами (PMI) определили, что управление программой и системное проектирование имеют схожие цели и не могут быть разделены. Давайте познакомимся со стандартами системной инженерии и ее связи с программным управлением.
Similar to Организационные структуры проектирования эис (20)
2. ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
Общая структура организации работ
по проектированию ЭИС
Процесс проектирования ЭИС включает
в себя большое количество
взаимосвязанных между собой
разнообразных элементов и
предполагает построение
соответствующей системы управления.
В качестве объекта разработки проекта
могут выступать либо вся ЭИС для
предприятия заказчика, либо только
отдельная подсистема или совокупность
подсистем, либо отдельные работы
3. ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
Проект как вид деятельности проектирующей организации отличается
следующими особенностями:
направлен на
достижение
конкретных целей
все проекты в
определенной
степени
неповторимы и
уникальны
координирует
выполнение
взаимосвязанных
действий
4.
5. ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
Управление проектными работами в этом случае может
осуществляться на нескольких уровнях:
руководителей проектных групп
руководителей проектов
руководства функциональными подразделениями
руководства обеспечивающих подразделений
руководства проектной организации
6. ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
Управление проектированием, как
правило, рассматривают в двух
аспектах: организационном и
функциональном.
В организационном аспекте
управление
проектированием
рассматривается по уровням
организационно-
административной
структуры с
соответствующими правами
и обязанностями субъектов
процесса проектирования.
В функциональном аспекте
управление проектированием
рассматривается как
применение
соответствующих методов и
средств организации и
ведения проектных работ.
7. Организация работ по
проектированию ЭИС определяется
порядком взаимодействия между
несколькими сторонами,
участвующими в этом процессе:
пользователем, заказчиком,
администратором и разработчиком.
Пользователь - это организация или
группа подразделений, которые
используют результаты обработки
информации на ЭВМ. Для ЭИС под
пользователем понимают прежде всего
административно-управленческий
аппарат, для которого создается эта
система.
Пользователь выполняет следующие
функции:
формирует исходные
данные
определяет состав задач
для автоматизации
определяет основные
требования к задачам
8. Заказчик - это ответственное лицо, под которым понимается
организация или подразделение и которое выполняет
функции:
формирует
требования к
системе
выдает
техническое
задание,
финансирует
разработку
ЭИС
проводит
внедрение и
прием проекта
ЭИС
ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
9. Разработчик - это ответственное лицо (организация или
подразделение), которое выполняет следующие функции
разрабатыв
ает ЭИС по
техническо
му заданию
заказчика
принимает
участие во
внедрении
осуществл
яет сдачу
проекта
заказчику
осуществляет
авторское
сопровождени
е проекта
Администратор - ответственное лицо, которое
выполняет эксплуатацию программно-технических
средств и информационного и методологического
обеспечения ЭИС (технологические и
инструкционные карты).
10. Существует несколько типов схем организации работ с участием
четырех сторон, выбор которых зависит от объема заказа.
1. Если заказ имеет небольшие размеры по стоимости и по продолжительности рабо
то принимают первую схему, в которой в одном лице выступают заказчик, разработ
и администратор
11. 2. Для больших и сложных заказов применяют схему, согласно которой
функции разработчика отделяются от функций заказчика и администратор
выполняются другой организацией
12. 3. В том случае, если заказчик - большая организация, которая курир
разработку нескольких проектов ЭИС, применяют следующую схем
13. 4. Отделение заказчика от разработчика позволяет последнему
привлекать к своей работе организации-соисполнителей разных уровн
иерархии, что, в свою очередь, позволяет использовать труд
специализированных и профессиональных организаций.
14. Переход экономики страны на
рыночные отношения привел
к тому, что в области
проектирования ЭИС
появился самостоятельный
рынок услуг по
проектированию, покупке и
установке вычислительной
техники, разработке
локальных сетей, прокладке
сетевого оборудования и
обучению пользователей,
выполняемых компаниями,
называемыми «системными
интеграторами».
Под термином «системный
интегратор» понимают компании,
специализирующиеся на сетевых и
телекоммуникационных решениях
(сетевые интеграторы), имеющие, в
свою очередь, сеть своих реселеров
(продавцов), или компании -
программные интеграторы.
15. Компания - «системный интегратор» выполняет следующий набор
функций:
продажа аппаратного обеспечения
продажа программного обеспечения
консалтинг, проектные работы, сервис,
техническая поддержка, обучение
16. Организационные формы управления проектированием ЭИС
Организационная форма управления
проектированием ЭИС играет большую
роль в реализации задач повышения
эффективности процесса разработки
систем.
Формирование организационных форм управления в
организациях - разработчиках ЭИС осуществляется по
следующим принципам
17. Матричный принцип
Матричное построение
организационных
структур предполагает
формирование в
организации -
разработчике ЭИС из
специалистов
функциональных
подразделений
проектных групп для
разработки конкретных
проектов. При этом
специалисты не теряют
принадлежности к
соответствующему
функциональному
подразделению и
находятся в двойном
подчинении:
проектный принцип
Для построения
организационных
структур проектных
организаций наиболее
часто используется
проектный принцип.
На основе этого
принципа
формируется
организационное
подразделение -
проектная группа
(проект), которая
предназначена для
одноразовой
разработки ЭИС.
Функциональный принцип
Функциональный принцип
построения структуры
организации
используется при
выполнении задач
проектирования
постоянного характера..
Подобная
организационная
структура обладает
высокой степенью
централизации
управления,
авторитарным стилем
руководства. В области
разработки ЭИС
встречается весьма редко.
18. Подсистемное разделение труда в коллективе разработчиков ЭИС
базируется на свойстве декомпозируемости проекта на подсистемы,
каждая из которых независимо от числа технологических операций
проектирования разрабатывается отдельной группой специалистов.
Накопление знаний и опыта приводит к системной специализации
разработчиков ЭИС (например, специалистов по информационному
обеспечению, техническому обеспечению, экспертным системам и
т.п.) или к специализации по разработке компонентов ЭИС
(информационной базы, пользовательского интерфейса и т.п.).
ПРЕЗЕНТАЦИЯ ПО ДИСЦИПЛИНЕ
ПРОЕКТИРОВАНИЕ ЭИС
19. Типовые организационные структуры
проектной группы
Открытая
организационная
структура отличается
тем, что закрепленного
организационного
распределения
обязанностей нет.
Каждый член коллектива
разработчиков является
неформальным
руководителем на этапе
разработки системы, где
он более других
квалифицирован.
Централизованная
организационная
структура
предусматривает в
качестве руководителя
специалиста высокой
квалификации,
осуществляющего
административное и
техническое руководство.
Он же является
основным посредником
между группой,
заказчиком проекта и
внешними
организациями.
Децентрализованная
организационная
структура -руководитель
проекта осуществляет
управление группой
старших специалистов,
отвечающих за
разработку крупных
частей системы, а те
осуществляют
руководство младшими
специалистами, которые
поддерживают между
собой горизонтальные
связи в процессе
проектирования.
20. Типовые организационные структуры
проектной группы
Открытая
организационная
структура позволяет
варьировать
количество
разработчиков,
привлекая для
выполнения работ
наиболее
квалифицированных
специалистов, что
способствует
повышению качества
проекта.
Централизованная
организационная
структура
Особенностью данной
организационной
структуры проектной
группы является четкое
распределение функций
и полномочий между
специалистами.
Недостаток
заключается в
отсутствии проявления
инициативы
конкретных
исполнителей.
Децентрализованная
организационная
структура имеет
свойство двух
вышеизложенных
структур. Данная
организационная
структура применяется
в коллективах с
большой численностью
разработчиков (свыше
10 человек),
осуществляющих
проектирование
больших ЭИС
21. Организационные формы
реинжиниринга бизнес-процессов
Реинжиниринг бизнес-процессов в
узком смысле предшествует
проектированию ЭИС и соответствует в
традиционном представлении этапу
системного анализа, на котором, в
частности, определяются требования к
информационной системе