Билет№1

Технология программирования и основные этапы её развития.

Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Как любая другая технология, технология программирования представляет собой набор технологических инструкций, включающих: 1/Указание последовательности выполнения технологических операций;2/Перечисление условий, при которых выполняется та или иная операция;3/Описание самих операций, где для каждой операции определены исходные данные, результаты, а также инструкции, нормативы, стандарты, критерии и методы оценки и т.п.

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

Основные этапы развития программирования как науки:

Первый этап – “ стихийное программирование ”. Этот этап охватывает период с момента появления первых вычислительных машин до середины 60-х годов 20 века. В этот период практически отсутствовали сформулированные технологии, и программирование фактически было искусством. Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных. Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение данных при программировании.

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

Третий этап – объектный подход к программированию (с середины 8-х до конца 90-х годов 20 века). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа, а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.

Четвертый этап – компетентный подход и CASE – технологии (с середины 90-х годов 20 века до нашего времени). Компонентный подход предполагает построение программного обеспечения из отдельных компонентов – физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов  объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде и использовать в любом языке программирования, поддерживающем соответствующую технологию. 

Билет№2

Проблемы разработки сложных программных систем.

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

Дополнительным факторами, увеличивающими сложность разработки программных систем, являются:1/Сложность формального определения требований к программным системам;2/Отсутствие удовлетворительных средств описания поведения дискретных средств описания поведения дискретных систем с большим числом состояний при недетерминированной последовательности входных воздействий;3/Коллективная разработка;4/Необходимость увеличения степени повторяемости кодов.

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

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

Коллективная разработка. Из-за больших объемов проектов разработка программного обеспечения ведется коллективом специалистов. Работая в коллективе, отдельные специалисты должны взаимодействовать друг с другом, обеспечивая целостность проекта, что при отсутствии удовлетворительных средств описания поведения сложных систем, достаточно сложно. Причем, чем больше коллектив разработчиков, тем сложнее организовать процесс работы.

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

 

Билет№4

Ускорение разработки программного обеспечения. Технология RAD.

Разработка спиральной модели жизненного цикла программного обеспечения и CASE – технологий позволили сформулировать условия, выполнение которых сокращает сроки создания программного обеспечения. Современная технология проектирования, разработки и сопровождения программного обеспечения, должна отвечать следующим требованиям: 1/Поддержка полного жизненного цикла программного обеспечения;2/Гарантированное достижение целей разработки с заданным качеством и в установленное время; 3/Возможность выполнения крупных проектов в виде подсистем, разрабатываемых группами исполнителей ограниченной численности с последующей интеграцией составных частей;4/Минимальное время получения работоспособной системы; 5/Возможность управления конфигурацией проекта, ведения версий проекта и автоматического выпуска проектной документации по каждой версии; 6/Независимость выполняемых проектных решений от средств реализации;7/Поддержка комплексом согласованных CASE –средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.8тим требованиям отвечает технология RAD (Rapid Application Development – Быстрая разработка приложений). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий разрабатываемого программного обеспечения.

Технология RAD хорошо зарекомендовала себя для относительно небольших проектов, разрабатываемых для конкретного заказчика.

Процесс разработки при этом делится на следующие этапы: анализ и планирование требований пользователей, проектирование, реализация, внедрение.

На этапе анализа и планирования требований формулируют наиболее приоритетные требования, что ограничивает масштаб проекта.

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

Технология RAD хорошо зарекомендовала себя для относительно небольших проектов, разрабатываемых для конкретного заказчика.

Билет№5

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

При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют два подхода: 1/Восходящий;2/Нисходящий.

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

Подход имеет следующие недостатки: 1/Увеличение вероятности несогласованности компонентов в следствие неполноты спецификаций;2/Наличие издержек на проектирование и реализацию тестирующих программ, которые нельзя преобразовать в компоненты; 3/Позднее проектирование интерфейса, а соответственно невозможность продемонстрировать его заказчику для уточнения спецификаций и т.д.

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

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

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

Нисходящий подход обеспечивает:1/Максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой;2/Раннее определение интерфейса пользователя, демонстрация которого к заказчику позволяет уточнить требования к создаваемому программному обеспечению;3/Возможность нисходящего тестирования и комплексной отладки.

Билет№3

Жизненный цикл и этапы разработки программного обеспечения.

Жизненным циклом программного обеспечения называют период от момента появления идеи создания некоторого программного обеспечения до момента завершения его поддержки фирмой – разработчиком или фирмой, выполнявшей сопровождение.

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

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

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

