Даже в XXI веке, когда компьютеры и современная техника казалось бы захватили мир, человеческий фактор по-прежнему играет ключевую роль в нашей жизни. Так и при разработке корпоративных систем, которым посвящены несколько моих предыдущих курсов, весьма значительную роль играют аспекты менеджериально-управленческие. А кризисы в разработке КС, о которых мы говорили, во многом обусловлены человеческим фактором. Предметом курса является человеческий фактор в корпоративных системах, включающий особенности взаимодействия разработчика и заказчика, а также команд разработки программных продуктов. Командообразование, управление конфликтами, конструктивное общение, проведение и анализ результатов собеседований,- вот далеко не полный перечень знаний, умений и навыков, которые призван дать настоящий курс.
ACDM — мотивация
Loading...
來自 National Research Nuclear University MEPhI 的課程
Человеческий фактор в разработке корпоративных систем
1 個評分
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
National Research Nuclear University MEPhI
1 個評分
從本節課中
Информационное взаимодействие разработчика и клиента
В этом модуле мы рассмотрим особенности информационного взаимодействия между разработчиком и заказчиком. Вспомним ограничения в разработки программных систем, которые связаны с человеческим фактором. Мы посмотрим, каким образом выбор модели и методологии разработки программных систем влияет на результат. Обсудим, какие могут возникать ситуации при разработке.
與講師見面
Зыков Сергей ВикторовичДоцент
Кафедра кибернетики
Рассмотрим, как следует строить проектную команду в свете
архитектурно-центрического метода проектирования ICDM.
Прежде всего, нужно понять, каким образом архитектура,
ну мы уже об этом говорили: это компоненты и связи,
определяет специфику работы проектной команды,
и почему как можно скорее важно определиться с правильной
архитектурой. Ну, прежде всего, нужно заметить что улучшение
процесса разработки программных систем, на самом деле,
не всегда способствует качеству, совершенствованию качества
процессов проектирования. И в этой связи, к сожалению,
выясняется, что эксперты по проектированию зачастую
фокусируются, останавливаются на технических вопросах,
то есть вопросах, так сказать, второстепенных, более детальных,
и игнорируют процессы в целом.
Совершенствование процессов, повышение, так сказать, уровня
зрелости разработки в целом, отвлекаясь на, возможно,
второстепенные технические детали.
В результате получается следующее: проект в целом
и его процессы воспринимаются как тривиальная деятельность
или сводятся к конкретным артефактам (что-то получилось,
что-то не получилось — вот собственно и все).
Конкретные виды технического проектирования
не детализируются, то есть не уточняется, каким именно
образом мы будем осуществлять технические аспекты
проектирования. И даже в организациях, которые называют
себя зрелыми, процессы проектирования носят такой
достаточно анархичный произвольный характер —
как получится. Что же делать, чтобы этого не произошло?
Каким образом имеет смысл настраивать рабочие процессы?
Рассмотрим типичный проект и проект, который происходит
по схеме ICDM, и попробуем сфокусироваться на основных
целях. Естественно, при начале проектирования запуск проекта,
как это видно на схеме, у нас имеет место достаточно большое
количество неопределенности или, вообще говоря,
предкризисной ситуации, которая может привести к кризису,
может привести к достаточно предсказуемой разработке
проекта и в определенный момент, который у нас будет
называться условно точкой сборки мы получим дизайн
ситуацию: дизайн завершен да или проект готов.
То есть технический проект закончен, документация
разработана, и мы попадаем в ту точку, начиная с которой,
можно вести уже собственно реализацию.
В любом случае мы видим, что время, которое проходит
от запуска проекта до стадии дизайн завершен, на самом деле
может существенным образом варьироваться,
и оно определяется во многом той самой неопределенностью.
Как это, может быть, ни странно прозвучит, определяется
неопределенностью тех самых технических параметров,
тех самых архитектурных параметров, которые у нас во многом
и фиксируют архитектуру.
Таким образом, чем раньше мы зафиксируем адекватные
приоритеты с точки зрения атрибутов качества, с точки зрения
наших базовых компонентов и связей в рамках архитектуры,
чем быстрее мы с этим определимся, тем быстрее мы и придем
к той самой точке сборки, с которой можно начинать
детализированное архитектурное проектирование и реализацию.
Рассмотрим, каким образом происходит взаимодействие
в проектной команде при использовании метода ICDM,
и собственно, как такая команда организуется.
Ну, прежде всего мы напомним, что при разработке
программных систем участвует достаточно большое количество
различных специалистов и вообще говоря несколько команд.
Это команда заказчика, команда разработчика и существенную
роль, естественно, играет руководство и с той, и с другой стороны.
При этом руководство включает как топ-менеджмент,
то есть руководители, которые считают ресурсы: прежде всего
это люди и финансовые средства, это те функции, которые мы
получаем, и заказчик получает в итоге, и подход с точки зрения
«Давай мы этот проект запустим, мы разбогатеем, мы получим
какие-то дивиденды с этого» — то есть на самом деле это
вполне определенный подход, но он достаточно далек
от технического и, с другой стороны, достаточно далек
от маркетинга. Специалисты по маркетингу говорят, что те
или иные решения могут быть реализованы для тех или иных
клиентов. Давайте мы будем продавать, давайте мы разработаем
вот такое решение, которое обладает такими характеристиками,
зачастую не понимая, что вообще эти характеристики
нереализуемы, или их достаточно сложно реализовать в рамках
тех технологических возможностей, в рамках тех ресурсов
(временных и людских), которые мы имеем.
Третья сторона, кроме маркетинга и топ менеджмента,
даже со стороны разработчика это, так сказать, инженерия.
Это собственно технический персонал, который мыслит,
как мы видим, в терминах вполне определенных, в терминах,
измеримых в метриках программной инженерии строках кода,
в конкретных нотациях конкретных языков и технологий
программирования и так далее. То есть в совсем других
терминах. При этом все эти три подхода: подход маркетинга,
подход топ менеджмента и подход технических специалистов
должны быть как-то объединены и в этом нам помогает подход ICDM.
Вспомним, что программная инженерия возникла
из сопоставления методов, которые используются
при традиционном проектировании скажем, в строительных
организациях и попытки обобщения этого опыта на новую
предметную область создания крупномасштабных
компьютерных систем, и посмотрим, как ICDM можно здесь
использовать. Ну, на самом деле, оценки в строительной отрасли
можно непосредственно вывести из, так сказать, технического
задания, из архитектурных моделей.
В нашем случае это не совсем так и на слайде приведена пара
примеров. Это строки кода и функциональные точки,
которые подобны соответственно оценке количества болтов
для строительства моста и количества ударов молотка,
необходимых для того, чтобы построить дом.
Все это оценки достаточно приблизительные, достаточно
грубые. В ряде случаев на больших проектах они работают,
может быть, не вполне адекватно.
Именно поэтому потребовалось достаточно много лет
(порядка тридцати лет исследований) для того, чтобы методы
архитектурного проектирования были сформированы
и оформлены соответствующим образом, необходимым
для производства крупномасштабных систем.
При этом, одним из первых подходов был подход,
ориентированный на так называемые атрибуты качества.
Мы уже их упоминали. Некоторые из них —
это отказоустойчивость, безопасность, надежность,
эргономичность, переносимость и так далее.
Следующий подход — это архитектурный дизайн или дизайн,
управляемый архитектурой, и далее противовесы
или компромиссы, как скажем, безопасность
и производительность. Чем больше мы улучшаем безопасность,
тем больше у нас страдает производительность.
Но нам нужно обеспечить определенный баланс этих атрибутов
и ключевых атрибутов качества в целом, таким образом ICDM
и правильная организация команды, в данном случае мы будем
обсуждать именно командные роли, помогает нам правильно
сбалансировать атрибуты качества, адаптировать методы,
использовать нужные артефакты и правильные комбинации
существующих методов.
