Технология разработки ПО.

Оглавление Лекция 1. Проблемы разработки ПО и пути их решения Роль ПО и компьютеров в производстве, социальной жизни и науке. Инженерия ПО Проблемы разработки ПО Лекция2. Технология разработки ПО и качество ПО. Системный подход к разработке ПО. Жизненный цикл ПО. Технология разработки ПО и качество ПО Характеристики качества ПО Факторы, влияющие на качество ПО Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода Этапы жизненного цикла ПО. Каскадная модель жизненного цикла ПО. Лекция 3. Основные, вспомогательные и организационные процессы создания ПО. Жизненный цикл ПО и процессы верификации. Спиральная модель ЖЦ ПО. «Тяжелые и быстрые» технологии разработки ПО. Три группы процессов создания ПО Жизненный цикл ПО и процессы верификации. Тестирование, верификация, валидация. Различие в понятиях. V образная модель жизненного цикла ПО Спиральная модель ЖЦ ПО. «Тяжелые и быстрые» технологии разработки ПО. Экстремальное (ХР) программирование Лекция 4. Стандарты и разработка ПО. Три вида программных разработок с точки зрения технологии их создания. Виды документации, выпускаемой на систему и ПО. Виды и значение стандартов, требования стандартов Три вида программных разработок с точки зрения технологии их создания Разбиение СТС на подсистемы. Аутсортинг Параллельная разработка подсистем Виды документов, выпускаемых на ПО по этапам разработки системы. Задачи, решаемые на различных стадиях проектирования системы и ПО. Лекция 5. Проектирование архитектуры ПО. Итеративный характер проектирования системы и ПО. Структура ПО СТС Итеративный характер проектирования ПО. Стадии проектирования. Цена ошибок проектирования. Проектирование, основанное на моделировании (Model-Based Systems Engineering - MBSE) CASE технологии разработки ПО Задачи и результаты архитектурного проектирования ПО. Технология Rational Rose,UML Структура системы, иерархия управления и структура ПО Функциональные задачи и декомпозиция СТС Пример иерархической структуры ПО СТС Лекция 6. Временная диаграмма работы системы и работы ПО СТС с параллельными физическими процессами. Цикличность решения задач управления в системах с ЦВМ Временная диаграмма работы СТС в варианте использования системы Представления работы ПО СТС в виде набора «сечений», выполняемых последовательно. Представление работы ПО СТС в виде набора параллельных процессов. Лекция 7. Процессы. Контекст процесса. Взаимодействие между процессами или потоками. Многозадачная работа ПО СТС. Причины многозадачности. Задачи и процессы. Контекст процесса Схема возможных вариантов обмена информацией взаимодействующими процессами Повышение эффективности ПО за счет параллельных вычислений Закон Амдела Лекция 8. Технологии обеспечения взаимодействия процессов во времени. «Синхронизация» процессов Критический ресурс ЦВМ. Основное правило защиты ресурсов ЦВМ Синхронизация процессов Взаимное исключение процессов. Использование мьютексов Задача синхронизации «Читатели-писатели» Задачи синхронизации. «Обедающие философы» Технология синхронизации ПО. Intel Thread Checker (ITC) Лекция 9. Конструирование ПО. Минимизация сложности ПО. Приспособленность ПО к изменениям. Проектирование «сверху вниз» и «снизу вверх». Конструирование ПО Минимизация сложности ПО. Стратифицированная декомпозиция. Ожидание изменений. Приспособленность ПО к изменениям Стандарты в конструировании Практики кодирования. Рефа́кторинг Особенности конструирования программ для встроенных ЦВМ критических систем. Фиксированное распределение памяти Программные технологические заглушки и их использование Основные понятия структурного подхода к проектированию ПО. Основные понятия объектно - ориентированного подхода (ООП) к проектированию ПО. Лекция 10 . Конструирование аварийной защиты в ПО для минимизации ущерба от проявившихся ошибок. Автоматический контроль работы ПО встроенными средствами. Стратегии безопасности ПО и системы Виды контроля работы ПО. Контроль работы ПО встроенными средствами без прекращения его функционирования Эталоны для контроля работы ПО Стратегии безопасности. Три уровня реакции ПО на обнаруженную ошибку. Отказоустойчивые системы Перечень нештатных ситуаций. Аварийная защита Лекция 11. Организация и управление разработкой ПО СТС Управление разработкой ПО. Треугольник ограничений. Трудоемкость ПО и факторы, влияющие на нее. Планирование разработки ПО. Сетевые графики и диаграммы Ганта. Организация разработки ПО. Распределение работ и ответственности между разработчиками. Контроль хода разработки ПО. Управление качеством ПО в процессе разработки. Управление персоналом, мотивация Лекция 12. Технология отладки ПО. Ошибки ПО. Статическая, динамическая, структурная, функциональная отладки Ошибки ПО, отладка и тестирование ПО. Анализ обнаруживаемых в ПО ошибок и важность его проведения Классификация ошибок ПО Статическая отладка и динамическая отладка Принцип «белого» и «черного» ящика при динамической отладке ПО. Функциональная отладка Лекция 13. Структурная динамическая отладка. Автономная отладка (АО) и комплексная отладка (КО) ПО. Последовательность действий при отладке ПО Структурная динамическая отладка «Особые точки» при работе программ Автономная отладка (АО) и комплексная отладка (КО) ПО Драйверы и заглушки при автономной отладке Последовательность действий при отладке ПО. Лекция 14. Принципы выделения маршрутов отладки. Некоторые проектные модели оценки числа маршрутов при отладке ПО. Контроль отлаженности ПО в процессе отладки. Принципы выделения маршрутов при комплексной отладке Приближенный метод оценки числа вариантов для отладки ПО Контроль отлаженности ПО в процессе отладки. Регулярное и случайное дерево структуры ПО и устойчивость его структурного параметра Контроль отлаженности ПО в процессе отладки. Гипотеза Джелинского – Моранды и математическая модель надежности ПО Метод наименьших квадратов для аппроксимации экспериментальных данных по ошибкам ПО Лекция15. Моделирование работы систем с целью генерации данных для проведения комплексной отладки ПО. Наследуемое ПО. Мобильность ПО и реинжениринг ПО Проблема генерации данных на комплексную отладку Принципы математического моделирования Преимущества математического моделирования внешней среды Наследуемое ПО. Мобильность ПО и реинжениринг ПО Эмуляция работы старой ЦВМ на новой аппаратной платформе Лекция16. Непроизводительные затраты времени на повторения при комплексной отладке. Запоминание и восстановление информации в контрольных точках. Технологическая защита при разработке ПО. Принцип отчуждения подлинника. Принцип «повторяемости» результатов отладки с цифровой моделью внешней среды Непроизводительные затраты времени на повторения при отладке Контрольные точки. "Запоминание и восстановление" информации в контрольных точках Выбор оптимального шага контрольных точек Технологическая защита ПО. Задачи технологической защиты ПО Подлинники, учтенные копии, неучтенные копии. Служба архива подлинников Принцип отчуждение подлинника. Технология внесения изменений в ПО. Лекция 1. Проблемы разработки ПО и пути их решения Роль ПО и компьютеров в производстве, социальной жизни и науке. В развитых (и не очень) странах постоянно растут капиталовложения в то , что называется информационными технологиями, базирующимися на компьютерах и их ПО. При этом доля ПО в основном капитале выросла за 1980 - 2004: для ФРГ с 0,1% до 1,1%, для Франции с 0,1% до 1,05%, для США с 0,21% до 2,8% (т.е. > чем в 10 раз). Обычно выделяют три класса систем - неживую природу, живую природу и человеческое общество. Процесс развития всех классов систем связан с некоторым упорядочением и организа- цией, формой которого является управление. Отсюда вытекает укрупненная классификация процессов управления: -управление в неживой природе (в технических системах), являющееся предметом изучения технических наук; -управление в живых организмах (в биологических системах) , являющееся предметом изучения естественных наук; -управление в обществе (в социальных системах), являющееся предметом изучения социальных наук. Ключевая тенденция развития современных технических систем в том числе сложных технических систем (СТС) - перенос функциональной нагрузки с механических и электрических устройств и подсистем к интеллектуальным компонентам и технологиям, на которые возлагаются функции определения и изменения во времени управляющих воздействий, логической и информационной увязки работы энергетических и силовых компонент взаимодействующих устройств. Эта тенденция привела к использованию ЦВМ в качестве центрального звена управления большинства современных систем, технологических и бытовых установок. При проектировании и исследовании сложных технических систем и не только технических все большее место занимает компьютерное моделирование процессов, протекающих в таких системах, которое постепенно вытесняет классические методы исследований докомпьютерной эры. Оптимизация структур и параметров систем стала возможной с применением компьютеров и их программного обеспечения. Само программное обеспечение в упомянутых объемах стало создаваться только в связи с использованием компьютеров и компьютерного моделирования, как инструментальных средств для создания ПО. В развитии биологических и социальных систем также просматривается тенденция все более широкого применения ЦВМ и их ПО для обработки информации и выработки управляющих воздействий Растет использование ЦВМ в научных исследованиях. Со времен Сократа научный метод состоит из следующих составляющих: -поставить вопрос, -сформулировать гипотезу и найти доказательства, -поставить эксперимент, -объяснить результаты и сделать выводы, -пересмотреть гипотезу(вернуться к второму шагу). Компьютеры позволили изменить эти этапы и количественно и качественно. До появления компьютера мир представлялся линейным, нелинейные явления линеаризовывались – приближенно сводились к линейным, так как принцип суперпозиции для линейных систем позволял легко исследовать сложные явления по частям. Появление компьютеров сделало доступным исследование более сложной нелинейной динамики и на этом пути получены новые революционные научные результаты. Компьютерное моделирование во многих случаях позволяет заменить или дополнить физический эксперимент. В результате по количеству занятых разработкой ПО людей можно говорить о наличии целой индустрии разработки ПО. Некоторое ПО разрабатывается индивидуально, а некоторое в огромных организациях сотнями людей коллективно. Конечно, основной прирост этой численности дают не научные исследования, а разработка и использование ПО в организациях, производящих компьютеризированные системы, программные средства и информационные услуги. Дисциплина, которую мы будем изучать – инженерная дисциплина , направленная на производство реального программного продукта т.е. производственная дисциплина. Обучение программированию первоначально происходит(а иногда и ограничивается) путем программирования заданных примеров на определенных языках программирования. Затем изучаются ОС и БД. Существует большая разница между таким программированием и решением задач с использованием ПО, когда алгоритмов решения задач никто не задает и разработчику ПО самому требуется их найти, изучив или поняв предметную область, запрограммировать и убедиться , что выбранный алгоритм действительно решает поставленную задачу. НО разработка больших систем ПО предусматривает нечто большее, чем просто определение и программирование алгоритмов выполнения составляющих систему ПО задач . Требуется разработать схему взаимодействия компонентов ПО между собой в «пространстве и во времени» и добиться работоспособности этой схемы. При этом разработка такого ПО – это коллективный труд, что требует управления взаимодействием участников процесса разработки. Выпуска документов, обеспечивающих ясную ответственность каждого за выполненную работу и т. п. В результате трудности, возникающие при разработке большого ПО растут далеко не пропорционально увеличению его функциональности. Существует также большая разница между программированием «для себя» или программированием в небольших научно- исследовательских лабораториях или частных предприятиях и программированием «на заказ» по конкретным заказам в промышленности в больших коллективах, в которых в общем случае работают не «фанаты» этого дела. В таких коллективах приходится разделять ответственность за произведенный программный продукт, и здесь всегда есть люди, которые могут уволиться в любой самый неподходящий момент, и всегда есть люди просто не желающие или не могущие работать. Ситуация осложняется отсутствием взаимозаменяемости разработчиков ПО, так как для многих из них требуется специализация в предметной области и эти знания приобретаются в течении определенного времени. Ясно ,что в этом случае методы и средства разработки будут другими, чем в случае любительского программирования. Например, здесь без документирования программной продукции и процессов ее производства с фиксацией ответственности участников разработки не обойтись. Не обойтись и без координации работ разработчиков ПО путем подробного планирования работ и оперативного контроля их хода. Последнее приобретает определяющее значение, так как часто встречается ситуация ,когда после ежедневных докладов о выполнении всех планов следует предложение в конце месяца о необходимости перенесения сроков разработки. Здесь возникает проблема , как добиться наблюдаемости процесса разработки ПО? ПО не ракета и не корабль и не спутник и процесс производства не видим руководителями – нельзя подойти к стапелю и своими глазами увидеть состояние дел. Нужно создание системы контрольных точек и отчетных документов, делающих наблюдаемым разработку ПО. Инженерия ПО Программная инженерия – систематическое применение научных и технологических знаний, методов и практического опыта к проектированию, реализации, тестированию и документированию ПО в целях оптимизации его производства, поддержки и качества .(ISO/IEC 2382/1-93). В совокупности наук имеются «компьютерная наука»(computer science) - это скорее теоретическая наука. И есть прикладная область исследований, именуемая «инженерией ПО»(software ingenering), объединяющая достижения различных инженерных знаний в создании эффективных и безопасных систем ПО, в управлении проектами ПО и персоналом, в инженерном искусстве верификации и отработки принятых решений, создании хорошей документации и среды тестирования ПО. Можно сказать, что инженерия ПО состоит из двух частей : технологии разработки ПО и Надежность и качество ПО. Действительно, для реальной разработки ПО необходимы инженерные знания в области: характеристик качества ПО, стандартизованных в ГОСТ Р ИСО/МЭК 9126-93, методов их измерений и обеспечения., жизненного цикла ПО, трудоемкости разработки ПО и ее связей с характеристиками и сложностью ПО, планирования и оценки программного проекта, технологий в области проектирования алгоритмов и программ, проектирования архитектуры (структуры ПО и организации вычислительного процесса системной ЦВМ), организации корпоративной разработки ПО, технологий отладки ПО, технологической защиты ПО, необходимости и опасности проведения изменений ПО, причин типичных ошибок и методов их предупреждения и обнаружения. Эти знания базируются на теоретических основах различных инженерных наук и направлены на выполнение прежде всего практической работы по созданию реальных систем с требуемыми характеристиками в рамках временных и финансовых ограничений. Инженерный подход в любой разработке также подразумевает: -Получения подтверждения работоспособности в требуемых условиях , -Решения задачи безопасности и восстановления работоспособности при наличии неисправностей и отказов составляющих систему элементов. В свою очередь эта задача связана с контролем работоспособности системы и ПО и таким их конструированием ,чтобы имеющиеся отказы и неисправности не приводили к фатальному исходу, Производство программных средств отличается от традиционных промышленных производств тем, что основные усилия затрачиваются не на заводское тиражирование сконструированного изделия, в данном случае программу, а на непосредственное их проектирование и конструирование и, я бы хотел добавить, на испытания (отладку). Тогда как тиражирование программ - относительно простая операция. На долю программистов - разработчиков программ приходится не только относительно простая и рутинная работа по кодированию разработанных математических моделей и задач на соответствующий язык программирования, но и куда более сложная и творческая работа по постановке и формализации задач, которые необходимо решать на компьютере, по общению с теми людьми, кто хотел бы решать свои задачи на компьютере. При этом часто приходится выяснять, что же на самом деле хочет пользователь или заказчик и не всегда это происходит быстро. Сегодня ,когда мы говорим о формализации постановки задачи, мы имеем в виду процесс создания последовательных моделей, каждая из которых описывает систему с различных точек зрения с постепенной детализацией. Таким образом ,уточнение постановки задачи и алгоритма производится многократно – итерациями по мере осмысления и получения первых результатов. В результате этой формализации и этого общения осуществляется переход от описательной к точной математико-логической модели и точному алгоритму, так как языки программирования до сих пор требуют четкого и формального описания задачи. При этом сам русскоязычный термин «программное обеспечение» имеет некоторое системное значение и говорит о том, что программы нужны не сами по себе, а как средство, обеспечивающее решение некоторой задачи. Отметим, что определение - что и как должна делать программа требуют знаний в предметной области. Проблемы разработки ПО Какие проблемы сопровождают реальную разработку ПО. 1.ПО нужно много. Все большее количество людей вовлекается в процесс разработки. Создание эффективных ЯП не решает проблему, так как надежды на то, что ЯП решит все проблемы производительности при создании ПО не оправдались и прирост эффективности меньше прироста потребностей. Современный взгляд на эту проблему – повторное использование ранее разработанных программ и программных компонент, так как это делается в электронике. Все новые и новые изделия ЭТ создаются из имеющегося набора БИС. Конечно, это сопровождается развитием этих наборов. 2.Проблема сложности ПО. Нужно рассматривать два вида сложности: сложность устройства, проявляющаяся при разработке, и сложность поведения ,проявляющаяся при исполнении ПО. Пусть мы определились, что и как должно делать ПО в системе. Следующей задачей, возникающей при практической реализации разработки сложных программ, точно также как и при разработке других сложных творений рук человеческих, является задача их технологического членения, так как имеющиеся в распоряжении человека методы и инструменты не позволяют изготовлять сложную продукцию, в том числе и большие программы целиком и сразу. Чем больше и сложнее программное обеспечение, тем важнее разбить его на небольшие четко описанные части (структурировать). Это позволяет абстрагироваться от деталей реализации при проектировании ПО и при анализе его исполнения. Ни один человек не обладает интеллектом и возможностью охватить все детали большой компьютерной программы. Вместо попытки сделать это разработчики ПО должны попытаться сделать программы такими, чтобы можно было работать с частями программы поочередно. И отдельно представлять программу, как целое, не вникая в детали устройства частей. Структурирование ПО – разбиение его на доступные для понимания человеком части, вытекающее из методов структурного проектирования и объектно-ориентированного проектирования – основной метод борьбы со сложностью ПО. При технологическом членении необходимо решить не только из каких составных частей будет состоять изделие, как их изготовить, кто и где их будет изготавливать, но и как соединить затем разработанные части в единое целое причем в пространстве и во времени. Правильное технологическое членение – структуризация программы уменьшает сложность разработки; делает программу понятной разработчику и пользователю, упрощает проектирование, повышает надежность работы программы, уменьшает временные затраты на отладку программы и сроки разработки ПО в целом. В последнее время собственная сложность ПО усугубляется территориальным распределением ПО по различным хостам, усложняющим взаимодействие между частями ПО. Здесь необходимо использовать принцип и средства реализации прозрачности распределения ПО, который позволяет рассматривать распределенное ПО, как единое целое 3. Проблема борьбы с ошибками. В любой написанной достаточно сложной программе имеются ошибки. Эти ошибки, учитывая роль программного обеспечения, могут привести к тяжким экономическим последствиям вследствие аварии систем, использующих компьютеры, а также к катастрофам. Те грубые ошибки, которые не позволяют вообще программе работать, обнаруживаются сразу и сразу же устраняются и речь идёт не о них. Опасны ошибки, имеющие скрытый характер, проявляющиеся при определенных наборах исходных данных. Для их устранения необходимо проводить специальную работу, по их выявлению, локализации и устранению. Эта работа называется отладка, для её выполнения разрабатываются специальные средства-инструменты и технологии. Уменьшению количества первичных ошибок в программах способствует также приближение структуры ПО к структуре системы и сокращению семантического разрыва между задачами системы и их представлением в ПО. Использование объектно-ориентированного подхода к разра- ботке ПО сокращает семантический разрыв между предметной областью и ПО, уменьшает сложность ПО при его проектировании. Методы борьбы с ошибками ПО имеют еще два важнейших направления: конструирование ПО со свойствами устойчивости к ошибкам, связанные с автоматическим обнаружением ошибок и их обработкой, и проведение отладки ПО, которая требует создания эффективных и трудоемких инструментов. 4.Проблемы изменяемости ПО. При разработке ПО существует проблема его изменяемости. В настоящее время факт постоянного изменения и уточнения требований к ПО в процессе его разработки осознан, как нормальное и неизбежное условие создания и развития, а не как следствие неумения разработчиков или отсутствия у них четкой организации труда. Предусмотрение возможности безболезненных изменений это тот самый принцип, который отличает ПО от других видов промышленных продуктов, так как в большинстве случаев ПО разрабатывается в обстоятельствах, когда требования к нему недостаточно определены. Они уточняются по мере продвижения разработки системы и ПО для неё. Но способность ПО к развитию не возникает сама собой и не является следствием удачного стечения обстоятельств. Она требует определенных усилий, чтобы определить где и каким образом потребуется необходимость изменений, требует определенной стратегии структуризации ПО, так чтобы изменения были изолированы в особых частях ПО и не затрагивали остальные части при их проведении. Структуризация ПО, изолируя функциональные программные единицы, способствуют решению задачи внесения изменений в отдельно взятые фрагменты ПО, не затрагивая другие. Проведение изменений в ПО требует четкого планирования и четкой организации этого процесса. Тем не менее и в настоящее время изменения ПО, направленные на устранение ошибки не редко приводят к внесению в ПО дополнительных ошибок. Лекция2. Технология разработки ПО и качество ПО. Системный подход к разработке ПО. Жизненный цикл ПО. Технология разработки ПО и качество ПО Технология разработки – это набор методов, правил, организационных положений, .инструментальных средств , направленных на разработку , производство и сопровождение программного продукта, обладающего заданным качеством. Технология разработки ПО и качество ПО два основных вопроса рассматриваемых в программной инженерии. В определении присутствуют слова Качество программного продукции - это набор признаков и характеристик, которые характеризуют способность продукции удовлетворять установленные потребности. В инженерных дисциплинах потребности формулируются и устанавливаются документально. Поэтому качество ПО надо определять документально В настоящее время невозможно считать нормой поставку продукции низкого качества, недостатки которой нужно устранять в процессе эксплуатации. Для ПО это замечание весьма актуально, так как некоторые сторонники быстрых (agile )технологий разработки готовы поставлять первые версии ПО низкого качества с постепенным устранением выявленных недостатков в последующих версиях. Для критических систем проявление низкого качества ПО может привести к фатальному исходу до всех попыток исправить положение. Правда, сторонники agile технологий хорошо это осознают и понимают, что такие технологии не для критических систем. Чем определяется качество ПО и какие проблемы стоят на этом пути. На пути создания перечня характеристик качества ПО стоят: - трудности выбора единых характеристик для ПО различного назначения, - трудности выбора численной меры для этих характеристик, - не совпадение критериев разработчика и пользователя. Характеристики качества ПО Характеристик качества ПО придумано много, но не все они универсальны и применимы для любого ПО и не все они имеют численную меру. Иногда эти меры сложны в определении и измерении. В итоге процесс управления качеством ПО состоит из 5 шагов: -Определение критериев качества ПО и их мер. -Определение потребного уровня значений, выбранных критериев качества. -Определение методической базы измерения критериев качества. -Обеспечение качества ПО как множества процедур и стандартов и их адаптация для конкретного случая разработки ПО. -Периодическое измерение качества ПО - проведение процедур контроля качества. Текущий контроль качества ПО, который гарантирует выполнение всеми участниками разработки выбранных стандартов и правильной технологии разработки ПО. С помощью процессов верификации необходимо оценивать текущие характеристики качества ПО и отдельных артефактов процесса разработки и сопоставлять их с критериями и правилами, определенными в рамках системы обеспечения качества проекта. С технической точки зрения верификация является неотъемлемыми элементами деятельности по обеспечению качества. Несмотря на огромное разнообразие программных продуктов, производимых в настоящее время и соответственно огромное количество критериев качества для них, удалось выделить некоторое количество базовых критериев качества ПО, которое легло в основу международного стандарта ИСО/МЭК 9126-92 «характеристики качества ПО» . Качество ПО в соответствии с этим стандартом оценивается шестью базовыми характеристиками: -функциональные возможности, -надежность, -эффективность, -практичность, -сопровождаемость, -мобильность или переносимость на другую аппаратную платформу или в другое программное окружение прежде всего ОС. Данный набор базовых критериев качества не лишен недостатков. Например, в нем явно не хватает характеристик безопасности ПО. Безопасность ПО и безотказность его(надежность) это не одно и то же. Всех интересует вопрос, что следует за отказом ПО. Конечно, ПО бывает очень различным .Отказ ПО, управляющего полетом ракеты, самолета, химической установки ,медицинского оборудования определенного вида это всегда большой ущерб - большие экономические потери, необратимый ущерб экологии и жизни людей . Отказ ПО ,обеспечивающего информационно справочные службы, неприятен, но не несет большого и не обратимого ущерба. Факторы, влияющие на качество ПО Изучение опыта создания ПО различного назначения и масштаба во многих странах показало, во первых ,наличие значительного числа провалов в этом вопросе и, во вторых , что разработ- ка ПО должна проводится не по интуиции или вдохновению т. е. быть не искусством, а достаточно формализованным процессом, который можно изучать ,воспроизводить и управление которым можно совершенствовать. Одна из причин распространенности хаотического процесса создания ПО - стремление сэкономить на стадиях проектирования и отладки жизненного цикла. Технология разработки ПО оказывает значительное влияние на его качество. Технология разработки ПО Качество ПО Человеческий фактор: -Ошибки - несоблюдение установленных правил Выделенные ресурсы и график работ Вообще считается, что если ПО произведено по правильной технологии, прошло все предусмотренные ею этапы проектирования и отладки, то это ПО – качественное. На рис приведена укрупненная схема влияющих на качество ПО факторов. С влиянием человеческого фактора все ясно – человеку свойственно ошибаться в том числе не выполнять установленные предписания и правила. Качество ПО также пострадает ,если для его разработки не будут выделены необходимые ресурсы в частности для закупки или создания необходимых инструментальных средств Качество ПО пострадает ,если график проведения работ будет выделять мало времени на жизненно важные этапы работ, комкая их, не будет предусматривать выпуск необходимых документов. Качество ПО не будет обеспечено, если будет нарушена технология разработки, пропущены и не выполнены важные этапы , не выпущены необходимые документы Таким образом, разработка ПО требует трех знаний: знаний в предметной области, знаний в области программирования, знаний в области технологии разработки ПО. Технология разработки ПО, как дисциплина, развивает подходы, методы и инструменты, следуя которым средний разработчик ПО, не будучи исключительно талантливым, может создать работоспособное и качественное ПО, работоспособную и качественную систему. Безопасность для ПО «критических систем» - ограничение ущерба, наступающего после отказа ПО, должна быть обеспечена не только технологией разработки ПО, но и конструкцией самого ПО путем организации в нем фрагментов «аварийной защиты». Изучению сквозной технологии разработки ПО: проектированию ПО, его разработке, отладке и эксплуатации посвящен настоящий курс. Собственно методы написания кодов, исполняемые на ЦВМ, изучаются в соответствующих курсах программирования. Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода При рассмотрении технологии разработки ПО мы будем придерживаться системного подхода, который предполагает рассмотрение не каких-то отдельных аспектов проблемы разработки ПО, а проблемы в целом. Системный подход реализуется в «пространстве» и во времени. Системный подход во времени рассматривается от момента формирования неудовлетворенной потребности в ПО до момента её разрешения. Системный подход в "пространстве" предусматривает рассмотрение разрабатываемого ПО, программы, модуля или объекта, как части системы. При этом на базе изучения информационных потребностей системы, в которую будет входить разрабатываемое ПО, формулируются цели и набор функций ПО, анализируются прототипы программных средств. Формируются и документируются требования к ПО. Современная технология разработки ПО рассматривает программирование - создание программного кода для ЭВМ, как один из этапов разработки в цепи последовательных этапов цикла разработки. Все эти этапы объединяются понятием жизненный цикл ПО и должны быть поддержаны соответствующими инструментальными программными и аппаратными средствами. Изучению принципов построения этих средств, последовательности и содержания технологических этапов разработки ПО - цель курса. Термин разработка включает в себя новую разработку, модификацию, повторное использование, перепрограммирование или любое другое действие, направленное на создание программного продукта. Этапы жизненного цикла ПО. Каскадная модель жизненного цикла ПО. Понятие жизненный цикл является отражением системного подхода к разработке ПО. В соответствии с международным стандартом ISO /IEC 12207 «информационные технологии – Процессы жизненного цикла ПО»., стандартом США MILSTD-498 “Разработка ПО …”, российских стандартов ГОСТ 19.102-77 (ЕСПД) процесс разработки ПО содержит следующие этапы жизненного цикла ПО: 1) анализ системных требований и области применения; 2) проектирование архитектуры системы; 3)анализ требований к ПО(спецификации, внешние интерфейсы, требований к квалификации); 4) проектирование архитектуры ПО; 5) детальное проектирование каждой единицы ПО; 6) кодирование ПО (программирование) 7) тестирование единиц ПО; 8) интеграция (объединение ПО) и тестирование совокупности единиц ПО; 9) квалификационные испытания ПО (комплексное тестирование); 10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств; 11) квалификационные испытания системы; 12) установка ПО. Таким образом, процесс разработки ПО имеет свое начало от системы, где это ПО будет использовано и завершается опять в системе. После этапов разработки в жизненном цикле ПО следует этап эксплуатации ПО и его сопровождения при эксплуатации. Иногда перечень этапов жизненного цикла ПО приводится с некоторыми обобщениями (укрупнениями) приведенных 12 этапов. Например, этапы проектирования системы и определение требований к ПО, проектирования программного комплекса, проектирования алгоритмов и ПО, программирования (кодирования), автономной отладки ПО, комплексной отладки ПО, эксплуатации ПО. Данная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки системные требования хорошо проработаны и возможно полно и точно сформулировать все требования к ПО. Однако, реальный процесс создания ПО не всегда укладывается в такую жесткую последовательную схему и часто возникает необходимость возврата к уже пройденным этапам с уточнением или пересмотром уже принятых прежде всего системных решений из за изменений требований заказчика, изменений в аппаратуре, обнаружения принципиальных ошибок. Каскадную модель, конечно, можно к этому приспособить, но лучше с самого начала для ПО такого типа рассматривать модель жизненного цикла,«заточенную» под быстрые итерации для получения недостающих требований к ПО. Лекция 3. Основные, вспомогательные и организационные процессы создания ПО. Жизненный цикл ПО и процессы верификации. Спиральная модель ЖЦ ПО. «Тяжелые и быстрые» технологии разработки ПО. Три группы процессов создания ПО Вслед за стандартом ГОСТ Р ИСО/МЭК 12207 разделим все процессы создания ПО на три группы: основные, вспомогательные и организационные. Группа основных процессов включает в себя процессы: -приобретения(заказа) – работы, действия и задачи заказчика, приобретающего программное средство, связанные с формулированием требований к нему, выбору поставщика, проведению договорной работы и т.п. - поставки – работы, действия и задачи поставщика , снабжающего заказчика программным продуктом путем принятия решения о разработке ПО своими силами или с привлечением субподрядчика, определения ресурсов и т.п. -разработки – работы, действия и задачи разработчика программного продукта в соответствии с уже рассмотренными этапами жизненного цикла ПО, -эксплуатации – работы, действия и задачи оператора, осуществляющего эксплуатацию ПО в соответствии с эксплуатационной документацией по вводу системы в эксплуатацию, порядку разрешения возникающих проблем, непосредственно эксплуатации, - сопровождения – действия и задачи, выполняемые сопровождающей организацией или разработчиком ПО, если он имеет соответствующие обязательства, по модификации ПО, разрешению возникающих проблем, по переводу ПО в новую аппаратную среду. Мы отметили всех «игроков», участвующих в процессе создания и использования ПО. В ряде конкретных случаев, рассмотренные роли и задачи могут совмещаться, например, поставщик, разработчик, сопровождающая организация могут быть одним и тем же юридическим или даже физическим лицом. Однако, все описанные функции и задачи при таком структурированном подходе к процессам разработки сохраняются и в этом случае. Группа вспомогательных процессов включает в себя процессы, обеспечивающие выполнение основных процессов: -документирования – набору работ и действий, с помощью которых планируют, выпускают, редактируют, сопровождают документы, необходимые для всех перечисленных ранее заинтересованных лиц, участвующих в создании ПО, -управления конфигурацией- применение административных и технических процедур для определения состояния компонентов ПО в системе и для управления модификациями, -обеспечения качества ПО о чем говорилось выше,