Другое: Технология программирования

10.Чем отличается модель быстрой разработки приложений от инкрементной модели?

11.Объясните достоинства и недостатки модели быстрой разработки приложений.

12.Укажите сходства и различия спиральной модели и классического жизненно го цикла.

13.В чем состоит главная особенность спиральной модели?

14.Чем отличается компонентно-ориентированная модель от спиральной модели и классического жизненного цикла?

15.Перечислите достоинства и недостатки компонентно-ориентированной модели.

Лекция 2. Методология программирования. Этапы и уpовни pазpаботки пpогpамм. Техническое задание на pазpаботку пpогpамм. Этап технического пpоектиpования пpогpамм. Разpаботка стpуктуpных схем алгоpитмов. Оpганизация данных. Разpаботка стpуктуpы пpогpамм и внутpипpогpаммного интеpфейса

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

Разработка структурных схем алгоритмов

Алгоритмизация. Анализ существующего или разработка нового алгоритма. При анализе существующего алгоритма (или нескольких) следует обращать внимание на: расчетные формулы; характеристики алгоритма по скорости, точности, требуемой памяти и области его применимости. Вывод расчетных формул при описании алгоритма можно опускать. Как правило, в математических книгах алгоритмы описываются в виде, не пригодном к непосредственному переводу на язык программирования.

Пример. Вычислить значение

=ax3+bx2+cs+d

Прямое решение

=A*X**3+B*X**2+C*X+D

Более эффективное решение

Дальнейшее упрощение алгоритма - разложение полинома (методом Горнера):

y=ax3+bx2+cs+d=x(ax2+bx+c)+d=x(x(ax+b)+c)+d

В этом случае требуется выполнить по три действия сложения и умножения.

Выбор языка программирования. На практике выбор языка программирования зачастую ограничен наличием соответствующих трансляторов на доступной ЭВМ или стандартами организации. Если есть выбор, предпочтение отдается языку максимально высокого уровня, но такому, который может обеспечить требуемую эффективность программы.

Организация структуры данных. На основе выбранного алгоритма необходимо продумать организацию данных в ЭВМ: какие константы, переменные, массивы, структуры будут соответствовать обозначениям, принятым в алгоритме, какие нужны вспомогательные массивы и т.д. В зависимости от выбора структуры данных программа может значительно меняться по размерам и скорости выполнения.

Запись на псевдокоде. Перед программированием алгоритм следует записать в каком-либо виде с применением стилизованного естественного языка для описания структуры управления программой, конструкции которого близки к базовым управляющим конструкциям структурных языков программирования. Возможные формы записи: словесное описание, псевдокод, блок-схемы и т.п. При разработке псевдокода методом так называемой пошаговой детализации запись получается более удобной для последующего программирования и отладки. Фактически структура данных и псевдокод (схема) программы разрабатываются параллельно, все более уточняясь по мере детализации алгоритма.

Оптимизация. При высоких требованиях к эффективности программы по скорости и памяти на основе псевдокода принимаются решения по оптимизации программы: выделяются участки кода программы, которые целесообразно выделить в процедуры, выделяются циклы, по которым можно оценить наиболее медленные места программы. По структуре данных можно оценить необходимую память. Иначе говоря, на данном этапе имеются все необходимые данные для оценки параметров программы. Если программа не удовлетворяет требованиям эффективности, то следует вернуться к п. 5, 4 или даже 2. В крайнем случае, если выясняется невозможность удовлетворить требованиям технического задания, приходится возвращаться к п. 1.

Подготовка отладки. На схеме программы выделяются места, где будут использоваться средства отладки, и принимаются решения о том, какие средства будут применены. Отладочные средства ставятся в узловых точках схемы, на входах в процедуры, на длинных линейных участках ставят промежуточные печати.

Тесты. Разрабатываются по схеме и техническому заданию на программу. Определяя количество тестов, необходимо следить, чтобы проверялись все возможные варианты внешнего эффекта алгоритма и чтобы все ветви схемы были пройдены минимум один раз. Для каждого теста выписываются исходные данные, результаты и те данные, которые должны выдать отладочные средства. При составлении тестов могут быть обнаружены ошибки, для корректировки которых следует вернуться к п. 5 или 4, а далее повторно пройти этапы 5, 6, 7, так как изменения в схеме программы могут привести к иной расстановке отладочных средств и иному комплекту тестов.

Программирование. Перевод программы со схемы или другого псевдокода на конкретный язык программирования. Если на данном этапе выясняется возможность улучшить организацию данных, следует вернуться к п. 4.

