
- •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. Роли участников команды бп.
4.Требования к прикладным системам. Характеристика требований.
5.Требования к пс: адекватность предметной области; дружественность; возможность модификации.
6.Требования к пс: живучесть; защищенность. Проблемы переносимости. Универсальность и специализация.
Термин «хорошая прикладная система» может трактоваться по-разному. Заказчик доволен, если система ликвидировала какое-то узкое место в его производстве, обошлась дешево и не создала новых проблем. В пакете расчетных программ ценится скорость и точность расчетов, если это система индивидуальной разработки, важно небольшое время реализации. Анализируя множество положительных оценок ППС, можно выделить несколько основных свойств, которыми должна обладать хорошая ППС: адекватность предметной области, дружественность, способность к модификации, живучесть, защищенность, переносимость.
Адекватность обозначает, что ведущим фактором в определении свойств системы должна быть технология работы в предметной области, в частности, обработки информации. Она говорит о соотношении основных технологических этапов и функций прикладной программной системы. Программная система адекватна предметной области, если она отражает все этапы моделируемой технологической цепочки, не привносит дополнительных этапов и способна к уточнению и расширению функций в пределах технологии.
Дружественность программной системы связана с лёгкостью использования. В настоящее время этому вопросу уделяется большое внимание. Удобство и простота работы с системой позволяет снизить нагрузку на персонал и использовать специалистов более низкой квалификации. Понятие дружественности включает много аспектов, важнейший из которых – пользовательский интерфейс. Другие аспекты – документированность системы, предсказуемость ее поведения, возможность выбирать пути решения задачи в зависимости от категории пользователя и т.п. Иногда вместо термина «дружественность» используют термины «удобство», «эргономичность».К сожалению, в настоящее время эти термины стали порой заменять термином «юзабилити».
Способность системы к модификации (в терминологии [Вендров-2] – изменяемость) существенно влияет на продление времени ее эксплуатации за счет адаптации к изменяющейся предметной области. В свою очередь, это позволяет снизить стоимость автоматизации производства и избежать дорогого этапа преждевременной смены систем. Это свойство присуще системам, разработанным в соответствии со стандартами анализа, проектирования и программирования, с учетом предстоящего сопровождения, с использованием средств автоматизации разработки. Стоимость разработки с учетом модификации обычно достаточно высока, но в быстро меняющихся областях это может быть единственно приемлемым решением.
Живучесть (устойчивость к ошибкам программы и пользователей, способность сохранить информацию в экстренных ситуациях) системы рассматривается как способность системы функционировать в нештатных ситуациях. Это может быть спектр непредусмотренной информации, которую необходимо обрабатывать, или непредусмотренные технические характеристики устройств, или нештатные условия эксплуатации, или, например, работа с пользовательским интерфейсом с другим разрешением. Разумеется, любые отклонения от штатных условий могут быть только в определенных границах, но иногда они бывают неизбежными.
Защита программных систем от несанкционированного доступа – необходимое условие их существования. В настоящее время большинство организаций хранит информацию, в том числе и жизненно важную, на машинных носителях с доступом через программные системы, большое количество информации передаётся по линиям связи. В этих условиях не защищать как программную, так и информационную компоненты системы – обрекать организацию на большие потери.
Переносимость обозначает возможность нормальной эксплуатации программной системы в различных программно-аппаратных средах. Проблемы переносимости стояли перед программистами всегда, но раньше они касались в большей степени аппаратного обеспечения. В последнее время, в связи с насыщенностью предприятий и организаций программным обеспечением различного происхождения, более острой стала проблема интеграции программного обеспечения, а, следовательно, и разработка программных систем, допускающих интеграцию.
Универсальность и специализация. Надо сказать, что можно создавать универсальное ПО, которое будет работать с разными СУБД, операционными системами, устройствами, и т.д. Но это дорого, сложно и неэффективно (с точки зрения производительности), а специализация ПО позволяет повысить производительность и упрощает разработку. Но тогда использовать можно будет только в определенных условиях. Для того, чтобы создать универсальное ПО нужно пользоваться CASE-средствами.