Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
ПО — совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ
процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов.
процесс разработки:
Совершенствование процесса (software process improvement) – это деятельность по изменению существующего процесса с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки.
Причины: 1) смена технологии разработки, 2) конкуренция, 3) рост компаний, как достигается: 1) переход на новые средства разработки, 2) перестройка процессов в компании, 3) сертификация
Пример: 1) Переход на новые средства разработки, языки программирования и т.д.; 2)Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр.; 3) Полная, комплексная перестройка всех процессов в проекте, департаменте, компании; 4) Сертификация компании
Organization pull – инновации нацелены на решение конкретных проблем компании.
Technology push – широкомасштабное внедрение инноваций из стратегических соображений
Organ. – изменения на одном уровне (изменения локальны, менее рискованно), tech. – изменение на одну ступень выше, переход на новый рубеж (измения глоабльны, сложно вносимы).
Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат.
Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО.
Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование
«+» - ограничение возможности возвратов на произвольный шаг назад
«+» - прототипирование - разрабатывать систему дважды, чтобы уменьшить риски разработки.
«-» - отождествление фаз и видов деятельности, что влечет потерю гибкости разработки
«-» - требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа
«-» -интеграция в конце, интеграционные проблемы дают о себе знать поздно
«-» - пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; поэтому непонимание пользователей\заказчиков с разработчиками
«-» - модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств
Бэри Боемом в 1988г
Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. Виток это фаза, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной.
Каждый виток имеет следующую структуру (секторы):
•определение целей, ограничений и альтернатив проекта;
•оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
•разработка и тестирование
•планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно.
Нецелесообразное применение при небольшой степенью риска, с ограниченным бюджетом, для небольших проектов.
“Архитектура — это фундаментальная организация системы, воплощенная в компонентах, их взаимосвязях, среде, и принципах, управляющих их дизайном и эволюцией.”
Функциональное требование — это требование к системе/программному приложению, которое должно выполняться соответствующим компонентом. Это требования, которые определяют поведение и действия системы, составляющие фундаментальный процесс или преобразования, которые программные и аппаратные компоненты системы производят над входными данными для получения выходных данных.
Нефункциональное требование — это требование к программному обеспечению, которое описывает не то что делает программа, но как программа выполняет функции. Например производительность ПО, требования к внешним интерфейсам,
Строить так чтобы затем изменять: как приложение может изменяться с течением времени чтобы удовлетворять новым требованиям
Моделировать чтобы анализировать и уменьшить риск.
Использование моделей и визуализаций в качестве средства коммуникации и сотрудничества: Эффективное обсуждение дизайна, принимаемых решений и предстоящих изменений дизайна критично для построения хорошей архитектуры.
Определение ключевых инженерных решений: Необходимо определить и понимать какие ключевые решения используются и области наиболее вероятного возникновения ошибок.
Языки описания архитектуры
Языки описания архитектуры Architecture description languages (ADLs) используются для описания Архитектуры ПО.
Представления (Views): Архитектура ПО организована в виде представлений (views), что является аналогом калек используемых в строительной архитектуре. Примеры: Функциональное /Логическое представление, структурное;
Поялние было связано с кризисом в программировании в 60-х – начале 70-х годов прошлого века.
Фазы: проектирования, изготовления образца, организация производства, серийное производство, эксплуатация, ремонт, вывод из эксплуатации
Проблемы практического применени:
Жизненный цикл программного продукта (software life cycle) – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Программный продукт (software product) – набор машинных программ, процедур и, возможно, связанных с ними документации и данных.
Процесс (process) – набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты.
Процессы ЖЦ
Управления. Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.
Создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.
Усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.
Обучения. Определяет работы по соответствующему обучению персонала.
Приобретение Процесс приобретения определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений.
Поставка Процесс поставки, в свою очередь, определяет работы и задачи поставщика
Разработка Процесс разработки определяет работы и задачи разработчика
Эксплуатация Процесс разработки определяет работы и задачи оператора службы поддержки
Сопровождение Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения.
Ме́трика ПО - мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Метрики позволяют измерить сложность ПО. Введены для решения следующих задач:
Размерно-ориентированные метрики базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, количество строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ. Поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки.
Критика (недостатки):
1) некрасиво и неправильно сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности.
2) Метрика не учитывает опыт сотрудников и их другие качества
3) Искажение: процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу.
4) Неточность: нет метрик, которые были бы одновременно и значимы и достаточно точны.
Основан на анализе управляющего графа программы
Виды оценок:
цикломатическая сложность программы. данная оценка не способна различать циклические и условные конструкции. «-» - программы, представленные одними и теми же графами, могут иметь совершенно разные по сложности предикаты
метод Хансена. Мера сложности программы представляется в виде пары (цикломатическая сложность, число операторов). Преимуществом данной меры является ее чувствительность к структурированности ПО.
Существует метрика Шнейдевинда, выражающаяся через число возможных путей в управляющем графе.
Метрика Чепина: суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Метрика спена основывается на локализации обращений к данным внутри каждой программной секции. Спен - это число утверждений, содержащих данный идентификатор, между его первым и последним появлением в тексте программы.
метрика, связывающая сложность программ с обращениями к глобальным переменным.
Эти метрики позволяют получить оценку сложности объектно-ориентированных проектов.
1) Взвешенная насыщенность класса 1: Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются.
2) Взвешенная насыщенность класса 2: Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
3) Глубина дерева наследования: Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
4) Количество детей: Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции.
5) Связность объектов: Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
6) Отклик на класс: Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов.
Необходимо создать набор документов, который должен содержать, как минимум, требования, спецификации, дизайн, модели (чертежи), перечень компонентов, тестовую документацию, исходные коды и документацию пользователя. Требовалось общее выражение для обозначения любого из этих документов или всех документов, описывающих конфигурационный объект, для проекта любого размера. Так как основное предназначение этих документов было в «идентификации конфигурации» объекта, этот набор документов назвали «конфигурационной идентификацией».
Управление конфигурацией является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом.
Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо
Конфигурационное управление имеет дело с меняющимися в процессе разработки продуктами, состоящими из наборов файлов.
Такие продукты называются единицами конфигурационного управления: пользовательская документация; проектная документация; исходные тексты ПО; пакеты тестов; инсталляционные пакеты ПО; тестовые отчеты.
Структура – набор файлов. Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении .
Ответственное лицо или группу лиц, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией.
Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии.
Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ
Сборка – это единица повторного использования кода, в которой поддерживается система управления версиями и заложена система управления безопасности программного обеспечения. Сборка представляет собой набор файлов, модулей и дополнительной информации, которые должны обеспечить простую установку приложения и последующую работу.
Причиной появления понятия сборки можно считать трудности установки Windows-приложений. Обычное Windows-приложение состоит из множества файлов - запускаемые модули, библиотеки, дополнительные файлы и т.п. Многие приложения использовали разделяемые DLL, что зачастую приводило к проблемам при установке более новых версий этой DLL.
Манифест сборки: Данные о версии сборки (идентификационные данные); Список файлов, входящих в сборку; Список сборок, на которые имеются ссылки; Набор требуемых полномочий доступа к сборке; Экспортируемые типы.
Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования.
Процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continues integration) – то есть регулярной сборке всего проекта (как правило – каждую ночь).
Приватные сборки (библиотеки) поставляются с самим приложением, используются только им и храниться в его каталоге.
Локальные сборки видны только самому приложению и никому более, т.е. приложение изолируется от внешнего воздействия, как других программ, так и самой операционной системы.
Концепция приватных сборок сильно упрощает развёртывание (инсталляцию) приложений.
Приватная сборка должна иметь строгое имя: Имя самой сборки; Номер версии (позволяется одновременно использоваться разные версии одной и той же сборки); Открытый ключ (позволяет делать строгое имя уникальным и исключает вероятность подмены сборки); Культурные и региональные настройки
Разделяемые сборки хранятся в глобальном кэше сборок; Сборки, хранящиеся там, используются многими приложениями; Хранилище сборок располагается в каталоге <windir>assembly; В каталоге GAC (Global Assembly Cashe) есть подкаталоги, представляющие каждую сборку, в которых хранятся директории, разбивающие данную сборку по версиям. Таким образом, на компьютере может храниться любое количество версий одной и той же сборки.
Разделяемые сборки хранятся в глобальном кэше сборок; Сборки, хранящиеся там, используются многими приложениями; Хранилище сборок располагается в каталоге <windir>assembly; В каталоге GAC (Global Assembly Cashe) есть подкаталоги, представляющие каждую сборку, в которых хранятся директории, разбивающие данную сборку по версиям. Таким образом, на компьютере может храниться любое количество версий одной и той же сборки.
Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д.
Принятие такой версии сопровождается дополнительными действиями по оформлению, сглаживанию, тестированию, включению только законченных фрагментов и т.д. Этот результат можно посмотреть, отдать тестировщикам, передать заказчику и т.д. Baseline служит хорошим средством синхронизации групповой работы.
Качество ПО определяется как весь объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям.
Характеристики:
Обеспечение качества - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта.
Технические методы: использование систем управления дефектами, внедрение автоматизированного тестирования, внедрение модульного (unit) тестирования, использование современных интегрированных сред разработки, использование валидаторов кода, внедрение систем версионного контроля.
Организационные методы: планирование работ и затрат, оценка проектных рисков, проведение статусных митингов, проведение сессий Lessons Learnt, проведение Casual Analysis, введение метрик.
Тестирование – это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами и на оценку свойств ПО.
Цель тестирования – поиск дефектов в программе.
Функциональное тестирование – это тестирование заявленных (задокументированных) функциональных возможностей программы. Цель данного тестирования – поиск дефектов, связанных с выполнением непосредственных функций программы (неправильное взятие программой-калькулятором корня от числа).
Тестирование практичности - поиск возможных проблем при использовании программы и относящихся к удобству пользования и предоставления заявленных функциональных возможностей (близко расположенные маленькие кнопки программы-калькулятора, расположение которых приводит к тому, что часто нажимается не та цифра).
Тестирование безопасности – выявление уязвимостей, которые могут приводить к неправомерному или нецелевому использованию программы (уязвимости в интернет-браузерах, позволяющие злоумышленникам получать контроль над компьютером пользователя).
Тестирование производительности - выявление проблем производительности программы. Данное тестирование оценивает затраты программы на выполнение заявленных функций, а также проверяет поведение программы при работе с верхними пределами входных значений (стократное увеличение времени вычислений при выполнение операции взятия корня над двузначными числами в программе-калькуляторе).
Нагрузочное тестирование направлено на определение пороговых значений входных данных и поиска дефектов в программе при обработке пиковых нагрузок (проверка того, что содержимое базы данных не повреждается при превышение количества подключений к ней и аварийном завершении программы).
Глобализационное тестирование – выявление дефектов, связанных с региональными отличиями в программном обеспечении (как будет вести себя программа при использовании на компьютере с американскими региональными настройками): дефект, связанный с некорректной обработкой чисел с плавающей запятой: в России в качестве разделительного знака используется запятая, а, например, в США – точка.
Локализационное тестирование - поиск дефектов, возникших при локализации программного продукта (ошибки, допущенные во время перевода; проблемы, связанные с отображением национальных символов).
Тестирование доступности проводится для определения проблем в работе людей с ограниченными возможностями с программой. Дефектом, обнаруженном при данном виде тестирования являются некорректные цвета интерфейса, приводящие к тому, что человек, страдающий дальтонизмом, не в состоянии прочитать текст.
1) Insourcing. Стандартная компания имеет две команды: разработки и тестирования. Тестирование проводится собственными силами компании. Основной товар на рынке тестирования: инструментарий тестирования.
2) Outsourcing. Стандартная организация компании: внутренняя команда разработки и внешняя команда тестирования, представленная сторонней компанией.
Основной товар на рынке тестирования: команды тестирования с их собственным процессом тестирования.
3) Crowdsourcing. Тестирование проводится множеством независимых тестировщиков, расположенных по всему миру. Каждый из тестировщиков владеет собственными инструментами тестирования и располагает определенными платформами для тестирования.
Основной товар на рынке тестирования: тестировщик и имеющиеся в его распоряжении инструменты и платформы.
4) Testsourcing. Схожие задачи тестирования уже решались кем-либо до нас. Возможность создания универсальных тест кейсов (в виде ручных или автоматизированных тестов) обеспечивает существование данного поколения. Предполагается, что универсальные тесты могут быть использованы при тестировании различных программных продуктов.
Основной товар на рынке тестирования: универсальные тесты.
В зависимости от знания системы выделяют эти виды тестирования.
В случае с черным ящиком вся система представляется в виде черного ящика, о внутреннем устройстве которого ничего неизвестно. В случае с белым ящиком тестировщик имеет возможность анализировать код и внутреннюю логику программы. Тестирование серого ящика находится в пограничном состоянии между белым ящиком и черным: снаружи на продукт смотрим как на черный ящик, но выбор тестов основываем на знании внутреннего устройства программы, знании ее кода (тестирование web приложений).
Дефект – это ошибка в программного обеспечении, приводящая к отказу в нем.
Критичность дефектов:
1) Блокирующая - блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
2) Критическая - критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
3) Значительная - значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
4) Незначительная - незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
5) Тривиальная - тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
ЖЦ дефекта:
Тестировщик обнаруживает дефект и заводит его в системе учета дефектов. В этот момент дефект находится в состоянии Submitted. После этого назначается человек, ответственный за исправление этого дефекта, и дефект переводится в состояние Assigned. Ответственный человек либо исправляет дефект и переводит его в состояние Resolved, либо отклоняет дефект (признает данную ситуацию нормальной или уже исправленной) и переводит дефект в состояние Rejected. Далее человек, который завел дефект проверяет правильность исправления и либо закрывает дефект (состояние Closed), либо переоткрывает его (состояние Re-Opened).
Cистемы отслеживания дефектов - прикладная программа, разработанная с целью помочь разработчикам программного обеспечения учитывать и контролировать ошибки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий. При описании дефекта тестировщик заполняет определенные поля.
Свободно распространяемые: Redmine, BUGS - the Bug Genie, Bugzilla, GNATS, Mantis, Flyspray
Проприетарные: Atlassian JIRA, Bontq, PVCS Tracker, Project Kaiser, TrackStudio Enterprise
Требования к программному обеспечению – совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
Виды требований по уровням:
Customer Requirements – набор требований, предпочтений и ограничений со стороны заказчика.
Product Requirements – структурированный набор функциональных и нефункциональных требований к системе. Должны быть полными, непротиворечивым и проверяемыми.
Component Requirements – требования к логической и физической структуре системы, ее отдельным компонентам.
Методы выявления требований: 1)Интервью, опросы, анкетирование; 2)Мозговой штурм, семинар; 3)Наблюдение за производственной деятельностью, рабочего дня; 4)Анализ нормативной документации; 5) Анализ моделей деятельности; 6)Анализ конкурентных продуктов; 7)Анализ статистики использования предыдущих версий системы.
Управление требованиями – процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц.
Управление требованиями – непрерывный процесс на протяжении всего проекта.
Цель управления требованиями: гарантировать что организация документирует, проверяет и удовлетворяет потребности и ожидания заказчика.
Управление требованиями включает: выявления и анализа целей и ограничений заказчика; поддержку требований; интеграцию требований; организацию работы с требованиями.
Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта. Требования не являются чем-то постоянным. В процессе жизненного цикла ПО требования могут меняться. Изменения в требованиях должны отслеживаться.
Технические средства управления требованиями: IBM Rational RequisitePro; Borland CaliberRM; Sybase PowerDesigner.