Тестирование и отладка. Записанная на языке программирования программа выполняется с тестовыми исходными данными с целью обнаружения ошибок (тестирование). Если результаты выполнения расходятся с ожидаемыми, то принимаются меры к поиску причин расхождения (отладка). Для исправления ошибки необходимо перепрограммировать какую-то часть программы, т.е. вернуться к п. 4 или 5.

Счет. По завершении отладки из программы удаляются отладочные средства, программа записывается в оттранслированном виде на магнитные носители. Затем программа поступает в эксплуатацию.

Документация. Если программа предназначена для длительной эксплуатации, то при ней необходимо иметь полную документацию. Особенно это важно, если программа эксплуатируется не ее автором.

Таковы основные этапы разработки программы.

Модели качества процессов конструирования

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.

Базовым понятием модели СММ считается зрелость компании [61], [62]. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения.

Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.

Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости (рис. 1.9) и предусмотрен плавный, поэтапный подход к совершенствованию процессов - можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.

Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.

Для перехода на повторяемый уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов.

Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.

С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.

Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

Ø  предотвращения дефектов;

Ø  управления изменениями технологии;

Ø  управления изменениями процесса.

Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости.

Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.

Литература 3 [10-100]

Контрольные вопросы

.Назовите этапы алгоритма?

.Разработка структурных схем, объясните.

. Назовите модели качества создания прогрммы?

. Назовите критерии для оценки зрелости компании?

Лекция 3. Основы технологии программирования. Методы пpоектиpования пpогpаммного обеспечения. Hисходящее и восходящее пpоектиpование пpогpамм и их сочетание. Стpуктуpное пpогpаммиpование. Модульное пpогpаммиpование. Выбоp языка пpогpаммиpования. Стиль пpогpаммиpования. Показатели качества пpогpаммиpования. Читаемость пpогpамм, комментаpии. Пpогpаммиpование с защитой от ошибок. Этап отладки и испытания пpогpамм

Понятие технологичности программного обеспечения

Под технологичностью понимают качество проекта программного продукта, от которого зависят трудовые и материальные затраты на его реализацию и последующие модификации. Хороший проект сравнительно быстро v легко кодируется, тестируется, отлаживается и модифицируется.

Из опыта нескольких поколений разработчиков программного обеспечения известно, что технологичность программного обеспечения определяется проработанностью его моделей, уровнем независимости модулей, стилем программирования и степенью повторного использования кодов.

Стиль программирования, под которым понимают стиль оформления программ и их "структурность", также существенно влияет на читаемость программного кода и количество ошибок программирования. Кризис 60-х годов XX в. был вызван в том числе и стилем программирования, при котором программа напоминала клубок спутанных ниток или блюдо спагетти, и отсутствием языковых конструкций поддержки "структурного" стиля.

Для обеспечения необходимых технологических свойств применяются специальные технологические приемы и следуют определенным методикам, сформулированным всем предыдущим опытом создания программного обеспечения. К таким приемам и методикам относят правила декомпозиции, методы проектирования, программирования и контроля качества, которые под общим названием "структурный подход к программированию" были сформулированы еще в 60-х годах XX в.

В его основу были положены следующие основные концепции:

1нисходящая разработка;

2модульное программирование;

3структурное программирование;

4сквозной структурный контроль.

Нисходящая и восходящая разработка программного обеспечения

При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют два подхода:

восходящий;

нисходящий.

В литературе встречается еще один подход, получивший название "расширение ядра". Он предполагает, что в первую очередь проектируют и разрабатывают некоторую основу - ядро программного обеспечения, например, структуры данных и процедуры, связанные с ними. В дальнейшем ядро наращивают, комбинируя восходящий и нисходящий методы. На практике данный подход в зависимости от уровня ядра практически сводится либо к нисходящему, либо к восходящему подходам.

Восходящий подход. При использовании восходящего подхода сначала проектируют и реализуют компоненты нижнего уровня, затем предыдущего и т.д. По мере завершения тестирования и отладки компонентов осуществляют их сборку, причем компоненты нижнего уровня при таком подходе часто помещают в библиотеки компонентов.

Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы.

Подход имеет следующие недостатки:

увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций;

наличие издержек на проектирование и реализацию тестирующих про грамм, которые нельзя преобразовать в компоненты;

позднее проектирование интерфейса, а соответственно невозможности продемонстрировать его заказчику для уточнения спецификаций и т.д.

Исторически восходящий подход появился раньше, что связано с особенностью мышления программистов, которые в процессе обучения привыкают при написании небольших программ сначала детализировать компоненты нижних уровней (подпрограммы, классы). Это позволяет им лучше осознавать процессы верхних уровней. При промышленном изготовлении программного обеспечения восходящий подход в настоящее время практически не используют.

Нисходящий подход.

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