Проектирование. Основной задачей этого этапа является определение подробных спецификаций разрабатываемого программного обеспечения. Процесс проектирования сложного программного обеспечения обычно включает:

1/Проектирование общей структуры – определение основных компонентов и их взаимосвязей;2/Декомпозицию компонентов и построение структурных иерархий в соответствии с рекомендациями блочно – иерархического подхода;/3/Проектирование компонентов.

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

Реализация. Реализация представляет собой процесс поэтапного написания кодов программы на выбранном языке программирования (кодирование), их тестирование и отладку.

Сопровождение. Сопровождение – это процесс создания и внедрения новых версий программного продукта. Причинами выпуска новых версий могут служить:

1/Необходимость исправления ошибок, выявленных в процессе эксплуатации предыдущих версий;2/Необходимость совершенствования предыдущих версий, например, улучшения интерфейса, расширения состава выполняемых функций или повышения его производительности;3/Изменение среды функционирования, например, появление новых технических средств и / или программных продуктов, с которыми взаимодействует сопровождаемое программное обеспечение.

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

Билет№6

Структурное и “неструктурное” программирование.

Одним из способов обеспечения высокого уровня технологичности разрабатываемого программного обеспечения является структурное программирование.

Различают три вида вычислительного процесса, реализуемого программами: линейный, разветвленный и циклический.

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

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

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

После того, как в 60-х годах 20-го века было доказано, что сколь угодно сложный алгоритм можно представить с использование трех основных управляющих конструкций, в языках программирования высокого уровня появились управляющие операторы для реализации соответствующих конструкций. Эти три конструкции принято считать базовыми. К ним относят конструкции:

·          Следование – обозначает последовательное выполнение действий (рис.1,а)

·          Ветвление – соответствует выбору одного из двух вариантов действий (рис.1, б)

·          Цикл -пока – определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла (рис.1, в)                                         

Рис.1.

а –следование;                     б –ветвление;                                             в – цикл-пока.

                                                                      

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

 

Билет№7

Стиль оформления программы.

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

Стиль оформления программы включает: 1.Правила именования объектов программы (переменных, функций, типов, данных и т.п.);2.Правила оформления модулей; 3.Стиль оформления текстов модулей.

Правила именования объектов программы. При выборе имен программных объектов следует придерживаться следующих правил: 1.Имя объекта должно соответствовать его содержанию, например:MaxItem – максимальный элемент; NextItem – минимальный элемент;2.Если позволяет язык программирования, можно использовать символ “ _ ” для визуального разделения имен, состоящих из нескольких слов, например:

Max_Item; Next_Item;3.Необходимо избегать близких по написанию имен, например: Index и InDec.

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

1.Название модуля;

2.Краткое написание его назначения;

3.Краткое описание входных и выходных параметров с указанием единиц измерения;

4.Список используемых модулей;

5.Краткое описание алгоритма (метода) и /или ограничений;

6.ФИО автора программы;

7.Идентифицирующую информацию (номер версии и/или дату последней корректировки).

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

{проверка количества отрезков и выход , если отрезки не заданы}

if n<0 then

begin

WriteLn(“количество отрезков отрицательно”);

Exit;

End;

{цикл суммирования длин отрезков}

S:=0;

For i:=0 to n-1 do S:=S+Len[i];

Билет№8

Классификация программных продуктов по функциональному признаку.          

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

К системным обычно относят программные продукты, обеспечивающие функционирование  вычислительных систем . Это - операционные системы, оболочки и другие служебные программы (утилиты).

Операционные системы управляют ресурсами (процессором и памятью), процессами (задачами и потоками) и устройствами.

Оболочки (например, NORTON COMMANDER) появились для организации более удобного интерфейса пользователя с файловой системой MS DOS. Современные оболочки, такие, как FAR, используют для обеспечения пользователю привычной среды при работе с файловой системой.

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

Прикладные программы и системы ориентированы на решение конкретных пользовательских задач.

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

Разработчики программ используют специальные инструментальные средства, такие как, отладочные средства, системы программирования, среды разработки, CASE-средства.

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

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

Билет №9

Основные эксплуатационные требования к программным продуктам.

 

Эксплуатационные требования  определяют некоторые характеристики разрабатываемого программного обеспечения, проявляемые в процессе его функционирования. К таким характеристикам относят:

·          Правильность – функционирование в соответствии с техническим заданием;

·          Универсальность – обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных;

·          Надежность ( помехозащищенность) – обеспечение полной повторяемости результатов, т.е. обеспечение их правильности при наличии различного рода сбоев;

·          Проверяемость – возможность проверки получаемых результатов;

·          Точность результатов – обеспечение погрешности результатов не выше заданной;

