тематизированных знаний или наука об оптимальных способах приемах и процедурах проведения процесса прогр
Работа добавлена на сайт samzan.net:
- Понятие программного средства. Технология программирования. Программная инженерия.
ПС(software) - объект, состоящий из программ, процедур, правил, а также, если предусмотрено, сопутствующих им документации и данных, относящихся к функционированию системы обработки информации.
Под технологией программирования понимается совокупность обобщенных и систематизированных знаний, или наука, об оптимальных способах (приемах и процедурах) проведения процесса программирования, обеспечивающего в заданных условиях получение программной продукции с заданными свойствами.
Программная инженерия – это область компьютерных технологий, которая занимается построением программных систем, настолько больших, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций.
- Основы жизненного циклаПС.
Жизненный цикл программы — это весь период ее разработки и эксплуатации, начиная с момента возникновения замысла и заканчивая прекращением всех видов ее использования.
Технология программирования изучает технологические процессы и порядок их прохождения — стадии.
Технологии удобно характеризовать в двух измерениях — вертикальном (представляющем процессы) и горизонтальном (представляющем стадии). Процесс — совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Процессы состоят из набора действий, а каждое действие из набора задач. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как рабочие процессы, действия, задачи, результаты деятельности и исполнители.
Стадия — часть действий по созданию программного обеспечения, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Стадии состоят из этапов, которые обычно имеют итерационный характер. Иногда стадии объединяют в более крупные временные рамки называемые фазами. Итак, горизонтальное измерение отражает динамические аспекты процессов и оперирует такими понятиями как фазы, стадии, этапы, итерации и контрольные точки.
Технологический подход определяется спецификой комбинации стадий процессов, ориентированной на разные классы программного обеспечения и на особенности коллектива разработчиков.
- Этапы жизненного цикла системы. Основные стадии разработки.
Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла — структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
Стадии жизненного цикла:
■ Анализ (разработка требований к ИС).
■ Проектирование (создание системы на логическом уровне).
■ Реализация (программирование, т.е. реализация на физическом уровне).
■ Внедрение (тестирование).
■ Эксплуатация (ввод в действие).
- Понятие жизненного цикла. Модели ЖЦ ПС. Каскадная и спиральная модель.
Жизненный цикл программы — это весь период ее разработки и эксплуатации, начиная с момента возникновения замысла и заканчивая прекращением всех видов ее использования.
Существует множество моделей процессов жизненного цикла систем и программных средств, но три из них в международных стандартах обычно квалифицируются как фундаментальные: каскадная; инкрементная (поэтапная); эволюционная (спиральная). Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла конкретного проекта.
Каскадная модель (характерна для периода 1970-1985 гг.). Предусматривает последовательное выполнение всех стадий проекта в строго фиксированном порядке. Переход на следующую стадию означает полное завершение работ на предыдущей стадии.
Можно выделить следующие положительные стороны применения каскадного подхода:
■ на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
■ выполняемые в логической последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе.
Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате кпредыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим итерационной модели.
Спиральная модель. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество, и планируются работы следующего витка. Особое внимание уделяется начальным стадиям разработки — анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Спиральная модель позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения вводятся временные ограничения на каждой из стадий жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
5. Роль системотехники в программной инженерии
Система – это совокупность взаимодействующих компонентов работающих совместно для достижения определяемых целей.
Системотехника – это технология создания систем, охватывающая все аспекты создания и модернизации сложных вычислительных комплексов. Сюда можно отнести технологию разработки аппаратных средств, внутренних вычислительных процессов и связей всей системы, а также технологию создания ПС. Инженеры системотехники на основе спецификации требований системы определяют её архитектуру и затем, собрав воедино её отдельные части, создают законченную систему.
Системотехника, как технология создания систем, охватывает процессы создания спецификаций, проектирования, разработки, тестирования, внедрения и сопровождения систем как единого целого. Системотехник, занимающийся разработкой вычислительных систем, не может быть сосредоточен только на программном комплексе, он должен уделять равное внимание программному средству, аппаратным средствам и средствам взаимодействия с пользователями и системным окружением. Специалист по созданию программного продукта должен понимать задачи и методы системотехники, поскольку возникающие проблемы часто являются результатом решений, принятых системотехниками.
Программная инженерия – это часть системотехники, которая охватывает аспекты программного средства от начальной стадии до окончательного выхода ПС из эксплуатации.
Отличительной особенностью системы является то что она обладает уникальными свойствами, которые формируются при взаимодействии компонент систем между собой.
6. Системные основы современной программной инженерии.
Основная цель современных технологийпрограммной инженерии состоит в обеспечении эффективности всего жизненного цикла комплексов программ для ЭВМ в различных проблемно-ориентированных областях. В понятие современной технологии включается совокупность методов и инструментальных средств автоматизации, а также технологические процессы, обеспечивающие жизненный цикл сложных ПС с заданными функциональными и конструктивными характеристиками качества.
Методической основой технологии, регламентирующей деятельность специалистов, является типовой технологический процесс. Он отражается набором этапов и операций в последовательности их выполнения и взаимосвязи, обеспечивающих ведения работ на всех стадиях от инициирования проекта и подготовки технического задания до завершения испытаний или применения версии ПС.
Индустриализация технологий программной инженерии базируется на стандартизации процессов разработки программ, их структурного построения и интерфейсов с операционной и внешней средой. Для этого с самого начала разработки должны определяться состав и этапы работ, необходимые для достижения конечной цели, а также требуемые для их выполнения ресурсы. Технические и управленческие проверки, анализ качества результатов промежуточных работ и компонентов, а также корректности их взаимосвязей должны обеспечивать руководителям и всем разработчикам уверенность достижения требуемого конечного результата проекта.
Методология обеспечения качества ПС в программной инженерии поддержана рядом методических документов и инструментальных средств, а также формализована комплексом международных стандартов. Концептуальные и организационные основы административного управления жизненным циклом и качеством ПС в системе СММ(CapabilityMaturityModel – система и модель для оценки зрелости), а также CMMI:2003, определены в восьми базовых принципах, которые декларированы в стандартах ISO 9000:2000 и ISO 15504:1-9.
11. Серия стандартов ИСО 9000 (ISO 9000) – группа международных стандартов, разработанных международной организацией по стандартизации (ИСО), для оказания помощи предприятиям, в построение эффективных систем менеджмента качества, а так же улучшения взаимопонимания в международной, и как следствие национальной торговле.
В России, как и во многих странах мира, стандарты серии ИСО приняты в качестве национальных стандартов. Национальные стандарты имеют обозначение ГОСТ Р ИСО и год отделяется от номера стандарта, знаком (-), вместо (:).
Состав серии стандартов ИСО 9000 (ISO 9000)
ИСО 9000:2008 “Системы менеджмента качества. Основные положения и словарь».
ИСО 9001:2008 «Системы менеджмента качества. Требования».
ИСО 9004:2009 «Менеджмент с целью достижения устойчивого успеха организации. Подход с позиции менеджмента качества».
ИСО 19011:2002 «Руководящие указания по аудиту систем менеджмента качества и/или систем экологического менеджмента».
Широкое распространение стандартов серии ISO 9000 получило после принятия Европейским Экономическим Союзом стандартов серии ISO 9000 в качестве основополагающих в сфере международной торговли, в рамках Европейского сообщества.
В России международным стандартам серии ИСО 9000 (ISO 9000) соответствует следующие национальные стандарты:
ГОСТ Р ИСО 9000-2008 «Системы менеджмента качества. Основные положения и словарь».
ГОСТ Р ИСО 9001-2008 «Системы менеджмента качества. Требования».
ГОСТ Р ИСО 9004-2010 «Системы менеджмента качества. Рекомендации по улучшению».
ГОСТ Р ИСО 19011-2003 «Руководящие указания по аудиту систем менеджмента качества и/или систем экологического менеджмента».
14. ГОСТ Р ИСО/МЭК ТО 12182-2002
Информационная технология. Классификация
программных средств
Настоящий стандарт предназначен для специалистов и области программной инженерии, пользователей и разработчиков стандартов в данной области.
Специалистам в области программной инженерии настоящий документ должен помочь в определении вида (типа) программного средства, для которого применимы конкретные стандарты программной инженерии, установлении критерием) запланированного риска, определения соответствия применяемой модели жизненного цикла (ЖЦ) условиям реализации конкретного проекта, определении усилия, необходимых для конкретной фазы жизненного цикла, и соответствующего для нее инструментария.
Пользователям и разработчикам стандартов настоящий документ должен помочь в определении подходов к классификации программных средств (ПС) и возможных вариантой стандартом для них на базе принятой схемы классификации и в последующем использовании данной схемы применительно к соответствующим ПС и стандартам программной инженерии.
С целью пояснения описываемой схемы классификации ПС в настоящем документе приведены примеры. Разработчикам стандартов настоящий документ поможет при классификации существующих, разрабатываемых и перспективных стандартов.
Настоящий стандарт определяет основы классификации ПС. схему классификации и содержит примеры применения соответствующих стандартов.
(функции ПС, прикладная область ИС, режим эксплуатации, требования надежности, к выч. ресурсам и тд)
15. ГОСТ Р ИСО/МЭК ТО 15271-2002
Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
В настоящем стандарте приведены рекомендации по практическому применению ГОСТРИСО/МЭК 12207 в условиях реализации конкретных проектов создания программных средств. Опытное применение ГОСТРИСО/МЭК 12207 в ряде организаций подтвердило необходимость выработки таких рекомендации для однозначного понимания требований и норм, установленных в ГОСТРИСО/МЭК 12207. Вместе с тем. Ряд концептуальных положений и понятий, определенных в указанном стандарте, требуют дополнительного пояснения и более расширенной трактовки. В настоящем стандарте учтены обобщенные предложения по практическому применению ГОСТРИСО/МЭК 12207, представленные Техническим комитетом по стандартизации ТК 22 «Информационные технологии*.
***тут есть рекомендации по каждому этапу жизненного цикла ПС***
16. ИСО/МЭК 15910-99
ПРОЦЕСС СОЗДАНИЯ ДОКУМЕНТАЦИИ ПОЛЬЗОВАТЕЛЯ ПРОГРАММНОГО СРЕДСТВА
Существующие стандарты можно отнести к двум основным типам:
a) стандарты на продукцию, определяющие ее характеристики и требования к ней;
b) стандарты на процессы, определяющие конкретные методы создания продукции.
Возрастающий масштаб применения программных средств и их сложность вызывает необходимость наличия полной, точной и понятной документации на эти средства, доступной пользователям. Настоящий стандарт определяет способ достижения данной цели, устанавливая работы (что должно быть сделано и исполнителя), связанные с качеством документации пользователя программных средств.
Документация часто рассматривает нечто, разрабатываемое после создания конкретного программного средства. Однако с точки зрения качества разработки программной документации она должна рассматриваться как неотъемлемая часть процесса создания данного программного средства. При надлежащем подходе к данной проблеме требуется достаточно сложная работа по планированию документирования. Целью настоящего стандарта является стимулирование разработчиков программных средств к надлежащему использованию процесса документирования. Стандарт также представляет пользователям метод определения надлежащего применения процесса документирования при создании конкретного программного средства.
Основной работой по настоящему стандарту является создание комплексного плана разработки документации, реализация которого обеспечивает лучшее документирование программного средства. Для соответствия настоящему стандарту данный план должен включать в себя требования (спецификацию) к стилю оформления документов. Настоящий стандарт не определяет состав данных требований (то есть компоновку конкретного документа или используемый шрифт), но устанавливает их диапазон. Стандарт также определяет виды информации, представляемой заказчиком разработчику документации (документатору) для проверяющих и распространяющих документацию.
17. ГОСТ Р ИСО/МЭК ТО 16326-2002
Программная инженерия. Руководство по применению
ГОСТ Р ИСО/МЭК 12207 при управлении проектом
Программные средства являются неотъемлемой частью информационных технологий и традиционных систем, например транспортных, военных, здравоохранения и финансовых. Имеется тенденция к увеличению числа стандартов, процедур, методов, инструментальных средств и сред. связанных с разработкой программных средств и управлением программными проектами. Подобная тенденция вызывает трудности при управлении программными проектами и реализации соответствующих технологии, особенно при интеграции продуктов и услуг. Необходим определенный порядок при переходе от указанного многообразия к обшей структуре, удобной для профессионалов, обеспечивающей взаимопонимание при создании программных средств и управлении ими. Данная обшая структура установлена в ГОСТ Р ИСО/МЭК 12207.
Структура ГОСТ Р ИСО/МЭК 12207 охватывает весь жизненный цикл программного средства от возникновения идеи его создания до снятия с эксплуатации и состоит из процессов, определяющих заказ и представление программных продуктов и услуг. Данная структура также обеспечивает контроль за указанными процессами и их усовершенствование.
ГОСТ Р ИСО/МЭК 12207 представляет исчерпывающий набор процессов жизненного цикла программного средства. Конкретная организация для реализации поставленных целей может выбрать соответствующее подмножество (процессов, работ, задач) ига ГОСТ Р ИСО/МЭК 12207. Указанный стандарт может быть адаптирован для конкретной организации, проекта или приложения. Данный стандарт также может быть использован как для автономного программного средства, так И для средства, встраиваемого или входящего в общую систему.
В настоящем стандарте приведены рекомендации по использованию процесса управления, описанного в 7.1 ГОСТ Р ИСО/МЭК 12207. Большинство приведенных рекомендаций основано на международных и региональных нормативных документах по стандартизации и опыте людей, успешно руководящих программными проектами.
Настоящий стандарт не предназначен для установления каких-либо ролей или обязанностей организации.
Установлено, что определенные процессы, работы и задачи носят итерационный характер и могут проявляться и любом порядке или с любой частотой. Данные процессы, работы и задачи должны быть увязаны с другими процессами, работами и задачами, не указанными в настоящем стандарте, например со вспомогательными и организационными процессами жизненного цикла из ГОСТ Р ИСО/МЭК 12207.
Настоящий стандарт состоит из шести основных разделов и приложений А — Е.
18. ГОСТ Р ИСО/МЭК ТО 10000-3-99
Основы и таксономия международных функциональных стандартов. Часть 3. Принципы и таксономия профилей среды открытых систем.
Настоящий стандарт устанавливает применение основ функциональной стандартизации в части среды открытых систем (СОС). Стандарт определяет общие принципы и классификационную схему (таксономию) профилей СОС, которые могут быть или были представлены для принятия в качестве международных функциональных стандратов.
Функциональная стандартизация является составной частью работ, охватывающих общую область стандартизации информационных технологий, включая:
- базовые стандарты, которые определяют основополагающие и общие процедуры. Данные стандарты образуют инфраструктуру, которая может быть использована в различных приложениях, каждое из которых может выбирать собственные варианты реализации из предлагаемых базовыми стандартами;
- профили, которые определяют соответствующие подмножества или комбинации базовых стандартов, предназначенные для обеспечения конкретных функций. Профили устанавливают правила применения конкретных вариантов, описанных в базовых стандартах, и создают основу для разработки унифицированных, международно признанных аттестационных тестов;
- механизмы регистрации, которые обеспечивают средства для конкретной уточненной параметризации на основе базовых стандартов и профилей.
20. Понятие управления проектом. Методы планирования и управления.
Управление программной инженерией определяется как приложение вопросов управления (планирования, координации, контроля, отчетности и тд) к инженерной деятельности для систематического упорядоченного и измеряемого обеспечения разработки и сопровождения программных систем.
В рамках программной инженерии управленческая деятельность происходит на следующих трех уровнях:
- Организационное управление и управление инфраструктурой.
- Управление проектами
- Планирование и контроль программ количественной оценки.
Основой второго и третьего уровня являются сведения определенные в своде знаний по управлению проектами (PMBOK). Данный свод знаний определяет следующие области применения процесса управления:
- управление интеграцией проекта;
- управление содержанием проекта;
- управление сроками проекта;
- управление стоимостью проекта;
- управление качеством проекта;
- управление человеческими ресурсами;
- управление коммуникациями;
- управление рисками;
- управление закупками.
SWE-BOK отмечает, что область знаний управления проектами имеет непосредственное влияние на решение вопросов управления инженерной деятельностью в области разработки, сопровождения ПО. Поэтому в рамках программной инженерии основной упор делается на PMBOK в части процесса управления программной инженерии.
Управление проектом это приложение знаний, опыта, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к нему, а также ожидание участников проекта. PMBOK определяет 42 процесса управления проектом сгруппированных в 5 категорий:
- инициализация;
- планирование;
- исполнение;
- мониторинг и управление;
- завершение.
В управление проектами входит:
- определение требований;
- удовлетворение различных потребностей, решение проблем и удовлетворение ожиданий заинтересованных сторон проекта в ходе его планирования и исполнения;
- нахождение компромисса (уравновешивание) между ограничениями и проектом к которым относится:
- время;
- содержание;
- качество;
- бюджет;
- ресурсы (материалы, инструменты и тд);
- риски;
*В рамках управления проектами, согласно PMBOK, осуществляется управление проектами, программами и портфелями.
Портфель – это набор проектов или программ, а также других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей.
Программа – это ряд связных друг с другом проектов, управление которыми координируется для достижения определенных преимуществ и степени управляемости, недоступных при управлении ими по отдельности.
В рамках управления проектом и для его реализации в организации организуется офис управления проектами.
Офис – это подразделение или организация, осуществляющая различные функции, относящиеся к централизации и координации управления проектами.
Методы управления проектами
Следующие два метода были разработаны параллельно и независимо.
* Метод Критического Пути (МКП).
Метод критического пути предполагает выполнение следующей последовательности шагов:
- Составляется перечень работ, выполнение которых необходимо для достижения конечной цели проекта;
- Для каждой работы выявляются непосредственно предшествующие ей работы и непосредственно следующие за ней работы;
- Проверяем возможность совмещения работ во времени и в случае необходимости их разнесения с определением последовательности их выполнения;
- строится черновой вариант сетевого графика;
- осуществляется упорядочивание;
- рассчитываются временные параметры сетевого графика. Основным временным параметром сетевого графика является длительность критического пути. Критический путь это самый длительный путь от начальной вершины до завершающей вершины;
- осуществляется оптимизация сетевого графика.
* Метод анализа и оценки программ ПЕРТ (РЕRT — Ргоgram Evaluation and Review Technique)
21. ГОСТ Р ИСО/МЭК 12207-99
Процессы жизненного цикла программных средств
Назначение
Настоящий стандарт устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Настоящий стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств.
Настоящий стандарт также определяет процесс, который может быть использован при определении, контроле и модернизации процессов жизненного цикла программных средств.
Область распространения
Настоящий стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг; а также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств как в самой организации, так и вне ее. Стандарт содержит также те аспекты описания системы, которые необходимы для обеспечения понимания сути программных продуктов и услуг.
25. Инструментальные средства управления проектом. Классификация программных средств и их краткая аннотация.
26.
27.
28.
2. реферат дисертації на здобуття наукового ступеня кандидата економічних наук Львів ~1
3. і. Наратологія дозволяє здійснювати аналіз структурної організації художнього твору та діалогічної взаємод
4. тематика 469 Немецкий По 1 неделе англ
5. АР918417 МФ91 кн
6. Определитель матрицы равен сумме произведений элементов какойлибо строки на их алгебраические дополнения
7. История Казахстана
8. а OCR spellcheck- Neep newhck@ukr
9. никелевая руда которая автотранспортом доставляется до приемной площади ОФ
10. ЦДТ
11. Методика аппликационных работ с разными материалами в школе
12. Нефторированные хинолоны Кислота налидиксовая Невиграмон Неграм Спектр некоторые грам м-о кишечная
13. Українська полемічна думка у XVI XVIII ст
14. Об утверждении Положения о Федеральной службе финансовобюджетного контроля
15. Насилие на телевидении угроза обществу или правда жизн
16. Производство женских впитывающих гигиенических прокладок для личной гигиены
17. на тему- Анализ вексельных операций Выполнил-
18. Петр Дирихле
19. В процессе своей работы в любой прикладной области пользователю необходимо общаться с компьютерами и под
20. за спиной по команде руководителя прыгнуть в воду и проплыть дистанцию любым способом