- •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. Роли участников команды бп.
43. Участники безнадежного проекта.
Побудительные мотивы участия в БП могут быть разными.
расчет на вознаграждение в случае успеха (заметим, часто необоснованный)
тяга к выполнению трудных предприятий
удовольствие от интенсивной работы
наивные представления о своем всемогуществе
более прагматичные цели: возможность сделать карьеру, не попасть под сокращение, обеспечить себе лучшие условия работы и т.п.
Типичными «игроками» в безнадежном проекте являются следующие:
Владелец. Традиционно владелец - это человек, который принимает, санкционирует или финансирует систему и/или результаты проекта. Чрезвычайно важно идентифицировать этого человека и сделать все возможное, чтобы он был удовлетворен ходом проекта.
Владелец безнадежного проекта зачастую является руководителем гораздо более высокого уровня, чем в случае «нормального» проекта. С другой стороны, это не означает, что вся руководящая иерархия куда-то исчезла; наоборот, одна из проблем во многих безнадежных проектах заключается в том, что менеджер проекта совсем мало или вообще не контактирует непосредственно с владельцем проекта. Об этом важно помнить, поскольку изначальные требования владельца проекта могут быть легко искажены, пока достигнут менеджера проекта.
Заказчики - это как раз тот человек или, во многих случаях, группа людей, которые будут использовать разработанную систему после завершения проекта. Во всем мире такого человека или группу обычно называют «пользователями». Заказчики могут в свою очередь быть и владельцами безнадежных проектов, однако в большинстве случаев они являются административными или канцелярскими работниками, которые будут взаимодействовать с разработанной системой и эксплуатировать ее. В конечном счете, мы знаем, что в «нормальных» проектах пользователи могут полностью саботировать конечные результаты, отказываясь их использовать или утверждая, что они не соответствуют их требованиям.
Акционеры являются, по существу, «совладельцами» системы; хотя они могут и не иметь полномочий на то, чтобы начать проект, выполнить приемку его результатов или утвердить бюджет, они, тем не менее, кровно заинтересованы в его результатах. На самом деле, во многих случаях они имеют свою долю в бюджете, а также разделяют все прочие выгоды и риски, связанные с проектом.
Заинтересованные лица Разница между акционерами и заинтересованными лицами может показаться чисто теоретической, но на самом деле она важна. Заинтересованные лица - это те, кто имеет свою «долю» в конечных результатах проекта, даже если они не участвуют непосредственно в принятии решений. В этом смысле заказчики, владелец проекта и другие акционеры также являются заинтересованными лицами. Другими заинтересованными лицами могут быть члены руководящей иерархии, которым придется отказаться от использования своей старой информационной системы, если новая система будет сдана в срок. Они могут также быть членами различных объединений, поставщиками, заказчиками или конкурентами. Они могут даже быть другими сотрудниками.
Защитники. Постольку, поскольку существуют потенциальные противники безнадежного проекта, существуют и сторонники - включая таких, которые обладают столь большой властью и готовностью оказать помощь, что их называют защитниками. Нет ничего лучшего во всей вселенной, чем защитник, который одновременно является и владельцем проекта; защитниками могут также быть заказчики, акционеры и заинтересованные лица. Тем не менее, защитники обычно оказываются вне традиционного круга политических игроков проекта. Защитник может быть заинтересован в успехе молодого менеджера проекта - своего протеже; его интерес может быть также связан с успехом всего проекта в целом ввиду того влияния, который это оказывает на репутацию и доверие к IS/IT-подразделению или всей организации.
