- •Сущность и актуальность дисциплины «Технологии программирования», основные понятия и определения дисциплины.
- •Жизненный цикл программного средства.
- •Модели жизненного цикла по.
- •Модель с промежуточным контролем
- •Спиральная модель
- •Спиральная или итерационная схема разработки программного обеспечения
- •Изменение жизненного цикла программного обеспечения при использовании case-технологий.
- •Качество программного обеспечения.
- •Модели качества по
- •Метрики качества программного обеспечения.
- •Измерение и оценка качества по, стандартный метод оценки значений показателей качества.
- •Управление качеством пс.
- •Требования стандарта к организации системы качества
- •Диалоговые программы, типы диалога, формы диалога.
- •Спецификация пс.
- •Определение требований к программному средству.
- •Спецификация качества программного средства.
- •Функциональная спецификация программного средства.
- •Методы контроля внешнего описания программного средства.
- •Способы записи алгоритмов.
- •Представление основных структур алгоритмов.
- •Псевдокоды.
- •Flow-формы.
- •Диаграммы Насси-Шнейдермана.
- •Классификация структур данных.
- •Файловые структуры, физическая организация файлов.
- •Логическая организация файлов.
- •Документирование файлов.
- •Модульные программы, модули и их свойства.
- •Сцепление и связность модулей.
- •Нисходящая и восходящая разработка программного обеспечения.
- •Программирование «с защитой от ошибок».
- •Основные подходы программирования, «стихийное» программирование.
- •Основные подходы программирования, структурный подход к программированию.
- •Основные подходы программирования, объектный подход к программированию.
- •Основные подходы программирования, компонентный подход и case-технологии.
- •36. Процедурное (императивное) программирование
- •37.Функциональное программирование.
- •38. Декларативное программирование
- •39. Объектно-ориентированное программирование
- •40.Объектно-ориентированные языки программирования.
- •41. Спецификация программного обеспечения при структурном подходе.
- •42.Диаграммы переходов состояний.
- •43. Функциональные диаграммы
- •44. Диаграмма потоков данных
- •45. Моделирование управляющих процессов с помощью диаграмм потоков данных
- •46. Структуры данных и диаграммы отношений компонентов данных
- •47. Диаграммы Джексона.
- •48. Скобочные диаграммы Орра
- •49. Сетевая модель данных
- •50. Проектирование программного обеспечения при структурном подходе
- •54. Метод пошаговой детализации для проектирования структуры по
- •55. Структурные карты Констайна.
- •56. Проектирование структур данных
- •57. Представление данных в оперативной памят
- •60. Проектирование программного обеспечения, основанное на декомпозиции данных Методикой Варнье-Орра
- •61. Case-технологии, основанные на структурных методологиях анализа и проектирования
- •63. Определение «вариантов использования»
- •64. Диаграммы вариантов использования
- •65. Построение концептуальной модели предметной области
- •69. Проектирование программного обеспечения при объектном подходе
- •70. Разработка структуры программного обеспечения при объектном подходе
- •Определение отношений между объектами.
- •Диаграммы последовательностей этапа проектирования.
- •Диаграммы кооперации.
- •Уточнение отношений классов.
- •Интерфейсы в uml.
- •Проектирование классов.
- •Проектирование методов класса.
- •Компоновка программных компонентов.
- •Проектирование размещения программных компонентов для распределенных программных систем.
- •Методы доказательства правильности программ.
- •Метод индуктивных утверждений Флойда.
- •Метод Хора доказательства правильности программ.
- •Виды контроля качества разрабатываемого программного обеспечения.
- •Формирование тестовых наборов, основные подходы.
- •Ручной контроль программного обеспечения, методы ручного контроля.
- •I. Контроль обращений к данным
- •2. Контроль вычислений
- •3. Контроль передачи управления
- •4. Контроль межмодульных интерфейсов
- •Структурное тестирование, критерии формирования тестовых наборов.
- •Функциональное тестирование, методы формирования тестовых наборов.
- •Тестирование модулей и комплексное тестирование.
- •Оценочное тестирование.
- •Отладка программного обеспечения.
- •Классификация ошибок программного обеспечения.
- •Методы отладки программного обеспечения.
- •Методы и средства получения дополнительной информации об ошибках.
- •Общая методика отладки программного обеспечения.
- •Документирование и стандартизация.
- •Виды программных документов.
- •Основные правила оформления программной документации.
- •Основные инженерные подходы к созданию программ.
- •Классификация технологических подходов к созданию программ.
- •Классификация технологических подходов к созданию программ, подходы со слабой формализацией.
- •Классификация технологических подходов к созданию программ, строгие каскадные подходы.
- •Классификация технологических подходов к созданию программ, строгие каркасные подходы.
- •Классификация технологических подходов к созданию программ, генетические подходы.
- •Классификация технологических подходов к созданию программ, подходы на основе формальных преобразований.
- •Классификация технологических подходов к созданию программ, ранние подходы быстрой разработки.
- •Классификация технологических подходов к созданию программ, адаптивные технологические подходы.
- •Классификация технологических подходов к созданию программ, подходы исследовательского программирования.
- •Особенности и компоненты case-средств.
- •Объектно-ориентированные case-средства анализа и проектирования.
- •Структурные case-средства анализа и проектирования.
- •Case-средства компании ibm Rational Software, средство визуального моделирования Rational Rose.
- •Системы автоматизированного проектирования и их место среди других автоматизированных систем.
- •Структура сапр.
- •Разновидности сапр.
- •Понятие о cals-технологиях.
Классификация технологических подходов к созданию программ, ранние подходы быстрой разработки.
Развитием и одновременно альтернативой каскадных подходов является группа подходов быстрой разработки. Все эти подходы объединяют следующие основные черты:
итерационную разработку прототипа;
тесное взаимодействие с заказчиком.
Эволюционное прототипирование
Первый прототип при эволюционном прототипировании (evolutionary prototyping) обычно включает создание развитого пользовательского интерфейса, который может быть сразу же продемонстрирован заказчику для получения от него отзывов и возможных корректив. Основное начальное внимание уделяется стороне системы, обращенной к пользователю. Далее до тех пор, пока пользователь не сочтет программный продукт законченным, в него вносится необходимая функциональность (рис.19.10).
Эволюционное прототипирование разумно применять в тех случаях, когда заказчик не может четко сформулировать свои требования к программному продукту на начальных этапах разработки или заказчик знает, что требования могут кардинально измениться.
Существенным недостатком данного подхода является невозможность определить продолжительность и стоимость проекта. Неочевидным является количество итераций, по истечении которых пользователь сочтет программный продукт законченным.
Итеративная разработка
Первый прототип итеративной разработки (iterative delivery) уже должен включать завершенное ядро системы. Таким образом, в нем уже сосредоточена большая часть функциональности. Очередные итерации должны помочь пользователю определиться с доводкой пользовательского интерфейса и генерируемых систем отчетов и других выходных данных
Классификация технологических подходов к созданию программ, адаптивные технологические подходы.
Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во время работы в них необходимо учитывать природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).
Экстремальное программирование
Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (extreme programming) (XP) (http://www.extremeprogramming.org). Две основные черты, присущие быстрым разработкам, являются базовыми и в этом подходе. Методы, объединенные в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование дают существенные результаты и успешно выполненные проекты. Наибольшую пользу подход экстремального программирования может принести в разработке небольших систем, требования к которым четко не определены и позднее могут измениться.
Как происходит традиционный процесс разработки программного обеспечения? Организуется группа аналитиков, которая прикрепляется к проекту. Группа аналитиков в течение нескольких часов в неделю встречается с предполагаемыми пользователями, после чего они выпускают документацию на проект и приступают к его обсуждению.
Используя предоставленную им спецификацию, программисты по прошествии нескольких месяцев выпускают программный продукт, который более или менее соответствует тому, что от него ожидают. Зачастую к завершению проекта ситуация может измениться и пользователи пожелают внести изменения или добавления, которые осуществиться в данный момент не могут. Поэтому программисты, проведя тестирование, сдают программный проект заказчику в том виде, в каком он был заказан. Заказчик вынужден начать финансирование разработки новой версии программы.
Экстремальное программирование позволяет привлечь конечных пользователей для тестирования уже на ранних этапах проектирования и разработки системы. При этом заказчик обращается к разработчикам с просьбой изготовить программную систему. На протяжении всей работы над проектом необходимо присутствие представителя заказчика. Проект делится на три этапа:
этап планирования реализации: заказчики пишут сценарии работы системы на основе списка историй — возможных применений системы, программисты адаптируют их к разработке, после чего заказчики выбирают первоочередной из написанных сценариев;
итерационный этап: заказчики пишут тесты и отвечают на вопросы разработчиков, пока последние программируют;
этап выпуска версии: разработчики устанавливают систему, заказчики принимают работу.
Заказчик в экстремальном программировании имеет массу возможностей повлиять на направление работы команды, так как итерации проекта выдают каждые две недели программное обеспечение, которое можно использовать и тестировать. Принимая такое активное участие в разработке, заказчик может быть уверен в актуальности информации, используемой в работе системы.