20. Понятие технологии программирования

Технология программирования – это набор правил, методик, инструментов, позволяющих наладить производственный процесс выпуска какого-либо продукта. Разумеется, это определение не является полным. Надо упомянуть процессы планирования, измерения, оценки качества, ответственность исполнителя и многое другое.

В ТП входит:

1. архив с контролируемым доступом (для предотвращения внесения изменений в последний момент (пусть даже и из лучших побуждений), для отчуждения «программы от её автора»)

2. Машинная документация (на машинном носителе) – должна быть актуальна, должны оперативно вноситься исправления

3. Использование инструментальных средств. (в частности программы можно писать и отлаживать на инструментальных ЭВМ, а уже затем транслировать под целевые – тогда возможна параллельная разработка)

4. Соглашение о связях (напр. все рассматривают стек слева направо, возвращают значение через регистр R10 (даже если напр. кто-то вдруг выяснит, что через R7 быстрее), каждая процедура должна сохранять регистры…).

//Нельзя всё сводить только к программному инструментарию.

21. Жизненный цикл программы

Наша задача, чтобы цикл был конечный.

Первая модель – водопадная (waterfall)(не возвращаемся к предыдущему этапу):

Разработка сист. Требований (постановка)

Разработка треб.к ПО

Анализ(Планирование (люди, ресурсы))

Проектирование (структура, связи)

Реализация

Отладка

Документирование

Сдача

Сопровождение

Введено понятие прототипирования. Откат только на одну стадию назад.

Коллектив последовательно разрабатывает проект – от исходной концепции до комплексного тестирования. Эта модель требует определить опорные точки, в которых будет оцениваться сделанное и решаться вопрос о том, можно ли двигаться дальше (Так называемая оценка рисков). Такой подход хорош для проектов, в которых требования легко формулируются с самого начала, но не годится для сложных, когда требования могут неоднократно меняться. Кроме того, водопадная модель вынуждает готовить огромную массу документации и требует единообразной процедуры оценки результатов на каждом этапе. Эти две особенности часто приводят к синдрому "аналитического паралича", напряжённым отношениям между разработчиками, заказчиками и пользователями.

Циклическая модель с возвратами (если что-то не устраивает, возвращаемся к предыдущим этапам).

Спиральная модель: разработка приложения выглядит как серия последовательных итераций. На первых этапах уточняются спецификации продукта, на последующих добавляются новые возможности и функции. Цель этой модели – как можно раньше выявить риски и уже в первых версиях продукта устранить связанные с ними проблемы. В силу своей итеративной природы спиральная модель допускает корректировки по ходу работы, что способствует улучшению продукта. При большом числе итераций разработка по этой модели нуждается в глубокой автоматизации всех процессов, иначе она становится неэффективной. На практике у заказчиков и пользователей иногда возникает ощущение нестабильности продукта, так как они не успевают уследить за слишком быстрыми изменениями в нём. Наконец, во многих проектах, управляемых по спиральной модели, нет чётко определённого критерия окончания работы, поэтому разработка может длиться бесконечно, поглощая финансовые ресурсы и не давая желаемой отдачи.

Обычно также используют быстрое прототипирование(rapid prototype): создаётся начальный прототип с реализованными основными функциями, и показывается заказчику. Если последнего все устраивает, то потом из прототипа строится продукт. Данная модель позволяет уточнить постановку задачи. Хорошо бы иметь мощную технологию для этого(генерация форм например)