- •1.Предметная область. Прикладные программные системы (пс). Условия создания прикладных программных систем.
- •2.Автоматизированные системы управления и современные прикладные программные системы. Классификация, особенности.
- •3.Информационные системы и системы реального времени.
- •4.Требования к прикладным системам. Характеристика требований.
- •5.Требования к пс: адекватность предметной области; дружественность; возможность модификации.
- •6.Требования к пс: живучесть; защищенность. Проблемы переносимости. Универсальность и специализация.
- •7.Тиражирование прикладных систем. Тиражируемые, индивидуальные, слабо тиражируемые пс.
- •8.Модели жизненного цикла. Их характеристики.
- •9.Модели проектирования – каскадная, поэтапная, спиральная. Их особенности и области применения.
- •10.Планирование работы. Сетевой график.
- •11.Организация коллективной работы. Типы коллективов программистов.
- •12.Условия работы коллектива программистов.
- •13.Роли участников проекта: заказчик, пользователь, разработчик, руководитель, администратор.
- •14.Руководитель проекта, его действия по созданию работоспособного коллектива.
- •15.Профессиональная зрелость коллектива программистов.
- •16.Начальный этап проектирования. Анализ требований. Извлечение информации о предметной области.
- •17.Структурный системный анализ. Методология структурного системного анализа sadt (стандарт idef0).
- •18.Этап проектирования. Проектирование данных, функций, интерфейса, событий, выходных документов.
- •19.Потоки данных и процессы их обработки Диаграммы потоков данных в методологии Гейна-Сарсона.
- •20.Обсуждения: сквозной структурный контроль.
- •21.Принципы и виды отладки программ. Стратегии тестирования. Автономная и комплексная отладка.
- •22.Правила («Заповеди») тестирования.
- •23. Автономная отладка. Восходящее и нисходящее тестирование. Шаги автономного тестирования.
- •24. Комплексная отладка. Тестирование архитектуры, внешних функций, качества, документации, требований.
- •25. Особенности структурного тестирования (белый ящик). Его достоинства и недостатки.
- •26. Функциональное тестирование (черный ящик). Категории выявляемых ошибок.
- •27. Документирование прикладных программных систем. Этапы создания документации для тиражируемых систем.
- •28. Сдача прикладных систем в эксплуатацию.
- •29. Смена систем. Особенности проектирования «второй системы». Тактические приемы смены систем.
- •30. Особенности разработки заказных программных систем.
- •31. Подходы к перепроектированию технологических процессов: реинжиниринг бизнес-процессов (рбп) и асу.
- •32. Перепроектирование технологических процессов: модель управления по функциям и модель горизонтального потока. Цель и средства рбп.
- •33. Перепроектирование технологических процессов: риски. Критика подхода.
- •34. Перепроектирование технологических процессов и информационные технологии.
- •35. Классические и легкие методологии проектирования. Области применения.
- •36. Особенности подхода в методологии экстремального программирования.
- •37. Участники команды разработчиков в экстремальном программировании.
- •38. Экстремальное программирование: ценности, базовые принципы, виды деятельности.
- •39.Двенадцать правил экстремального программирования.
- •40. Риски легких методологий (на примере экстремального программирования).
- •41. Определение безнадежного проекта (бп). Категории бп.
- •42. Причины, порождающие безнадежные проекты.
- •43. Участники безнадежного проекта.
- •44. Отношение руководителя проекта и разработчиков к бп различных типов.
- •45. Оценка сложности проекта. Переговоры. Допустимые компромиссы.
- •46. Стратегии проведения переговоров в бп.
- •47. Человеческий фактор в бп: формирование команды.
- •48. Человеческий фактор в бп: условия работы.
- •49. Человеческий фактор в бп: мотивация, вознаграждение.
- •50. Роли участников команды бп.
14.Руководитель проекта, его действия по созданию работоспособного коллектива.
Производительность труда программиста заметно зависит от административной обстановки. Хороший администратор должен быть требовательным, но достаточно располагать к себе, чтобы не расхолаживать работников. Он должен быть не только технически компетентным, но и административно проницательным: должен обеспечить необходимый уровень требования, организовать обратную связь, отдавать должное хорошей работе и быть по необходимости строгим к промахам. Следует иметь в виду, что высоко бюрократизированная организация подавляет творческую деятельность, и это приводит к резкому снижению производительности труда программистов.
требовательность;
администратор – располагающий к себе человек;
компетентность: способность правильно распределить работу, организовать обратную связь, стимулировать работу разумным сочетанием поощрения и наказания.
Большое значение имеет стимулирование членов команды. Обычно есть желание поощрить своих разработчиков, но возможностей для этого не всегда хватает. Здесь нужно не оставлять без внимания ни одного события, достойного поощрения. Это может быть предоставление свободного режима работы, помощь в приобретении техники, организация отдыха, премия или другое материальное поощрение и т.п. Хуже дело обстоит с наказанием. Наказания обычно расстраивают команду, но иногда становятся необходимыми. Здесь лучше обойтись простыми методами и никогда не усердствовать. Известно, что положительные стимулы действуют слабее, но дольше, отрицательные сильнее, но быстрее забываются. Оптимальный вариант – сочетание этих подходов.
15.Профессиональная зрелость коллектива программистов.
Важная качественная характеристика коллектива программистов – его профессиональная зрелость. Она характеризуется прочными связями между ее членами, возникающими на основе общих ценностных ориентаций, позитивных неформальных отношений. Личные разногласия быстро устраняются, дисциплина носит сознательный характер, появляется чувство гордости за свой коллектив, складываются устойчивые традиции. Сотрудники имеют возможность раскрыть свой творческий потенциал, с энтузиазмом относятся к решению поставленных задач.
Методику измерения степени зрелости предложили немецкие специалисты В. Зигерт и Л. Ланг. Они предлагают оценивать степень зрелости, рассчитав по четырехбалльной шкале степень интенсивности 21-го негативного признака, основные из которых следующие:
активный поиск виновных в случае неудачи;
стремление работника обезопасить себя при помощи инструкций и докладных записок;
недостаточная информированность конкретных исполнителей;
первым о допущенной ошибке узнает не сам работник, а его коллега;
групповой эгоизм;
работник редко отождествляет себя с принятыми решениями;
дефицит времени для спокойной и планомерной работы;
недооценка коллективного руководства;
конфликты из-за мелочей;
совещания длительны и часто безрезультатны, сводятся к борьбе самолюбий;
работники не осведомлены о критериях оценки их труда;
новые идеи с трудом пробивают себе дорогу;
энтузиазм в работе – редкость;
коллектив расколот на ветеранов и новичков;
работа оценивается на уровне эмоций и поверхностных наблюдений;
многие работники недовольны, так как не могут применить свои знания на практике.
Минимизация степени интенсивности этих признаков свидетельствует о профессиональной зрелости коллектива.
Причины неэффективной работы коллектива
Непригодность руководителя (отсутствие соотв личностных качеств)
Неквалифицированные сотрудники.
Неконструктивный климат. (отсутствие преданности задачам команды, нет высокой степени взаимной поддержки в сочетании с заботой о благе каждого сотрудника).
Нечеткость целей – недостаточное согласование личных и коллективных целей
Низкие результаты работы. (целеустремленность)
Неэффективность методов работы. Подчеркивается значение правильной организации сбора и распределения информации, принятия правильных и своевременных решений.
Нехватка открытости и наличие конфронтации. (страха быть непонятым)
Недостаточные профессионализм и культура сотрудников. (нужны сотрудники с сильным характером)
Низкие творческие способности персонала.
Неконструктивные отношения с другими коллективами.
Непродуманную систему мотивации членов команды
Неадекватные формы контроля качества производимого продукта.
Можно так же рассмотреть вопрос с точки зрения выращивания команд программистов и рассматривают препятствия на этом пути. Травля команд (убойные способы нарушить социологию проекта):
оборонительная позиция руководства; руководитель не до конца доверяет набранной им команде компетентных специалистов, работник не имеет права на ошибку
бюрократия;
физическое разделение;( нет группового пространства, постоянной поддержки и воодушевленности, нет шансов на формирование групповой культуры)
дробление рабочего времени;( одновременное, чаще всего, вынужденное участие членов команды сразу в нескольких проектах)
снижение качества продукта; идиотские сроки сдачи;( самооценка и удовольствие от работы снижает необходимость создавать программный продукт, качество которого ниже их способностей; все участники проекта, включая руководителя, знают, что назначенный срок физически нереален.)
«насаждение клик». (означает, что зачастую не предусматриваются специальные меры для сохранения уже сложившегося здорового морально психологического климата, «духа команды». Вольно или невольно это происходит при переходе к новому проекту путем разделения команд.)