·          Защищенность – обеспечение конфиденциальности информации;

·          Программная совместимость – возможность совместного функционирования с другим программным обеспечением;

·          Аппаратная совместимость – возможность совместного функционирования с некоторым оборудованием;

·          Эффективность – использование минимально возможного количества ресурсов технических средств, например, времени микропроцессора или объема оперативной памяти;

·          Адаптируемость – возможность быстрой модификации с целью приспособления к изменяющимся условиям функционирования;

·          Повторная входимость – возможность повторного выполнения без перезагрузки с диска;

·          Рентабельность – возможность “параллельного” использования несколькими процессами.

 

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

Билет№10

Спиральная цель разработки программного обеспечения.

В середине 80-х годов 20-го века была предложена спиральная схема. В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как “необходимое зло”, а стал восприниматься как отдельный важный процесс.

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

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

Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на которой обеспечена определенная функциональная полнота, продукт можно предоставлять пользователю, что позволяет: 1.Сократить время до появления первых версий программного продукта;2.Заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;3.Ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;4.Уменьшить вероятность морального устаревания системы за время разработки.

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

 


 

Билет№11

Типы пользовательских интерфейсов и этапы их разработки.

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

Различают процедурно - ориентированный и объектно – ориентированный подход к разработке интерфейсов.

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

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

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

 Интерфейсы со свободной навигацией также называют графическими пользовательскими интерфейсами. Интерфейсы данного типа ориентированы на использование экрана в графическом режиме с высокой разрешающей способностью. Графические интерфейсы осуществляют визуальную обратную связь с пользователем и возможность прямого манипулирования объектами и информацией на экране.

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

Этапы разработки пользовательского интерфейса: 1.Постановка задачи – определение типа интерфейса и общих требований к нему;2.Анализ требований и определение спецификаций – определение сценариев использования и пользовательской модели интерфейса;3.Проектирование – проектирование диалогов и их реализация в виде процессов ввода-вывода;

Реализация – программирование и тестирование интерфейсных процессов

Билет№12

Тестирование программных продуктов.

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

Процесс разработки программного обеспечения, в том виде, как он определяется в современной модели жизненного цикла программного обеспечения, предполагает три стадии тестирования:

·       Автономное тестирование компонентов программного обеспечения;

·       Комплексное тестирование разрабатываемого программного обеспечения;

·       Системное или оценочное тестирование на соответствие основным критериям качества.

Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:

·  Предполагаемые результаты должны быть известны до тестирования;

·  Следует избегать тестирования программы автором;

·  Необходимо досконально изучать результаты каждого теста;

·  Необходимо проверять действия программы на неверных данных;

·  Необходимо проверять программу на неожиданные побочные эффекты на неверных данных.

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

Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный.

Структурный подход базируется на том, что известна структура тестируемого программного обеспечения, в том числе его алгоритмы (“стеклянный ящик”). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.

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

 

Билет№14

Билет №14 Коллективная разработка программного обеспечения.

Организацию коллективного владения кодом иллюстрирует рисунок.

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

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

Кроме тестов модулей, создаются тесты приемки, они основываются на пользовательских историях. Эти тесты испытывают систему как «черный ящик» и ориентированы на требуемое поведение системы. На основе результатов тестирования разработчики включают в очередную итерацию работу над ошибками.

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

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

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

Еще одна составляющая коллективного владения кодом – непрерывная интеграция. Без последовательной и частой интеграции результатов в систему разработчики могут быть уверены в правильности своих действий. Кроме того, трудно вовремя оценить качество выполненных фрагментов проекта и внести необходимые коррективы. По возможности разработчики должны интегрировать и публично отображать, демонстрировать код каждые несколько часов. Интеграция позволяет объединить усилия отдельных пар и стимулирует повторное использование кода.

Билет№13

Составление программной документации.

Составление программной документации – очень важный процесс.

К программным относят документов, содержащие сведения, необходимые для разработки, сопровождения и эксплуатации программного обеспечения. Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.ХХХХ). Так ГОСТ 19.101-77 устанавливает виды программных документов для программного обеспечения различных типов. Основные программные документы:

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

Ведомость держателей подлинников должна содержать список предприятий, на которых хранятся подлинники программных документов.

Текст программы должен содержать текст программы с необходимыми комментариями.

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

Ведомость эксплуатационных документов должна содержать перечень эксплуатационных документов на программу.

Формуляр должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы.

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

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

Руководство программиста должно содержать сведения для эксплуатации программного обеспечения.

Описание языка должно содержать описание синтаксиса и семантики языка.

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

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

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

 

Hosted by uCoz