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

• указание последовательности выполнения технологических операций;

• перечисление условий, при которых выполняется та или иная операция;

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

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

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

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

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

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

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

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

Утилита (англ. utility или tool) — вспомогательная компьютерная программа в составе общего программного обеспечения для выполнения специализированных типовых задач, связанных с работой оборудования и операционной системы (ОС)^[1].

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

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

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

3)

4) Основная категория специалистов, занятых разработкой программ — это программисты.

Системный программист (system /software programmer, toolsmith) занимается разработкой, эксплуатацией и сопровождением системногопрограммного обеспечения, поддерживающего работоспособность компьютера и создающего среду для выполнения программ, обеспечивающих реализацию функциональных задач.

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

Программист-аналитик (programmer-analyst)анализирует и проектирует комплекс взаимосвязанных программ для реализации функций предметной области.

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

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

Конечный пользователь (end user) является основным потребителем программ, относится к категории пользователей-непрограммистов.

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

6) Основные характеристики программ:

– алгоритмическая сложность (логика алгоритмов обработки информации);

– состав и глубина проработки реализованных функций обработки;

– полнота и системность функций обработки;

– объем файлов программ;

– требования к операционной системе и техническим средствам обработки со стороны программного средства;

– объем дисковой памяти;

– размер оперативной памяти для запуска программ;

– тип процессора;

– версия операционной системы;

– наличие вычислительной сети и др.

7) Качество ПП — это совокупность его черт и характеристик, которые влияют на способность ПП удовлетворять заданные потребности пользователя. Это, однако, не означает, что разные ПП должны обладать одним и тем же набором свойств с одинаковыми значениями количественных показателей. Как и в случае технических устройств, показатели качества являются противоречивыми, что означает: улучшение одних показателей качества может быть достигнуто за счет ухудшения других. Качество ПП является удовлетворительным, если количественные показатели свойств гарантируют успешное его использование.

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

8) Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

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

10) Вспомогательные процессы ЖЦПП; Основной целью в вспомогательных процессах является создание надёжного, полностью удовлетворяющего требованиям заказчика ПП, в установленные договором сроки.

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

-подготовительная работа;

-проектирование и разработка документации;

-выпуск документации и сопровождение;

Управление конфигурацией – предполагает применение административных и технических процедур на всем протяжении ЖЦПП. Включает в себя:

-определение состояния компонентов ПП;

-управление модификациями ПП;

-описание и подготовка отчетов о состоянии компонентов ПП;

-управления хранением и поставкой ПП;

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

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

-непротиворечивость к требованиям в системе и степень учета потребностей пользователей;

-возможности поставщика выполнить заданные требования;

-соответствие выбранных процессов ЖЦ условиям договора;

-адекватность стандартов процедур и среды разработки процессам ЖЦПП;

-корректность описания входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;

-тестируемость и корректность кода;

-адекватность, полнота и непротиворечивость документаций;

Процесс аттестации. Под аттестацией понимают подтверждение и оценку достоверности проведенного тестирования ПП.

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

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

Процесс разрешения проблем – предусматривает анализ и решение проблемы, обнаруженных в ходе разработки эксплуатации, сопровождении и др. процессов

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

12) Процессы жизненного цикла ПП, регламентируемые стандар­том ISO/IEC 12207, могут использоваться различными организа­циями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвя­зей между процессами с различных точек зрения, или в различ­ных аспектах. Взаимосвязи между процессами, описанные в стандарте, но­сят статический характер. Более важные динамические связи меж­ду процессами и реализующими их сторонами устанавливаются в реальных проектах.

13) Определение: надежность ПО – свойство составляющих его программ выполнять заданные функции в заданных условиях на конкретном КТС.Две основные причины возникновения отказов ПО:Разработчики ПО нарушили технические требования к программам (нарушены спецификации))Сами спецификации неточные или неполные, т. е. само описание того, что должна делать каждая программа, без указания как она должна это делать – неточное или неполное.Отличия надежности ПО от надежности КТС.элементы ПО не стареют от износа;число способов контроля ПО значительно больше, чем способов контроля аппаратуры;в ПО гораздо больше объектов для контроля, чем в аппаратуре в ПО гораздо проще вносить изменения, чем в аппаратуру, но это трудно делать корректно и безошибочно.

14) Жизненный цикл программного продукта – это период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.Программы любого вида характеризуются жизненным циклом, состоящим из отдельных этапов:a) маркетинг рынка программных средств, спецификация требований к программному продукту;b) проектирование структуры программного продукта;c) программирование (создание программного кода), тестирование, автономная и комплексная отладка программ d) документирование программного продукта, подготовка эксплуатационной и технологической документации;e) выход на рынок программных средств, распространение программного продукта;f) эксплуатация программного продукта пользователями;g) сопровождение программного продукта;h) снятие программного продукта с продажи, отказ от сопровождения. 15. Модели жизненного цикла разработки программного продукта

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;

2. Результаты выполнения работ на каждой стадии;

3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

16.Каскадная модель разработки пп

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

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

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

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

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

17.Модель быстрой разработки приложений (rad-модель)

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

Модель включает в себя следующие фазы:

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

Описание пользователя – проектирование ПП, выполняемое при непосредственном участии заказчика.

Создание – детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику.

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

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

18.Многопроходная модель разработки пп

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

Преимущества многопроходной модели:

*В начале разработки требуются средства только для разработки и реализации основных функций ПП.

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

*Снижается риск неудачи и изменения требований.

Недостатки многопроходной модели:

*Не предусмотрены итерации внутри каждого инкремента.

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

*Может возникнуть тенденция оттягивания решения трудных задач.

*Общие затраты на создание ПП не будут снижены по сравнению с другими моделями.

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