- •Понятие по: программа, программный комплекс, программный продукт, системный программный продукт.
- •Философия развития по. Тенденция развития по.
- •Инженерия по. Тенденции затрат на по.
- •Профессиональные и этические требования к специалистам по по. Основные проблемы, стоящие перед специалистами по по.
- •Управление качеством по и работа менеджеров по качеству.
- •Стандарт iso 9000 и управление качеством.
- •Вероятностные методы в оценке качества по.
- •Стандарты на продукцию и процесс разработки по.
- •Стандарты на техническую документацию.
- •Измерение показателей по. Характеристики качественного по.
- •Показатели программного продукта.
- •Объектно-ориентированные показатели.
- •Обзор моделей создания по.
- •Каскадная модель. Достоинства и недостатки каскадной модели.
- •Эволюционная модель. Два подхода к реализации эволюционного метода.
- •Формальная разработка систем.
- •Разработка по на основе ранее созданных компонентов.
- •Модель Миллса. Экстремальное программирование.
- •Спиральная модель разработки. Спиральная модель жизненного цикла разработки по
- •Спецификация по. Основные этапы.
- •Этапы процесса проектирования.
- •Управление проектами. Отличие программных проектов от технических.
- •Планирование проекта. График работ.
- •Анализ рисков.
- •Современный подход к проектированию по. V-цикл проектирования и разработки по.
- •Организация групп программистов.
- •Планирование проекта. План проекта. Контрольные метки этапов работ. График работ. Временные и сетевые диаграммы.
- •Методы проектирования.
- •Программирование и отладка.
- •Объектно-ориентированный анализ и проектирование (ооа/ооп). Методология объектно-ориентированного моделирования. Понятие объекта.
- •Сложные объекты. Использование объектной технологии. Объекты м классы объектов в uml. Взаимодействие между объектами.
- •Моделирование классов и отношений.
- •Пятиэтапный процесс тестирования. Альфа-тестирование, бетта-тестирование.
- •Эволюция программных систем.
- •Разработка по на основе визуального моделирования. Case – средства для разработки по. Ibm Rational & Rational Rhapsody.
- •Стандарты, регламентирующие Жизненный цикл по и процессы разработки.
- •Rup. Фазы и дисциплины унифицированного процесса.
- •Анализ требований на фазе начало up. Артефакты начальной фазы.
- •Стандарт uml 2.2.
- •Этапы проектирования ис с применением uml.
- •Диаграммы прецендентов.
- •Диаграммы классов.
- •Диаграмма объектов.
- •Диаграммы взаимодействия.
- •Метод ecm (Enterprise Component Modeling) в uml. Опишите игру в кости с помощью uml-diagram.
- •Методы верификации объектно-ориентированных программ.
- •Метод тестирования программ.
- •Организация проведения тестирования. Классификация ошибок.
- •Требования к покрытию критичных приложений тестами.
Инженерия по. Тенденции затрат на по.
Инженерия программного обеспечения (англ. Software Engineering) — приложение систематического, дисциплинного, измеримого подхода к развитию, оперированию и обслуживанию программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению.
Программная инженерия — это интегрирование принципов математики, информатики и компьютерных наук с инженерными подходами, разработанными для производства осязаемых материальных артефактов.
Дисциплина программной инженерии включается в круг вопросов компьютинга (англ. computing) и может рассматриваться как инженерная область, имеющая более тесные связи со своей базовой дисциплиной — компьютерными науками, — чем другие инженерные области. Среди других инженерных дисциплин она качественно выделяется нематериальностью программного обеспечения и дискретной природой его функционирования. Основываясь на математике и компьютинге, программная инженерия занимается разработкой систематических моделей и надежных методов производства высококачественного программного обеспечения, и данный подход распространяется на все уровни — от теории и принципов до реальной практики создания программного обеспечения, которая лучше всего заметна сторонним наблюдателям.
Термин «инженерия программного обеспечения» появился впервые в 1968 году на Конференции НАТО «Инженерия программного обеспечения» и предназначался, чтобы спровоцировать размышления относительно текущего в то время «кризиса программного обеспечения». С тех пор, это продолжилось как профессия и область исследований, посвященных созданию программного обеспечения, которое имеет более высокое качество, более доступно, поддерживаемо, и быстрее строится.
Так как область все еще относительно молода по сравнению со своими сестринскими областями инженерии, есть все еще большая работа и дебаты вокруг того, что представляет собой «инженерия программного обеспечения», и удовлетворяет ли оно понятию инженерии. Этот спор развивается естественным образом, начавшись с попыток рассматривать создание программного обеспечения только как программирование. Разработка программного обеспечения — термин, иногда предпочитаемый практиками в промышленности, которые рассматривают разработку программного обеспечения как несравнимо более мощную и конструкционноёмкую методологию в сравнении с процессом написания кода программистом.
Профессиональные и этические требования к специалистам по по. Основные проблемы, стоящие перед специалистами по по.
Управление качеством по и работа менеджеров по качеству.
Управление качеством программного обеспечения (SQM, Software Quality Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM определяет процессы, владельцев процессов, а также требования к процессам, измерения процессов и их результатов, плюс – каналы обратной связи.
Процессы управления качеством содержат много действий. Некоторые из них позволяют напрямую находить дефекты, в то время, как другие помогают определить где именно может быть важно провести более детальные исследования, после чего, опять-таки, проводятся работы по непосредственному обнаружению ошибок. Многие действия также могут вестись с целью достижения и тех и других целей.
Планирование качества программного обеспечения включает:
Определение требуемого продукта в терминах характеристик качества (см., например, область знаний “Управление программной инженерией”).
Планирование процессов для получения требуемого продукта (см., например, области знаний “Проектирование” и “Конструирование”).
Эти процессы отличаются от процессов SQM, как таковых, которые, в свою очередь, направлены на оценку планируемых характеристик качества, а не на реальную реализацию этих планов. Процессы управления качеством должны адресоваться вопросам, насколько хорошо продукт будет удовлетворять потребностям заказчика и требованиям заинтересованных лиц, обладать ценностью для заказчика и заинтересованных лиц и качеством, необходимым для соответствия сформулированным требованиям к программному обеспечению.
SQM может использоваться для оценки и конечных и промежуточных продуктов.
Некоторые из специализированных процессов SQM определены в стандарте 12207:
Процесс обеспечения качества (quality assurance process)
Процесс верификации (verification process)
Процесс аттестации (validation process)
Процесс совместного анализа (joint review process)
Процесс аудита (audit process)
Все эти процессы поддерживают стремление к достижению качества и, кроме того, помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем концентрируют внимание.
Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в данном проекте. Они предоставляют менеджерам основную информацию по каждому продукту и, кроме того, включают параметры качества всего процесса программной инженерии. Области знаний SWEBOK “Процесс программной инженерии” и “Управление программной инженерией” обсуждают программы качества для организаций, занимающихся разработкой программного обеспечения. SQM может предоставить соответствующую обратную связь для этих областей.
Процессы SQM состоят из задач и техник, предназначенных для оценки того, как начинают реализовываться планы по созданию программного обеспечения и насколько хорошо промежуточные и конечные продукты соответствуют заданным требованиям. Результаты выполнения этих задач представляются в виде отчетов для менеджеров перед тем, как будут предприняты соответствующие корректирующие действия. Управление SQM-процессом ведется исходя из уверенности, что данные отчетов точны.
Как описано в данной области знаний, процессы SQM тесно связаны между собой. Они могут перекрываться, а иногда даже и совмещаться. Они кажутся реактивными по своей природе, в силу того, что они рассматривают процессы в контексте полученной практики и уже произведенные продукты. Однако, они играют главную роль на стадии планирования, являясь проактивными как процессы и процедуры, необходимые для достижения характеристик и уровня качества, востребованных заинтересованными лицами <проекта> программного обеспечения.
Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале – disciplined) анализа рисков и <соответствующих> техник управления <рисками> в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”.
2.1 Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)
2.2 Проверка (верификация) и аттестация (Verification and Validation, V&V)
2.3 Оценка (обзор) и аудит (Review and Audits)
2.3.1 Управленческие оценки (Management Reviews)
2.3.2 Технические оценки (Technical Reviews)
2.3.3 Инспекции (Inspections)
2.3.4 Прогонки (Walk-throughs)
2.3.5 Аудиты (Audits)