
- •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. Роли участников команды бп.
12.Условия работы коллектива программистов.
Участник программного проекта во время работы находится в определенной обстановке, которая влияет на его работоспособность и на качество проекта [Шнейдерман-3]. Обычно рассматривают следующие виды обстановки:
Физическая
помещение: размер, освещенность, уровень шума, доступ к терминалу;
количество людей;
степень уединенности.
С точки зрения физической обстановки хорошим решением можно считать отдельную комнату для небольшого количества программистов (лучше для каждого) с удобным рабочим местом, включая стол и терминал, с большим окном, незначительным уровнем шума и с выходом в общее помещение для общения.
Социальная
желание/нежелание работать;
взаимоотношения.
Социальная обстановка играет важную роль, в небольших бригадах – ключевую. Работа в социально комфортной обстановке существенно повышает производительность труда программиста и стимулирует творческую активность.
Административная
требовательность;
администратор – располагающий к себе человек;
компетентность: способность правильно распределить работу, организовать обратную связь, стимулировать работу разумным сочетанием поощрения и наказания.
Производительность труда программиста заметно зависит от административной обстановки. Хороший администратор должен быть требовательным, но достаточно располагать к себе, чтобы не расхолаживать работников. Он должен быть не только технически компетентным, но и административно проницательным: должен обеспечить необходимый уровень требования, организовать обратную связь, отдавать должное хорошей работе и быть по необходимости строгим к промахам. Следует иметь в виду, что высоко бюрократизированная организация подавляет творческую деятельность, и это приводит к резкому снижению производительности труда программистов.
13.Роли участников проекта: заказчик, пользователь, разработчик, руководитель, администратор.
Заказчик – начальные сведенья о предметной области, тестирование.
Пользователь – эксплуатация.
Разработчик – программирование.
Руководитель – анализ требований, проектирование.
Администратор – координация проекта.
В работоспособных коллективах программистов каждый участник обычно играет какую-то роль. Роли условно можно разделить на технические и психологические.
Технические роли в бригаде:
Программист – основа проекта. Помимо прямой деятельности, он должен обеспечить понимаемость программ всей командой.
Заказчик – ставит задачу, уточняет и контролирует. Знать приоритеты работ и принимает решения в соответствии с ними.
Тестер – следит за регулярными запусками тестов.
Ревизор – следит за общей картиной разработки и контролирует успешность продвижения к цели.
Инструктор – контролирет правильность исполнения проекта и вмешивающийся в него по необходимости. В критические моменты он должен взять управление на себя и привести исполнение проекта в нормальное русло.
Консультант – приносит в команду знания для решения возникающих проблем.
Большой босс – руководит проектом и принимает основные решения. Он же за все и отвечает.
Психологические роли в бригаде:
Председатель – выбирает путь, по которому команда движется к цели. Умеет обнаружить сильные и слабые стороны команды.
Оформитель – придает законченную форму действиям команды, определяет рамки групповых обсуждений и общих решений.
Генератор идей – выдвигает новые идеи, пытается внедрять радикальные технологии.
Критик – анализирует проблемы, оценивает идеи, придает сбалансированность решениям. Противовес генератору идей.
Рабочая пчелка – превращает планы и концепции в практические рабочие процедуры.
Опора команды – поддерживает силу духа, способствует подъему командного настроя. Добытчик – налаживает внешние контакты, которые могут быть полезными для команды.
Завершающий – поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на стадии финального тестирования и сдачи.
Каждый участник может играть несколько ролей.