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