- •1. Кризис программирования
- •2. Понятие жизненного цикла по
- •3. Требования к технологии проектирования
- •4. Понятия профессионального программирования
- •5. Проект и команда
- •6. Задача профессионального программирования
- •7. Алгоритмы
- •8. Модели и моделирование
- •9. Структурный подход
- •9.1. Проблема сложности
- •9.2. Сущность структурного подхода
- •9.3. Метод функционального моделирования (sadt)
- •9.3.1. Состав функциональных моделей
- •9.3.2. Методика построения модели
- •9.4. Метод моделирования процессов - потоков данных (dfd)
- •9.4.1. Общая концепция
- •9.4.2. Состав диаграмм потоков данных
- •13. Венгерская нотация
- •14. Методология и парадигма программирования
- •15. Современные методологии программирования
- •16. Методология императивного программирования
- •17. Методология объектно-ориентированного программирования
- •18. Методология функционального программирования
- •19. Методология логического программирования
- •20. Методология программирования в ограничениях
- •21. Методология структурного императивного программирования
- •22. Методология параллельного императивного программирования
- •23. Методология нейросетевого программирования
- •23.1. Модель нейрона с линейной функцией активации
- •23.2. Модель нейрона с радиальной функцией активации
- •23.3. Разработка нейросетевой модели
- •24. Основные типы ошибок в программах
- •25. Отладка и тестирование
- •26. Режимы работы компилятора Delphi для поиска ошибок
- •27. Задание режимов работы отладчика с помощью переключающих директив
- •28. Пользователи и их поддержка
- •29. Поддержка программиста: общие требования
- •29.1. Пролог модуля
- •29.2. Проектная документация
- •29.3. Оформление текста программы
- •30. Поддержка конечного пользователя
- •31. Технология программирования графики
- •31.1. Графическая подсистема оболочек Win32/64
- •31.2. Графические средства Delphi
- •31.3. Проектирование интерфейса с пользователем: компоненты стандартных диалогов
- •32.Технология компонентного программирования
- •32.1. Технология com
- •32.1.1. Общая концепция
- •32.1.2. Интерфейс com
- •32.1.3. Сервер com
- •32.2. Технология ole
- •32.2.1 Суть и содержание ole
- •32.2.2.Терминология ole
- •32.2.3. Автоматизация ole
- •32.2.4. Структурированная память
- •32.3. Технология corba
- •32.4. Технология Java
- •32.5.Технология .Net
- •33. Технология описания аппаратуры
- •Input clock, reset, en;
- •If(!reset)
- •34. Технология коллективной разработки
- •34.1. Авторская разработка
- •34.2. Коллективная разработка
- •34.2.1. Технические командные роли
- •34.2.2. Психологические командные роли
- •34.2.3. Типы совместной деятельности
- •34.3. Общинная модель разработки
- •35. Технология оценки качества по
- •35.1. Подходы к оценке качества по
- •35.2. Характеристики качества по
- •35.3. Оценка качества процесса разработки
- •35.3.1. Модель зрелости процесса разработки по
- •35.3.2. Определение возможностей и улучшение процесса создания по
- •35.4. «Достаточно хорошее» по
- •33.5. Стандартизация информационных технологий
- •Международные организации, входящие в структуру оон.
- •Промышленные профессиональные или административные организации.
- •Промышленные консорциумы.
- •36. Инструментальные средства поддержки некоторых технологических подходов
- •36.1. Инструментальные системы
- •36.1.1. Инструментальные среды программирования
- •36.1.2. Средства автоматизации разработки программ (case-средства)
- •36.1.3. Интегрированные среды
- •36.1.4. Репозитории проекта
- •36.2. Поддержка коллективной разработки: системы управления версиями
- •37. Организация диалогов
- •38. Защита программного кода
1. Кризис программирования
В среде профессиональных программистов существует понятие перманентного «кризиса программирования», который проявляется в следующем:
Большие проекты выполняются с отставанием от графика.
Большие проекты выполняются с превышением сметы расходов.
Разработанный программный продукт не обладает требуемыми функциональными возможностями.
Производительность разработанного продукта низка.
Качество разработанного продукта не удовлетворяет пользователя.
Основными причинами существования кризиса программирования являются:
Сложность. Одна из проблем определяется природой человеческого интеллекта и состоит в неспособности им обрабатывать сложность. Само понятие «сложность» следует рассматривать в виде двух аспектов:
Сложность программ. Данная составляющая является существенным, а не второстепенным свойством. Поэтому при описании программных объектов зачастую применяются приём абстрагирования от их сложности, а то и, вообще, от их сущности.
Сложность администрирования. Трудность осуществления надзора за исполнителями влечёт ослабление концептуальной целостности.
Согласованность. Значительная часть сложности относится к решению проблемы согласования различных интерфейсов.
Изменяемость. Программное обеспечение очень легко изменить. При этом появление добавленного кода («заплат») может привести к разрушению идей, заложенных в код изначально.
Незримость. Реальность программного обеспечения (ПО) не встраивается естественным образом в пространство. У ПО сверхсложное геометрическое представление – как правило, большое количество неориентированных графов, наложенных один на другой.
Разрыв между теорией и практикой во многих областях программирования оказывает существенное влияние на кризис программирования.
Незначительные результаты исследовательской работы в области разработки ПО. Исследования, проводимые в последнее время в университетах и большинстве коммерческих компаний, являются фрагментарными и односторонними. Многие крупные компании славятся не столько генерированием новых идей, сколько доводкой заимствованных или купленных.
Невозможность проанализировать и обобщить действия великих программистов за работой. Давно возникло понимание того, что некоторые программисты на порядок, а то и на несколько порядков, более полезны, чем остальные.
Невозможность менеджера правильно сформировать проектную команду.
Экстремальные условия, в которых выполняются многие проекты. Установлено, что продуктивность работы тех, кто находиться в хорошем офисе, и может, закрыв дверь, не отвлекаться на телефонные звонки и посторонние дела, почти в 2,6 раза выше, чем у находящихся в коллективных комнатах.
2. Понятие жизненного цикла по
Жизненный цикл (ЖЦ) ПО – это период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Жизненный цикл ПО включает следующие стадии:
Анализ.
Проектирование.
Программирование.
Тестирование и отладка.
Эксплуатация.
Модель ЖЦ ПО – это структура, определяющая последовательность выполнения действий и задач, а также взаимосвязи процессов на протяжении всего его ЖЦ.
Центральную часть формализованной дисциплины выполнения проекта любого ПО составляют методы и инструментальные средства проектирования. Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процесса в ЖЦ ПО.
Базовые документы, создаваемые для стандартизации в области технологий программирования разрабатываются в основном двумя организациями:
International Organization for Standardization (ISO) – Международная организация по стандартизации.
International Electrotechnical Commission (IEC) – Международная комиссия по электротехнике.
Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО является международный стандарт ISO/IEC 12207:1995 «Information Technology – Software Life Cycle Processes».
ISO/IEC 12207:1995 определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Стандарт определяет программный продукт как набор компьютерных программ, процедур, документации и данных. Процесс - совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Каждый процесс разделён на набор действий, каждое действие – набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости (заранее определённых последовательностей выполнения, как правило, не существует).
В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серия ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объёма, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально по форме, сроки действия - закончились, использование - нецелесообразно.
Процессы создания автоматизированных систем, в состав которых входит и ПО, регламентированы стандартами ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания», ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» и ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Однако процессы создания ПО для современных распределённых информационных систем (ИС), функционирующих в неоднородной среде, в данных стандартах отражены недостаточно, а отдельные их положения явно устарели.
В результате для каждого серьёзного проекта ИС приходиться создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому сегодня в отечественных разработках целесообразно использовать современные международные стандарты.
В соответствии со стандартом ISO/IEC 12207:1995 все процессы ЖЦ ПО разделены на три группы:
основные;
вспомогательные;
организационные.
Состав перечисленных групп процессов определен так, как показано на рисунке ниже.
Также стандартом ISO/IEC 12207:1995 определяется технология проектирования ПО.
Технология проектирования ПО - совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО.