- •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. Роли участников команды бп.
8.Модели жизненного цикла. Их характеристики.
Жизненный цикл отражает различные состояния системы, начиная с момента возникновения необходимости в данном комплексе средств и заканчивая моментом его полного вывода из эксплуатации. Это совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования исходных требований к ней до окончания её эксплуатации.
I. Традиционный жизненный цикл.
анализ – определение того, что должна делать система;
проектирование – определение того, как система будет делать то, что она должна. Это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
программирование – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;
тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа;
внедрение – установка и ввод системы в действие;
сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.
Этапы разработки, тестирования и внедрения ИС обозначаются единым, объемлющим термином – реализация. В общем случае структура жизненного цикла зависит от назначения системы и режима её функционирования.
II. Модель эволюционирующего объекта
возникла необходимость в программной системе;
появилась возможность её создать;
система создана;
система соответствует потребностям заказчика;
система изменяется в соответствии с эволюцией объекта;
система стареет, теряет способность к развитию;
система гибнет из-за несоответствия потребностям заказчика и заменяется на новую.
III. Cтандарт жизненного цикла ISO/IEC 12207.
Не предлагается конкретная модель жизненного цикла и методы разработки программного обеспечения (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике).
Его регламенты общие для любых моделей, методологий и технологий разработки. Этот стандарт описывает структуру процессов жизненного цикла, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. Рассматриваются следующие стадии:
формирование требований к системе;
проектирование;
реализация;
тестирование;
ввод в действие;
эксплуатация и сопровождение;
снятие с эксплуатации.
На каждой стадии может выполняться несколько процессов и наоборот, один и тот же процесс может выполняться на разных стадиях. Это позволяет использовать стандарт для разных моделей.
9.Модели проектирования – каскадная, поэтапная, спиральная. Их особенности и области применения.
Каскадная модель предполагает переход на следующий этап после полного завершения работ предыдущего этапа. Она характерна для проектов с жёсткой дисциплиной исполнения. Принципиальные свойства чистой каскадной модели следующие [Вендров-1]:
фиксация требований к системе до её сдачи заказчику;
переход на следующую стадию проекта только после завершения работы на предыдущей.
Каждый этап заканчивается результатом, который документируется и служит исходными данными для следующей. Исходные требования фиксируются в начале работы над проектом и не изменяются.
Достоинства модели состоят в следующем: на каждом этапе готовится пакет документов, отвечающий критериям полноты и согласованности; порядок работы позволяет планировать сроки завершения работ и затраты.
Недостатки модели связаны с тем, что многие современные проекты по разным причинам на начальном этапе не до конца определены, и полностью требования формируются на стадии разработки. В этих условиях каскадную модель применять невозможно. Итак, основные недостатки модели следующие: позднее обнаружение проблем; нарушение графика работ; быстро устаревающая документация;риск создания системы, не удовлетворяющей потребностям заказчика.
Поэтапная итерационная модель предполагает, в отличие от каскадной, наличие циклов обратной связи между этапами. Преимущество такой модели в том, что межэтапные корректировки обеспечивают большую гибкость и меньшую трудоемкость по сравнению с каскадной моделью. Каждый этап работы в соответствии с этой моделью заканчивается сдачей и обсуждением результата в присутствии представителей заказчика, если это необходимо. Как только выявляется отклонение проекта от ожидаемого результата, проект дорабатывается, на что выделяется дополнительное время. Реально возврат проекта на более раннюю стадию может происходить в любой точке жизненного цикла, если обнаружилось несоответствие.
Достоинство этого подхода в том, что результирующий продукт достаточно хорошо соответствует ожиданиям заказчика, и риск провала системы невелик.
Тем не менее, длительность каждого из этапов из-за попыток сделать лучше может растянуться на весь период создания системы. Таким образом, главный недостаток модели – трудность планирования времени разработки и затрат на неё.
Спиральная модель – следствие попытки уменьшить неопределённость предыдущей модели при сохранении её гибкости. Основная её идея – разработка системы короткими, но законченными версиями, каждая из которых не удовлетворяет полностью требованиям заказчика, но последовательность версий итеративно приближается к ним. В ней делается упор на начальные этапы жизненного цикла: анализ, предварительное и детальное проектирование. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали.
Такой подход оправдан ещё и тем, что главная особенность современной индустрии заказных информационных систем состоит в концентрации усилий на двух начальных этапах ее жизненного цикла – анализе и проектировании, при относительно невысокой сложности и трудозатратах на последующих этапах.
Достоинства модели состоят в следующем: раннее получение результата; обратная связь: быстрое получение реакции пользователя; повышение предсказуемости поведения системы.
Недостатки модели: сложность планирования; сложность адаптации пользователя к множеству версий; напряжённость работы разработчиков; сложность смены (сопровождения) множества версий.
