- •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. Защита программного кода
4. Понятия профессионального программирования
Декомпозиция – разделение сложной системы на несколько составных частей.
Классификация – система, согласно которой что-либо распределяется по группам, разрядам, признакам, принципам, классам.
Одна из наиболее известных и удачных классификаций – периодический закон и периодическая система химических элементов Д.М. Менделеева. Ему удалось найти такое расположение химических элементов, благодаря которому появилась возможность получить чёткую картину соотношения элементов и предсказать открытие новых элементов.
Если же классификационные принципы выбраны наугад, то возможно получение нечто подобного следующей классификации, описанной аргентинским писателем Хорхе Луисом Борхесом в новелле «Аналитический язык Джона Уилкинса»: «Животные подразделяются на:
а) принадлежащих Императору;
б) бальзамированных;
в) прирученных;
г) молочных поросят;
д) сирен;
е) сказочных;
ж) бродячих собак;
з) включённых в настоящую классификацию;
и) буйствующих, как в безумии;
к) неисчислимых;
л) нарисованных очень тонкой кисточкой из верблюжьей шерсти;
м) прочих;
н) только что разбивших кувшин;
о) из далека кажущихся мухами».
Программа – исполняемый код, пригодный для запуска своим автором на системе, на которой он был разработан.
Программный продукт – программа, которую любой человек может запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в обобщенном стиле, тщательно оттестирована и сопровождена подробной документацией.
«Любой человек» – программист, имеющий разрешение работать с исходными текстами программ.
5. Проект и команда
Проект – ориентированное на программный продукт (не на отдельный процесс!) объединение действий разработчиков.
Проекты классифицируют по:
степени коммерциализации;
масштабу.
Выделяют две степени коммерциализации проектов:
Коммерческий проект — его разработчики ориентируются на получение прибыли.
Некоммерческий проект – его разработчики ориентируются на приобретение опыта, статуса, обучение и т.п.
Некоммерческий проект, как правило, характеризуются децентрализацией. Менеджер (координатор) проекта не знает точного количества участников. Практически всегда это разработка с открытыми и доступными всем текстами программного продукта. Некоммерческие разработки распространяются с лицензией, запрещающей их использование в коммерческих целях.
В зависимости от масштаба можно выделить четыре категории проектов:
№ |
Категория проекта |
Количество разработчиков |
Протяженность |
1. |
Небольшой |
менее 10 |
от 3 до 6 месяцев |
2. |
Средний |
от 20 до 30 |
от 1 до 2 лет |
3. |
Крупно-масштабный |
от 100 до 300 в иерархии |
от 3 до 5 лет |
4. |
Гигантский |
от 1000 до 2000 в иерархии |
от 7 до 10 лет |
Группы участников процесса разработки подразделяют на девять категорий:
Управляющий комитет – получает планы от команд и утверждает/отвергает их. Определяет необходимость выпуска очередной версии продукта.
Команда разработчиков продукта – проектирует и разрабатывает продукт, объединяя коды его модулей (компонентов). Обычно включает в себя несколько команд разработчиков компонентов.
В некоторый момент от основных кодов ответвляется очередная версия для пользователей, за которую несёт ответственность команда версии.
Команда версии – отвечает за производство и помещение альфа-версии, бета-версии и версии первой поставки пользователю на страницах сервера Internet, дискетах, компакт-дисках или других носителях. В состав команды входят:
технические писатели;
инженеры тестирования;
инженеры качества;
специалисты по сопровождению продукта;
специалисты по продажам продукта.
Команда разработчиков компонента – предназначена для создания и развития модуля, компонента или отдельного свойства. В состав команды входят:
инженеры – разработчики;
инженеры тестирования;
технические писатели.
Начинает работу сразу после завершения проектирования продукта. После начала продаж занимается сопровождением продукта, исправляя ошибки, обнаруженные пользователями.
Пользователи – это заказчики, выдвигающие требования и получающие первый прототип ПО.
Архитектурный совет – обеспечивает информационный и технический базис для параллельного развития продуктов и следит за архитектурным постоянством изменений.
Совет старейшин – состоит из наиболее опытных сотрудников. Привлекается управляющим комитетом с целью распознавания возможных проблем и оценки перспектив.
Группа поддержки пользователей – оперативно отвечает на сложные технические вопросы клиентов.
Команда локализации – решает проблемы локализации (адаптации) продукта для конкретной языковой и культурной среды.
Последовательность версий программного продукта может быть проиллюстрирована следующим образом. Существует одна основная эволюционирующая версия, от которой по мере готовности ответвляются версии, предназначенные для пользователей.
Если новая версия включает существенные изменения (например, новый интерфейс), то увеличивается на единицу её «основной» номер (число перед точкой). Если изменения незначительны и сводятся к небольшим поправкам функциональности, то увеличивается на единицу «второстепенный» номер (число после точки). В ответвившиеся версии также могут вноситься исправления (обычно – только исправления ошибок).
Следует отметить, что развиваться и включать кардинальные изменения может только основная версия, остальные версии – лишь сопровождаются.