Инструментальные средства разработки программного обеспечения (ИСРПО)

Содержание

Слайд 2

Сущность ИСРПО Инструментальное программное обеспечение — программное обеспечение, предназначенное для использования

Сущность ИСРПО

Инструментальное программное обеспечение — программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения

программ, в отличие от прикладного и системного программного обеспечения.
Слайд 3

Процессы и модели жизненного цикла информационных систем В соответствии с ГОСТ

Процессы и модели жизненного цикла информационных систем

В соответствии с ГОСТ

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

Основные процессы жизненного цикла Процесс заказа. Определяет работы заказчика, то есть

Основные процессы жизненного цикла
Процесс заказа. Определяет работы заказчика, то есть организации,

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

Вспомогательные процессы ЖЦ 1) Процесс документирования. Определяет работы по описанию информации,

Вспомогательные процессы ЖЦ

1) Процесс документирования. Определяет работы по описанию информации, выдаваемой

в процессе жизненного цикла.
2) Процесс управления конфигурацией. Определяет работы по управлению конфигурацией.
3) Процесс обеспечения качества. Определяет работы по объективному обеспечению того, чтобы программные продукты и процессы соответствовали требованиям, установленным для них, и реализовывались в рамках утвержденных планов. Совместные анализы, аудиторские проверки, верификация и аттестация могут использоваться в качестве методов обеспечения качества.
4) Процесс верификации. Определяет работы (заказчика, поставщика или независимой стороны) по верификации программных продуктов по мере реализации программного проекта.
5) Процесс аттестации. Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.
Слайд 6

Вспомогательные процессы жизненного цикла 6) Процесс совместного анализа. Определяет работы по

Вспомогательные процессы жизненного цикла

6) Процесс совместного анализа. Определяет работы по оценке

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

Организационные процессы жизненного цикла 1) Процесс управления. Определяет основные работы по

Организационные процессы жизненного цикла

1) Процесс управления. Определяет основные работы по

управлению, включая управление проектом, при реализации процессов жизненного цикла.
2) Процесс создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.
3) Процесс усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.
4) Процесс обучения. Определяет работы по соответствующему обучению персонала.
Слайд 8

Области знаний в сфере программной инженерии (SWEBOK) SWEBOK (Software Engineering Body

Области знаний в сфере программной инженерии (SWEBOK)

SWEBOK (Software Engineering Body of Knowledge) —

международный стандарт ISO/IEC TR 19759 от 2015 г., в котором описана общепринятая сумма знаний по программной инженерии.
Текущая опубликованная версия SWEBOK V3 включает 15 областей знаний в сфере программной инженерии:
software requirements — требования к ПО;
software design — проектирование ПО;
software construction — конструирование ПО;
software testing — тестирование ПО;
software maintenance — сопровождение ПО;
software configuration management — управление конфигурацией;
Слайд 9

Области знаний в сфере программной инженерии (SWEBOK) software engineering management —

Области знаний в сфере программной инженерии (SWEBOK)

software engineering management — управление IT

проектом;
software engineering process — процесс программной инженерии;
software engineering models and methods — модели и методы разработки;
software quality — качество ПО;
software engineering professional practice — описание критериев профессионализма и компетентности;
software engineering economics — экономические аспекты разработки ПО;
computing foundations — основы вычислительных технологий, применимых в разработке ПО;
mathematical foundations — базовые математические концепции и понятия, применимые в разработке ПО;
engineering foundations — основы инженерной деятельности.
Слайд 10

ITIL (IT Infrastructure Library) ITIL - библиотека инфраструктуры информационных технологий. Сегодня

ITIL (IT Infrastructure Library)

ITIL - библиотека инфраструктуры информационных технологий.
Сегодня это уже не

аббревиатура, а отдельное название или бренд, используемой и пользующейся доверием миллионов людей во всем мире. По мере развития библиотеки инфраструктуры ИТ, акцент сместился на управление услугами и к подходу к жизненному циклу, а элемент инфраструктуры практически исчез за последние 10 лет.) — самое распространенное в мире руководство по управлению ИТ-услугами (ITSM)
ITIL может помочь отдельным лицам и организациям использовать ИТ для реализации изменений, трансформации и роста бизнеса.
Слайд 11

Практики общего управления (ITIL) Управление архитектурой Постоянное улучшение Управление информационной безопасностью

Практики общего управления (ITIL)

Управление архитектурой Постоянное улучшение
Управление информационной безопасностью Управление знаниями
Измерение

и отчетность Управление организационными изменениями
Управление портфелем Управление проектами
Управление отношениями Управление рисками
Управление финансами для услуг Управление стратегией
Управления поставщиками Управление рабочей силой и талантами
Слайд 12

Практики управления услугами (ITIL) Управление доступностью Бизнес-анализ Управление мощностями и производительностью

Практики управления услугами (ITIL)

Управление доступностью Бизнес-анализ
Управление мощностями и производительностью
Управление инцидентами Управление ИТ активами
Мониторинг

и управление событиями Управление проблемами
Управление релизом Управление каталогом услуг
Управление конфигурациями услуг Управление непрерывностью услуг
Проектирование услуг Управление уровнем услуг
Управление запросами на обслуживание
Подтверждение и тестирование услуг Контроль изменений
Слайд 13

Актуальность соответствия международным стандартам повышение качества обслуживания и удовлетворенности клиентов (67%)

Актуальность соответствия международным стандартам

повышение качества обслуживания и удовлетворенности клиентов (67%)
поддержание ИТ-систем

в актуальном состоянии посредством постоянного улучшения (57%).
создание более стабильной среды обслуживания для поддержки изменений в бизнесе (53%).
обеспечение более эффективного управления бизнес-рисками, перебоями в обслуживании или отказами (51%).
большая прозрачность затрат и активов в области ИТ (44%)
сокращение расходов за счет более эффективного использования ресурсов (43%).
Слайд 14

Прочие стандарты. COBIT COBIT - пакет открытых документов, около 40 международных

Прочие стандарты. COBIT

COBIT - пакет открытых документов, около 40 международных и

национальных стандартов и руководств в области управления IT, аудита IT-безопасности, основанных на анализе и гармонизации существующих стандартов и ведущих практик в области управления IT.
Управление IT по COBIT можно представить в следующем ступенчатом виде (по порядку реализации):
Стратегии (выстраивание IT-процесса по бизнес-целям, постановка задачи, цели и создание концепции IT-процесса; ответственные: руководство бизнес-подразделений).
Политики (методы достижения целей в рамках стратегий, например: «длина пароля регламентируется»; ответственные: руководство IT-подразделений).
Стандарты (метрики для политик-методов, например: «длина пароля должна составлять не менее 8 символов»; ответственные: руководство IT-подразделений).
Процедуры (регламенты работ для применения политик-методов с использованием стандартов-метрик, рабочие инструкции для исполнителей; ответственные: руководство IT-подразделений).
Слайд 15

Прочие стандарты. ISO 20000 ISO 20000 — международный стандарт для управления

Прочие стандарты. ISO 20000

ISO 20000 — международный стандарт для управления и обслуживания IT-сервисов.
Процессы предоставления

сервисов (Service delivery process): в группу входят управление уровнем сервисов, управление непрерывностью и доступностью, управление мощностями, отчётность по предоставлению сервисов, управление информационной безопасностью, бюджетирование и учёт затрат.
Процессы управления взаимодействием (Relationship processes): эта область включает в себя управление взаимодействием с бизнесом, управление поставщиками.
Процессы разрешения (Resolution processes): разработчики стандарта фокусируются на инцидентах, которые удалось предотвратить или успешно разрешить – управление проблемами, управление инцидентами.
Процессы контроля (Control processes): в данном разделе рассматриваются процессы управления изменениями и конфигурациями.
Процессы управления релизами (Release process): речь идёт о выработке новых и коррекции уже имеющихся решений.
Слайд 16

Как управлять качеством ПО? Проектирование программных средств сопровождается анализом взаимодействия факторов,

Как управлять качеством ПО?

Проектирование программных средств сопровождается анализом взаимодействия факторов, влияющих

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

Качество ПО

Качество ПО

Слайд 18

Категории показателей качества программного обеспечения 1) Анализ надежности ПО, дающая возможность

Категории показателей качества программного обеспечения

1) Анализ надежности ПО, дающая возможность анализировать

ситуации отказов и прогнозировать их.
2) Анализ языковых средств, их уровня и использования.
3) Анализ производительности ПО, в том числе, путем определения ошибок реализации, с дальнейшим повышением ее эффективности.
4) Анализ сложности ПО, в том числе, информационной и топологической.
5) Анализ сложности восприятия ПО, в том числе, когнитивной эргономичности, имеющей в основании психологические особенности восприятия информации человеком, результаты которого имеют ценность на этапе разработки, проектирования, а также внесения изменений и сопровождения ПО.
6) Анализ труда разработчика, необходимый для технико-экономического обоснования проекта по разработке ПО, а также для прогнозирования сроков всего проекта и отдельно составляющих его этапов.
Слайд 19

СИСТЕМЫ ПРОГРАММИРОВАНИЯ ассемблеры; трансляторы; компоновщики; отладчики; текстовые редакторы; библиотеки подпрограмм; редакторы

СИСТЕМЫ ПРОГРАММИРОВАНИЯ

ассемблеры;
трансляторы;
компоновщики;
отладчики;
текстовые редакторы;
библиотеки подпрограмм;
редакторы графического интерфейса;
средства автоматизации разработки программ (CASE-средства)
Перечисленные инструменты

могут входить в состав интегрированных сред разработки
Слайд 20

ВИДЫ ИНСТРУМЕНТАЛЬНОГО ПО Интегрированные среды разработки Компиляторы и кросс-компиляторы Интерпретаторы Линковщики

ВИДЫ ИНСТРУМЕНТАЛЬНОГО ПО

Интегрированные среды разработки
Компиляторы и кросс-компиляторы
Интерпретаторы Линковщики
Парсеры и генераторы парсеров Профилировщики
Генераторы документации
Средства анализа покрытия кода Средства непрерывной интеграции
Средства автоматизированного

тестирования
Системы управления версиями
Системы управления проектами Системы отслеживания ошибок
Слайд 21

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) CASE-средства (от Computer

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

CASE-средства (от Computer Aided

Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций.
Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.
Слайд 22

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) IBM Rational Rose

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

IBM Rational Rose Rational

Rose - современное и мощное средство анализа, моделирования и разработки программных систем. Rational Rose пригодится при решении практически любых задач проектирования информационных систем: от анализа бизнес-процессов докодогенерации на определенном языке программирования. Такой арсенал позволит не только спроектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.
Borland Together - это интегрированная платформа разработки, позволяющая упростить и ускорить анализ, дизайн, разработку и развертывание комплексных корпоративных приложений. Эти возможности сочетаются в одном интегрированном решении с поддержкой UML, помогающем командно разрабатывать высококачественные системы быстрее и эффективнее.
Слайд 23

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) Sparx Systems Enterprise

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

Sparx Systems Enterprise Architect

Как уверяют разработчики (Sparx Systems), Enterprise Architect - это программа для UML-моделирования и проектирования нового поколения.
С EA отлично интегрируется другой продукт Sparx Systems - Zicom Mentor. И пусть это пакет не для UML-проектирования! Zicom Mentor - это ПО для обучения UML, который поможет вам мгновенно получить ответы на свои вопросы, получить и проверить знание UML, начать новый UML-проект.
Слайд 24

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) Gentleware Poseidon Poseidon

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

Gentleware Poseidon Poseidon for

UML - это популярное CASE-средство для UML-моделирования. Poseidon берет свое начало из открытого проекта ArgoUML (который также был весьма неплох и удобен в работе) и в наши дни уже является признанным профессионалами пакетом. На данный момент сформировалось быстро развивающееся сообщество пользователей, которые работают с Poseidon при проектировании серьезных приложений. Poseidon известен своим удобством (usability).
Слайд 25

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) SmartDraw SmartDraw -

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

SmartDraw SmartDraw - это

простая и дружественная, да еще и нетребовательная к ресурсам альтернатива MS Visio. Как и Visio, этопрограмма, предназначенная исключительно для рисования, не имеющая функций поддержки командной разработки ПО.
Слайд 26

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) Dia - программа

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

Dia - программа для

создания диаграмм, базирующаяся на gtk+ и распространяющаяся по лицензии GPL. Dia создавалась поподобию коммерческой Windows-программы Visio. Она может быть использована для рисования многих видов диаграмм.
Слайд 27

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) TAU G2 от

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

TAU G2 от Telelogic.

Это легендарное средство моделирования, которое сочетает в себе мощь и простоту использования, а также предоставляет уникальную возможность начальной верификации и симуляции создаваемых моделей.
Интерфейс программы, правда, не блещет особой красотой в стиле Windows XP и выглядит даже слегка архаично, но, как оказалось, действительно очень удобен и понятен
Слайд 28

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) StarUML - программный

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

StarUML - программный инструмент

моделирования, который поддерживает UML (Унифицированный язык моделирования). StarUML ориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0.
StarUML предоставляет максимальную степень адаптации среды разработки пользователя, предлагая настройку параметров, которые могут влиять на методологию разработки программного обеспечения, проектную платформу и язык.
Слайд 29

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) Umbrello — среда

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

Umbrello — среда UML-моделирования. Это

приложение является свободным программным обеспечением, предназначенным для построения UML диаграмм на платформе Unix.
Umbrello поддерживает все стандартные типы UML-диаграмм. Также поддерживается импорт из C++, IDL, Pascal/Delphi, Ada, Python, Java, Perl (с помощью внешнего инструмента, доступного на uml.sourceforge.net) и экспорт диаграмм в различные языки программирования. Формат файла, используемый при хранении диаграмм, основан на XMI.
Слайд 30

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО) ArgoUML — средство

CASE-средства проектирования ПО (помимо изучавшихся в курсе ТРПО)

ArgoUML — средство UML

моделирования. ArgoUML является открытым программным обеспечением и распространяется под лицензией EPL.
ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше.
Слайд 31

Средства построения готовых UML-диаграмм по коду или наоборот UML/Code Generation Tool.

Средства построения готовых UML-диаграмм по коду или наоборот

UML/Code Generation Tool. Generate

source code from/as UML class model.
Java Round-Trip Engineering
Generate Java source code from UML class model, and let the UML model reflect the change you made in source code. Round-trip engineering helps keep your Java source code and software design synchronized. Every time you generate code or update UML model, changes will be merged.
Слайд 32

Средства построения готовых UML-диаграмм по коду или наоборот C++ Round-Trip Engineering

Средства построения готовых UML-диаграмм по коду или наоборот

C++ Round-Trip Engineering
Generate ANSI

C++ source code from your UML class model, and let the UML model reflect the change you made in source code. Round-trip engineering helps keep your C++ source code and software design synchronized. Every time you generate code or update UML model, changes will be merged.
Слайд 33

Средства построения готовых UML-диаграмм по коду или наоборот Instant Code Generation/Reversal

Средства построения готовых UML-диаграмм по коду или наоборот

Instant Code Generation/Reversal
Model the

new system with UML class diagram, and then generate the source code for implementation. Use Instant Generator to generate source files from UML class diagram. You can also reverse engineer UML class model from source files.
Слайд 34

Помимо диаграмм классов Form Sequence Diagram from Java Code Logic Study

Помимо диаграмм классов

Form Sequence Diagram from Java Code Logic
Study the runtime

behavior of an application by mean of a UML sequence diagram. Visual Paradigm supports the reverse engineering of sequence diagram from Java source code.
State machine code generation
Model controller class and its state machine with class diagram and state machine diagram, and generate the source code for the state machine.
Export state machine diagram to SCXML
Export State Chart XML (SCXML) from state machine diagram.
Слайд 35

Sourcetrail

Sourcetrail

Слайд 36

Среды разработки и средства построения готовых UML-диаграмм по коду или наоборот

Среды разработки и средства построения готовых UML-диаграмм по коду или наоборот

Разрабатывайте

и внедряйте программное обеспечение в единой среде - вашей любимой интегированной среде разработки IDE. Благодаря UML-редактору, легко интегрированному в IDE, вы можете с комфортом сосредоточиться на разработке своего программного обеспечения. Просто нажмите один раз, чтобы обновить код из UML-дизайна или обновить модель класса UML на основе исходного кода. UML-моделирование в IDE Рисуйте UML-диаграммы прямо в вашей любимой IDE. Поддерживаются популярные IDE (Eclipse / NetBeans / IntelliJ IDEA / Visual Studio / Android Studio)
Слайд 37

Средства построения готовых UML-диаграмм по коду или наоборот It provides the

Средства построения готовых UML-диаграмм по коду или наоборот

It provides the industry's

best code engineering mechanism (with full round-trip support for Java, C++, C#, CL (MSIL) and CORBA IDL programming languages), as well as database schema modeling, DDL generation and reverse engineering facilities.
Derives models from existing source code in just seconds MagicDraw's reverse engineering is the fastest way to get UML models from Java, C#, C++, CORBA IDL, EJB 2.0, DDL, CIL (MSIL), WSDL, and XML Schema source code. Our automatic generation of sequence diagrams from Java source code adds a more detailed view of the system.
Delivers source code from your UML model instantly MagicDraw generates code for Java, EJB, C#, C++, CORBA IDL, DDL, WSDL, XML Schema.
Since you can continue using your favorite IDE for coding, there's no need to waste valuable time learning a new one. Whether you are using MagicDraw as a standalone application or integrated with an IDE, you have the option for round-trip engineering to keep model and code synchronized. Since MagicDraw allows you to go further with code generation, it's the tool of choice in the world of Model Driven Development. MagicDraw integrates with IO Software ArcStyler, AndroMDA, and other MDD tools.
Слайд 38

Средства построения готовых UML-диаграмм по коду или наоборот StarUML действительно поддерживает

Средства построения готовых UML-диаграмм по коду или наоборот

StarUML действительно поддерживает профили

UML. Это максимизирует расширяемость UML, делая моделирование на UML применимым даже в области финансов, обороны, электронной коммерции, страховании и аэронавтике.
На самом деле можно создавать платформенно независимые модели (PIM), а платформенно зависимые модели (PSM) и исполняемые коды могут быть всегда автоматически сгенерированы на их основе.
Пользователи могут допускать ошибки в процессе моделирования. Такие ошибки могут дорого обойтись, если они не будут исправлены к заключительной стадии формирования кода. Чтобы предотвращать такие ситуации, StarUML автоматически проверяет модель программы, разрабатываемую пользователем, облегчая раннее обнаружение ошибок и способствуя безупречной и полной разработке программного обеспечения.
Предоставляет модуль Generator для генерации документов и кода. • Предоставляет модуль Java, поддерживающий профиль Java, Инструментарий J2SE/J2EE, генерацию объектного кода и реинжениринг.
Слайд 39

СИСТЕМЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ (ТРАССИРОВКА ТРЕБОВАНИЙ)

СИСТЕМЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ (ТРАССИРОВКА ТРЕБОВАНИЙ)

Слайд 40

Инженерия требований Применение подхода управления требованиями позволяет определить те самые особенности,

Инженерия требований

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

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

Требования (IEEE) Требование — это любое условие, которому должна соответствовать разрабатываемая

Требования (IEEE)

Требование — это любое условие, которому должна соответствовать разрабатываемая система или

программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
Документированное представление условий или возможностей для пунктов 1 и 2.
Слайд 42

Требования (ITIL) В соответствии с ITILv3 все требования в проекте можно

Требования (ITIL)

В соответствии с ITILv3 все требования в проекте можно разделить

на следующие группы:
Функциональные (Functional) — реализуют саму бизнес-функцию.
Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
Эргономические (Usability) — к удобству работы конечных пользователей.
Архитектурные (Architectural) — требования к архитектуре системы.
Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.
Слайд 43

Роль требований Стоит также заметить, что правильная организация работы с требованиями

Роль требований

Стоит также заметить, что правильная организация работы с требованиями позволяет

управлять рисками на самых ранних стадиях разработки. То есть существует возможность отследить риск, возникающий из определённого требования, оценить степень его влияния, вероятность появления.
На основании этого можно разработать план по предотвращению и устранению последствий этого риска. Все эти действия позволят избежать значительных финансовых потерь и предоставить потенциальным клиентам определённые гарантии.
Можно сделать вывод, что требования играю важную роль в следующих областях:
– планирование проекта;
– управление рисками;
– приемочные тестирования;
–формирование компромиссов (согласований);
– управление изменениями.
Слайд 44

Взаимосвязь стадий проекта и процесса управления требованиями. V-модель

Взаимосвязь стадий проекта и процесса управления требованиями. V-модель

Слайд 45

Стадии процесса управления требованиями

Стадии процесса управления требованиями

Слайд 46

Стадии процесса управления требованиями Процесс управления требования начинается с планирования. На

Стадии процесса управления требованиями

Процесс управления требования начинается с планирования. На этапе

планирования системный аналитик создает план управления требованиями и шаблоны необходимой документации. Планирование – первый шаг при работе с требованиями, он начинается на этапе предпроектного обследования.
Также системный аналитик определяет и заносит в план решение об использовании специального инструментального средства для управления требованиями.
При работе с государственным заказчиком для описания требований чаще всего используется техническое задание, разработанное в соответствие с ГОСТ 34.602- 89 или ГОСТ 19.201-78. Если нет жестких требований со стороны заказчика на соответствие государственным стандартам, можно использовать спецификацию требований на основе стандарта IEEE 830-1998.
Слайд 47

Этапы процесса разработки требований Идентификация заинтересованных сторон. Выявление требований заинтересованных сторон.

Этапы процесса разработки требований

Идентификация заинтересованных сторон.
Выявление требований заинтересованных сторон.
Формирование требований.
Уточнение

и переформулирование требований.
Анализ требований.
Приведение требований к виду одинаково понятному для всех заинтересованных сторон.
Определение критериев приёмки требований.
Слайд 48

Этапы процесса разработки требований Определение стратегии проверки требований. Создание тестов. Спецификация

Этапы процесса разработки требований

Определение стратегии проверки требований.
Создание тестов.
Спецификация требований.


Определение приоритетов требований.
Выведение зависимых требований.
Классификация требований.
Распределение требований.
Отслеживание требований.
Тестирование требований.
Проверка требований.
Утверждение требований
Слайд 49

Системы управления требованиями (трассировки требований) Цели: 1. Обеспечение уверенности заказчика в

Системы управления требованиями (трассировки требований)

Цели:
1. Обеспечение уверенности заказчика в том, что

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

Системы управления требованиями (трассировки требований) Способы достижения: 1. Сбор и анализ

Системы управления требованиями (трассировки требований)

Способы достижения:
1. Сбор и анализ количественных показателей

процесса и конечного результата. Например, общее количество требований, количество связанных, проверенных, удовлетворенных требований, в том числе в разрезах по исполнителям, элементам АС и экспертам.
2. Устранение ошибок, выявленных в ходе детальной проверки каждого требования в материалах проекта, а также взаимной проверки материалов на непротиворечивость.
3. Формальное закрепление ответственных исполнителей за каждым требованием.
4. Формальная организация приемки: описание критериев приемки, выдача заданий на экспертизу, формирование отчета о проведенной экспертизе.
Слайд 51

Количественные показатели процесса. Пример – АСУ В требованиях к показателям назначения

Количественные показатели процесса. Пример – АСУ

В требованиях к показателям назначения

АС приводят значения параметров, характеризующие степень соответствия системы ее назначению.
Для АСУ указывают:
степень приспособляемости системы к изменению процессов и методов управления;
степень приспособляемости системы к отклонениям параметров объекта управления;
допустимые пределы модернизации и развития системы;
вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.
Слайд 52

Профессиональная разработка и управление требованиями Совместное создание полноценных документов требований из

Профессиональная разработка и управление требованиями

Совместное создание полноценных документов требований из браузера
Удобная

работа с реестром требований, обсуждение, рецензирование и согласование требований в команде
Документирование UML-моделей, формул и алгоритмов, просмотр изменений в моделях и формулах
Быстрая и простая постановка задач разработчикам и тестировщикам
Версионирование требований и бейзлайны, трассировка требований на проектные артефакты
Загрузка и выгрузка требований в формате Microsoft Word, Open Document, HTML, с использованием пользовательских шаблонов
Полностью настраиваемый процесс работы над требованиями, расширяемая модель данных
Сбор и визуализация метрик для анализа проблем и повышения продуктивности
Слайд 53

Слайд 54

Решаемые задачи Разработка требований с вовлечением всех участников команды, начиная с

Решаемые задачи

Разработка требований с вовлечением всех участников команды, начиная с самых

ранних этапов жизненного цикла продукта.
Фиксация технических решений в форме фотографий, скриншотов, UML-моделей и формул, с автоматической нотификацией об изменениях.
Аккуратное внесение изменений в требования, анализ и сравнение требований, документов и версий.
Создание постановки для разработчиков и тестировщиков на основе новых требований или изменений в них.
Контроль и поддержка целостности продукта, системных требований, тестовой и пользовательской документации, с использованием трассировок и матриц трассируемости.
Интеграция с трекером или выгрузка документов требований для подписания или согласования.
Формирование библиотеки шаблонов и требований для повторного использования в проектах.
Поддержка Agile и Lean ориентированных процессов разработки ПО с максимальным вовлечением аналитиков.
Слайд 55

IBM Rational Requisite Pro

IBM Rational Requisite Pro

Слайд 56

IBM Rational/Telelogic DOORS

IBM Rational/Telelogic DOORS

Слайд 57

Borland Caliber RM

Borland Caliber RM

Слайд 58

JIRA

JIRA

Слайд 59

aNimble

aNimble

Слайд 60

Redmine

Redmine

Слайд 61

in-STEP BLUE

in-STEP BLUE

Слайд 62

Выводы Исходя из приведённого обзора подхода к управлению требованиями, необходимо заметить,

Выводы

Исходя из приведённого обзора подхода к управлению требованиями, необходимо заметить, что

для максимально эффективной работы с ними невозможно обойтись без использования какого-либо средства автоматизации основных процессов.
В зависимости от выбранного программного фреймворка реализация системы будет зависеть от имеющихся библиотек, наборов дополнительных плагинов, особенностей языка программирования и т.д.
В таких условиях реализация одинакового функционала на различных платформах разработки будет состоять из различного количества требований. В свою очередь, сроки реализации накладывают ограничения на оперативность принятия решений, как управленческих, так и производственных.
Если требуется быстро принять какое-либо решение, а информации для этого недостаточно, в силу необходимости её консолидации из различных источников, сроки его принятия велики, что негативным образом сказывается на общем процессе реализации.
Слайд 63

Выводы Среди систем подобного рода можно выделить: 1. 3SL Cradle. 2.

Выводы

Среди систем подобного рода можно выделить:
1. 3SL Cradle. 2. IBM

Rational DOORS.
3. Borland Caliber. 4. Devprom Requirements.
5. codeBeamer Requirements Management.
6. Cognition Cockpit. 7. in-STEP BLUE. 8. inteGREAT.
9. Jama. 10. Kovair ALM Studio. 11. Polarion REQUIREMENTS. 12. TestTrack.
13. Visure Requirements.
Слайд 64

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ ПРИЛОЖЕНИЙ

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ ПРИЛОЖЕНИЙ

Слайд 65

Инструментальные средства тестирования приложений Тестирование – дорогой и трудоемкий этап разработки

Инструментальные средства тестирования приложений

Тестирование – дорогой и трудоемкий этап разработки программных

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

Классификация основных методов тестирования 1. По знанию внутренностей системы: • черный

Классификация основных методов тестирования

1. По знанию внутренностей системы:
• черный ящик

(black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).
2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/ stress/performance testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).
Слайд 67

Классификация основных методов тестирования 3. По субъекту тестирования: • альфа-тестировщик (alpha

Классификация основных методов тестирования

3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);


• бета-тестировщик (beta tester).
4. По времени проведения тестирования:
• до передачи пользователю
— альфа-тестирование (alpha testing);
– тест приемки (smoke test, sanity test или confidence test);
– тестирование новых функциональностей (new feature testing);
– регрессивное тестирование (regression testing);
– тест сдачи (acceptance or certification test);
• после передачи пользователю
— бета-тестирование (beta testing).
Слайд 68

Классификация основных методов тестирования 5. По критерию “позитивности” сценариев: • позитивное

Классификация основных методов тестирования

5. По критерию “позитивности” сценариев:
• позитивное тестирование

(positive testing);
• негативное тестирование (negative testing).
6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or end-to-end testing).
Слайд 69

Классификация основных методов тестирования 7. По степени автоматизированности тестирования: • ручное

Классификация основных методов тестирования

7. По степени автоматизированности тестирования:
• ручное тестирование

(manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi automated testing).
8. По степени подготовки к тестированию:
• тестирование по документации (formal/ documented testing);
• эд хок-тестирование (ad hoc testing).
Слайд 70

Инструментальные средства тестирования приложений Перечислим возможные инструментальные средства тестирования и отношения

Инструментальные средства тестирования приложений

Перечислим возможные инструментальные средства тестирования и отношения между

ними.
1. Организатор тестов. Управляет выполнением тестов. Он отслеживает тестовые данные, ожидаемые результаты и тестируемые функции программы.
2. Генератор тестовых данных. Генерирует тестовые данные для тестируемой программы. Он может выбирать тестовые данные из базы данных или использовать специальные шаблоны для генерации случайных данных необходимого вида.
3. Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта. При тестировании параллельно запускаются оракул и тестируемая программа и сравниваются результаты их выполнения.
Слайд 71

Инструментальные средства тестирования приложений 4. Компаратор файлов. Сравнивает результаты тестирования с

Инструментальные средства тестирования приложений

4. Компаратор файлов. Сравнивает результаты тестирования с результатами предыдущего тестирования

и составляет отчет об обнаруженных различиях. Компараторы особенно важны при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие в новой версии системы.
5. Генератор отчетов. Формирует отчеты по результатам проведения тестов.
6. Динамический анализатор. Добавляет в программу код, который подсчитывает, сколько раз выполняется каждый оператор. После запуска теста создает исполняемый профиль, в котором показано, сколько раз в программе выполняется каждый оператор.
7. Имитатор. Существует несколько типов имитаторов. Целевые имитаторы моделируют машину, на которой будет выполняться программа. Имитатор пользовательского интерфейса – это программа, управляемая сценариями, которая моделирует взаимодействия с интерфейсом пользователя. Имитатор ввода-вывода генерирует последовательности повторяющихся транзакций.
Слайд 72

Selenium

Selenium

Слайд 73

Selenium

Selenium

Слайд 74

Katalon Studio

Katalon Studio

Слайд 75

UFT (Unified Functional Testing )

UFT (Unified Functional Testing )

Слайд 76

UFT (Unified Functional Testing )

UFT (Unified Functional Testing )

Слайд 77

Watir

Watir

Слайд 78

IBM Rational Functional Tester

IBM Rational Functional Tester

Слайд 79

TestComplete

TestComplete

Слайд 80

Выводы

Выводы

Слайд 81

Выводы Обзор: https://otus.ru/nest/post/617/ Selenium. TestingWhiz. HPE Unified Functional Testing (HP –

Выводы

Обзор:
https://otus.ru/nest/post/617/
Selenium.
TestingWhiz.
HPE Unified Functional Testing (HP – UFT ранее QTP)


TestComplete.
Ranorex.
Sahi.
Watir.
Tosca Testsuite.
Katalon Studio
Слайд 82

СИСТЕМА СОЗДАНИЯ, ХРАНЕНИЯ И ЗАПУСКА ТЕСТОВЫХ СЦЕНАРИЕВ

СИСТЕМА СОЗДАНИЯ, ХРАНЕНИЯ И ЗАПУСКА ТЕСТОВЫХ СЦЕНАРИЕВ

Слайд 83

Система создания, хранения и запуска тестовых сценариев Автоматические тесты выполняют тестовые

Система создания, хранения и запуска тестовых сценариев

Автоматические тесты выполняют тестовые сценарии

автоматически, но при этом сами требуют запуска. С каждым новым релизом от разработчиков необходимо вручную запускать множество автоматических тестов, которые, в свою очередь, запускают тестовые сценарии и документируют результаты.
Для более рационального использования временных и человеческих ресурсов существуют системы непрерывной интеграции (continuous integration).
Такие системы позволяют одновременно в изолированных средах запускать сразу несколько автоматических тестов, а также имеют возможность работы по расписанию. Таким образом, команда тестировщиков планирует проводимые тестирования заранее, имеет возможность выполнять весь их набор одновременно, а результаты прохождения тестов отображать комплексно.
Слайд 84

Примеры 1. Jenkins CI. 2. Atlassian Bamboo. 3. ThoughtWorks Go. 4.

Примеры

1. Jenkins CI. 2. Atlassian Bamboo.
3. ThoughtWorks Go. 4. Buildbot.


5. JetBrains TeamCity. 6. Hudson CI.
7. Continua CI.
8. Codeship.
9. CircleCI.
10. AppVeyor.
11. Microsoft Team Foundation Server.
12. Travis CI
Слайд 85

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ БАЗ ЗНАНИЙ

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ БАЗ ЗНАНИЙ

Слайд 86

Инструментальные средства разработки баз знаний Процесс разработки любой системы сопровождается созданием

Инструментальные средства разработки баз знаний

Процесс разработки любой системы сопровождается созданием большого

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

Инструментальные средства разработки баз знаний Важным моментом, при создании данного информационного

Инструментальные средства разработки баз знаний

Важным моментом, при создании данного информационного агрегатора,

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

Wiki

Wiki

Слайд 89

Wiki

Wiki

Слайд 90

Atlassian Confluence

Atlassian Confluence

Слайд 91

eXo Platform

eXo Platform

Слайд 92

Helpjuice

Helpjuice

Слайд 93

Spiceworks’ Knowledge Base

Spiceworks’ Knowledge Base

Слайд 94

Freshdesk

Freshdesk

Слайд 95

Выводы Существуют следующие популярные средства реализации базы знаний: 1. Wiki. 2.

Выводы

Существуют следующие популярные средства реализации базы знаний:
1. Wiki. 2. Atlassian Confluence.


3. eXo Platform. 4. Helpjuice.
5. Comintelli’s Knowledge Management System.
6. Spiceworks’ Knowledge Base. 7. Moxie Knowledgebase.
8. Zendesk. 9. Freshdesk.
10. Safeharbor Knowledge Solutions. 11. Knowledgeowl.
Слайд 96

СИСТЕМЫ УПРАВЛЕНИЯ ЗАДАЧАМИ

СИСТЕМЫ УПРАВЛЕНИЯ ЗАДАЧАМИ

Слайд 97

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

Системы управления задачами

Процесс разработки информационной системы требует консолидации усилий большого числа

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

Bitrix24

Bitrix24

Слайд 99

eXo Platform

eXo Platform

Слайд 100

Asana

Asana

Слайд 101

JIRA Atlassian

JIRA Atlassian

Слайд 102

Trello

Trello

Слайд 103

Gantt Project

Gantt Project

Слайд 104

Gitea

Gitea

Слайд 105

Выводы 1. Bitrix24. 2. eXo Platform. 3. Wrike. 4. Asana. 5.

Выводы

1. Bitrix24.
2. eXo Platform.
3. Wrike.
4. Asana.
5. JIRA

Atlassian.
6. Trello.
7. Basecamp.
8. TAIGA.
9. Producteev.
10. Freedcamp.
Слайд 106

ИНСТРУМЕНТЫ ПРОВЕРКИ КОДА НА СООТВЕТСТВИЕ СТАНДАРТАМ КОДИРОВАНИЯ (ВАЛИДНОСТЬ)

ИНСТРУМЕНТЫ ПРОВЕРКИ КОДА НА СООТВЕТСТВИЕ СТАНДАРТАМ КОДИРОВАНИЯ (ВАЛИДНОСТЬ)

Слайд 107

Инструменты проверки кода на соответствие стандартам кодирования (валидность) В разработке проекта

Инструменты проверки кода на соответствие стандартам кодирования (валидность)

В разработке проекта зачастую

принимают участие разработчики разного уровня. Это приводит к тому, что нет строгого формата написания кода. За качеством кода на проекте приходится постоянно следить старшим разработчикам и это отнимает у них кучу времени.
Применительно к С/С++, наиболее известными стандартами кодирования являются MISRA, HICPP, Google C++ Style Guide.
Для того, чтобы облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.
Слайд 108

Стандарт оформления кода (стандарт кодирования, стиль программирования) набор правил и соглашений,

Стандарт оформления кода (стандарт кодирования, стиль программирования)

набор правил и соглашений, используемых при написании исходного

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

Состав стандарта оформления кода Обычно, стандарт оформления кода описывает: способы выбора

Состав стандарта оформления кода

Обычно, стандарт оформления кода описывает:
способы выбора названий и

используемый регистр символов для имён переменных и других идентификаторов:
запись типа переменной в её идентификаторе (венгерская нотация) и
регистр символов (нижний, верхний, «верблюжий», «верблюжий» с малой буквы), использование знаков подчёркивания для разделения слов;
стиль отступов при оформлении логических блоков — используются ли символы табуляции, ширина отступа;
способ расстановки скобок, ограничивающих логические блоки;
использование пробелов при оформлении логических и арифметических выражений;
стиль комментариев и использование документирующих комментариев.
Вне стандарта подразумевается:
отсутствие магических чисел;
ограничение размера кода по горизонтали (чтобы помещался на экране) и вертикали (чтобы весь код файла держался в памяти), а также функции или метода в размер одного экрана.
Слайд 110

Install Pear: http://pear.php.net/go-pear.phar

Install Pear:

 http://pear.php.net/go-pear.phar

Слайд 111

Слайд 112

Ошибки В случае, если будут найдены ошибки, операция коммита прерывается и на экран выводится список ошибок

Ошибки

В случае, если будут найдены ошибки, операция коммита прерывается и на

экран выводится список ошибок
Слайд 113

Актуальность Сильные стороны этого способа: Централизованный контроль; Нельзя полностью избежать проверки

Актуальность

Сильные стороны этого способа:
Централизованный контроль;
Нельзя полностью избежать проверки кода;
Скрипты проверки кода

не изменяют исходные файлы и не блокируют добавление кода в случае хотфикса;
Скрипты легко установить и настроить;
Помимо ошибок стандартов кодирования Drupal, отображаются функциональные ошибки. Например о том, что вы забыли использовать функцию t или check_plain (а это уже дыра в безопасности) при выводе данных на страницу.
Слайд 114

Cpplint cpplint или cpplint.py - это похожий на линты инструмент с

Cpplint

cpplint или cpplint.py - это похожий на линты инструмент с открытым

исходным кодом, разработанный Google, разработан, чтобы гарантировать, что код C ++ соответствует руководствам по стилю кодирования Google.
Поэтому cpplint реализует то, что Google считает лучшими практиками в кодировании C ++.
CppLint — это скрипт на Питоне и для его работы необходимо установить Питон (версии 2.х и 3.х не совместимы, требуется именно 2.х). Установив Питон и проассоциировав файлы .py, можно запустить из скрипт cpplint на исполнение из командной строк.
Слайд 115

Общий вид

Общий вид

Слайд 116

Пример работы

Пример работы

Слайд 117

Как проверить код на валидность Не нужно вычитывать код и считать

Как проверить код на валидность

Не нужно вычитывать код и считать символы

— для этого есть сервисы и инструменты проверки валидности HTML онлайн.
Что они проверяют:
Синтаксис Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
Вложенность тэгов Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность.
DTD (Document Type Definition) Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.
Слайд 118

Примеры

Примеры

Слайд 119

Примеры

Примеры

Слайд 120

Примеры. WDG HTML Validator

Примеры. WDG HTML Validator

Слайд 121

PyCharm PyCharm позаботится о рутинных задачах, а вы сможете сосредоточиться на

PyCharm

PyCharm позаботится о рутинных задачах, а вы сможете сосредоточиться на более

важных вещах.
Работая в PyCharm, вы экономите время — для большинства задач не нужно отрывать руки от клавиатуры.
Слайд 122

СИСТЕМЫ ОТСЛЕЖИВАНИЯ ОШИБОК. СИСТЕМА УПРАВЛЕНИЯ ДЕФЕКТАМИ

СИСТЕМЫ ОТСЛЕЖИВАНИЯ ОШИБОК. СИСТЕМА УПРАВЛЕНИЯ ДЕФЕКТАМИ

Слайд 123

Система управления дефектами Отношение пользователя к информационной системе в целом чаще

Система управления дефектами

Отношение пользователя к информационной системе в целом чаще всего

складывается из опыта работы с её программной частью.
Если программная реализация системы содержит ошибки, работает нестабильно, требует большого количества усилий для освоения, её качество для пользователя, при всей сложности и обширности архитектурной составляющей, будет низким.
Чтобы этого не произошло, разработчикам приходится проводить сложные и дорогостоящие процедуры по улучшению качества. К ним относится процесс выявления дефектов (bug).
Слайд 124

Система управления дефектами Правильная организация этого процесса затрагивает множество участников. Выявление

Система управления дефектами

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

и его документирование происходит на этапе тестирования.
Далее происходит передача информации о дефекте разработчикам, причём это может быть сделано посредством базы знаний или специальной системы управления дефектами.
Имея запись о соответствующем дефекте, можно отслеживать состояние его устранения, ответственное за это лицо, время устранения, а также другие дополнительные сведения.
Следует заметить, что накопленная база дефектов позволяет сократить шансы появления ошибок в дальнейших разработках, так как даёт представление и возможных дефектах и причинах их возникновения.
Слайд 125

Примеры

Примеры

Слайд 126

Слайд 127

BugTracker.NET

BugTracker.NET

Слайд 128

BUGS - the Bug Genie

BUGS - the Bug Genie

Слайд 129

Inflectra SpiraTeam

Inflectra SpiraTeam

Слайд 130

YouTrack

YouTrack

Слайд 131

Выводы 1. Inflectra SpiraTeam. 2. YouTrack. 3. Bugzilla. 4. Mantis. 5.

Выводы

1. Inflectra SpiraTeam. 2. YouTrack.
3. Bugzilla. 4. Mantis.
5. FogBugz.

6. Zoho Projects.
7. BugHerd. 8. Bugify.
9. Pivotal Tracker. 10. JIRA Atlassian.
11. TestLink. 12. TestRail.
13. Sitechco. 14. Microsoft Team Foundation Server.
Слайд 132

Выводы. Часть 2 Redmin BUGS - the Bug Genie Bugzilla eTraxis

Выводы. Часть 2

Redmin BUGS - the Bug Genie 
Bugzilla  eTraxis 
GNATS Launchpad
Mantis bug tracking system
Trac EmForge
Picket Flyspray  DEVPROM

Слайд 133

РЕДАКТОРЫ ИСХОДНОГО КОДА

РЕДАКТОРЫ ИСХОДНОГО КОДА

Слайд 134

Редакторы исходного кода Редактор исходного кода — текстовый редактор для создания

Редакторы исходного кода

Редактор исходного кода — текстовый редактор для создания и редактирования исходного кода программ. Он

может быть отдельным приложением или встроен в интегрированную среду разработки (IDE).
Редакторы исходного кода имеют некоторые возможности, упрощающие и ускоряющие написание и изменение кода, такие как:
подсветка синтаксиса,
автодополнение,
отступы,
проверка правильности расстановки скобок,
контекстная помощь по коду
и многие другие.
Слайд 135

Visual Studio Code Visual Studio Code это бесплатный кросс-платформенный редактор кода,

Visual Studio Code

Visual Studio Code это бесплатный кросс-платформенный редактор кода, разработанный Microsoft.

Программа имеет открытый исходный код. Исходя из опроса, проведенного Stack Overflow в 2017 году, это один из самых популярных редакторов кода, которым пользуются больше 24% разработчиков.
Он оснащен доступным набором инструментов для редактирования и отладки. Редактор легко интегрируется с другими сервисами. Его собственные свойства также легко расширить.
Новая функция Live Share предоставляет возможности для парного программирования, благодаря чему вы и ваша команда можете с легкостью работать над одной базой кода. Вам не придется для этого конфигурировать инструменты разработки или возиться с настройками окружения.
Кроме того, среди особенностей VS Code мы видим Git-интеграцию, IntelliSense (технология автодополнения), подсветку синтаксиса для самых популярных языков программирования и много других прекрасных функций.
Если вам этого недостаточно, вы можете с легкостью улучшить и кастомизировать VS Code благодаря коллекции плагинов, поставляемых Microsoft или создаваемых сообществом.
Слайд 136

Visual Studio Code

Visual Studio Code

Слайд 137

Sublime Text 3 предоставляет базовое автодополнение, подсветку синтаксиса и функционал сворачивания

Sublime Text 3

предоставляет базовое автодополнение, подсветку синтаксиса и функционал сворачивания (фолдинга).

Но используя Package Control в Sublime Text, вы можете расширить последний и добавить больше «примочек»: инструменты отладки, новые темы, поддержку intellisense и т. п.
В последней версии Sublime также улучшено использование памяти (в некоторых случаях до 30%), появился рендеринг текста с поддержкой лигатур, усовершенствовано взаимодействие пользователя с программой, определение синтаксиса и добавлены новые цветовые схемы.
Слайд 138

Atom Atom это еще один бесплатный, кросс-платформенный редактор с открытым исходным

Atom

Atom это еще один бесплатный, кросс-платформенный редактор с открытым исходным кодом. Он

создан и выпущен GitHub.
По умолчанию Atom предоставляет подсветку синтаксиса, дополнение и сворачивание кода, а также встроенную поддержку десятков языков программирования.
Также этот редактор поддерживает GitHub. Он поставляется со встроенным менеджером пакетов, благодаря чему вы можете осуществлять поиск, а также устанавливать или создавать собственные пакеты для расширения функционала редактора.
Подобно VS Code, он также оснащен мощным инструментом для парного программирования – Teletype. Это дает возможность нескольким разработчикам присоединяться к изолированной сессии и работать совместно.
Atom можно расширить с помощью Atom-IDE – набора опциональных пакетов.
Слайд 139

Atom

Atom

Слайд 140

SpaceMacs

SpaceMacs

Слайд 141

Notepad++

Notepad++

Слайд 142

Brackets Brackets также поставляется с основными стандартными свойствами, включая автодополнение, подсветку

Brackets

Brackets также поставляется с основными стандартными свойствами, включая автодополнение, подсветку синтаксиса

для многих языков программирования, поддержку быстрого редактирования и разнообразных препроцессоров.
К его отличительным особенностям можно отнести опцию предпросмотра Live Preview. С ее помощью разработчик может открыть текущий документ в Chrome и просматривать, как этот документ отображается в браузере.
В Brackets также есть свойство «extract», позволяющее разработчикам подтягивать цвета, размеры, градиенты, шрифты и другие важные данные из PSD-файла в готовый к использованию CSS-файл.
Слайд 143

Brackets

Brackets

Слайд 144

Atom Atom является кроссплатформенным приложением и работает таких операционных системах, как

Atom

Atom является кроссплатформенным приложением и работает таких операционных системах, как Windows

, OS X и Linux.
Благодаря умному механизму автозаполнения, Atom помогает быстрее писать код.
Особенность интерфейса Atom позволяет разбивать интерфейс на множество окон, чтобы вы могли сравнивать и писать код в этих окнах одновременно.
Atom является продвинутым текстовым редактором, получившим возможности IDE, благодаря различным плагинам.
Поддерживает в разработке такие языки как: HTML, CSS, JavaScript, Python, XML, PHP, Java, SQL, C# и многие другие.
Слайд 145

Brackets Связь с Google Chrome. Основная особенность редактора Brackets, выделяемая многими

Brackets

Связь с Google Chrome. Основная особенность редактора Brackets, выделяемая  многими разработчиками

- связь с Google Chrome в режиме реального времени. С помощью этого механизма, разработчик может сразу после внесенного изменения наблюдать, как все эти изменения будут отображаться в браузере.
Доступность на Windows, MacOs, Linux.
Brackets признан одним из лучших текстовых редакторов под MacOs.
Широко развитая система горячих клавиш.
Основной особенностью, которая отличает Brackets от остальных HTML-редакторов, является функция «Извлечь». Функция извлечения позволяет извлекать информацию прямо из PSD - такую как шрифты, цвета и измерения, с чистым CSS и без контекстных ссылок на код.
Слайд 146

Выводы Ace AkelPad Atom Eclipse Emacs Geany IntelliJ IDEA Light Table

Выводы

Ace AkelPad
Atom Eclipse
Emacs Geany
IntelliJ IDEA Light Table
Visual Studio Code
Notepad++ PSPad
Embarcadero RAD Studio
RJ TextEd Sublime Text vi и vim

Слайд 147

ГЕНЕРАТОРЫ ДОКУМЕНТАЦИИ

ГЕНЕРАТОРЫ ДОКУМЕНТАЦИИ

Слайд 148

Генераторы документации Генератор документации — программа или пакет программ, позволяющая получать

Генераторы документации

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для

конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям (полученным на выходе компилятора).
Слайд 149

Sphinx Хотя Sphinx написан на языке Python и изначально был разработан

Sphinx

Хотя Sphinx написан на языке Python и изначально был разработан для

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

Sphinx

Sphinx

Слайд 151

JSDuck Хорошие разработчики тратят много времени на поддержку документации, но в

JSDuck

 Хорошие разработчики тратят много времени на поддержку документации, но в дальнейшем

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

SLATE

SLATE

Слайд 153

Документирование средствами Process Modeller

Документирование средствами Process Modeller

Слайд 154

Документирование средствами Process Modeller

Документирование средствами Process Modeller

Слайд 155

Документирование моделей данных в ERwin DM ERwin DM имеет собственные встроенные

Документирование моделей данных в ERwin DM

ERwin DM имеет собственные встроенные средства

документирования моделей, такие как построитель шаблонов отчетов Report Template Builder и построитель шаблонов текстовых отчетов Data Browser.
Встроенные инструменты импорта/экспорта позволяют экспортировать данные из модели ERwin DM в специализированные средства для создания отчетов презентационного качества, введения сложного форматирования и обработки данных и т.п.
Report Template Builder позволяет однократно разработать шаблон отчета, который впоследствии будет доступен для использования в любых моделях для генерации отчетов в любом из форматов: HTML, RTF, TXT, PDF.
Слайд 156

Документирование моделей данных в ERwin DM

Документирование моделей данных в ERwin DM

Слайд 157

Документирование моделей данных в ERwin DM

Документирование моделей данных в ERwin DM

Слайд 158

Выводы 1. Bit.ai 2. LaTex 3. JavaDoc 4. Haroopad 5. Sphinx

Выводы

1. Bit.ai
2. LaTex
3. JavaDoc
4. Haroopad
5. Sphinx
Для документации API:
1. https://redoc.ly/
2. https://swagger.io/
Генерация кодов

и документов StarUML
http://staruml.sourceforge.net/docs/user-guide(ru)/user-guide.pdf
Слайд 159

ПРОФИЛИРОВАНИЕ

ПРОФИЛИРОВАНИЕ

Слайд 160

Профилирование Профилирование — сбор характеристик работы программы, таких как время выполнения

Профилирование

Профилирование — сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно

подпрограмм), число верно предсказанных условных переходов, число кэш-промахов и т. д.
Инструмент, используемый для анализа работы, называют профилировщиком или профайлером (англ. profiler). Обычно выполняется совместно с оптимизацией программы.
Характеристики могут быть аппаратными (время) или вызванные программным обеспечением (функциональный запрос). Инструментальные средства анализа программы чрезвычайно важны для того, чтобы понять поведение программы. Проектировщики ПО нуждаются в таких инструментальных средствах, чтобы оценить, как хорошо выполнена работа. Программисты нуждаются в инструментальных средствах, чтобы проанализировать их программы и идентифицировать критические участки программы.
Это часто используется, чтобы определить, как долго выполняются определенные части программы, как часто они выполняются, или генерировать граф вызовов (Call Graph). Обычно эта информация используется, чтобы идентифицировать те участки программы, которые работают больше всего. Эти трудоёмкие участки могут быть оптимизированы, чтобы выполняться быстрее.
Слайд 161

AQtime

AQtime

Слайд 162

dotTrace

dotTrace

Слайд 163

VTune

VTune 

Слайд 164

WordPress

WordPress

Слайд 165

Xdebug

Xdebug

Слайд 166

dotMemory

dotMemory

Слайд 167

Выводы Многоплатформенные универсальные решения: gprof[en] (Linux/Unix/*BSD) — несколько реализаций традиционного профилировщика,

Выводы

Многоплатформенные универсальные решения:
gprof[en] (Linux/Unix/*BSD) — несколько реализаций традиционного профилировщика, требующие инструментирования программы компилятором.
VTune (Windows/Linux) —

коммерческий продукт компании Intel
Intel® Single Event API (Windows/Linux/Android/MAC OS/...) - некоммерческий продукт компании Intel с открытым исходным кодом
CodeAnalyst (Windows/Linux) — бесплатная программа от компании AMD
Решения для отдельных операционных систем
AQtime (Windows)
Instruments[en] (ранее Shark; Mac OS X)
Perf (Linux)[en] — реализованная в ядре Linux система профилирования процессов и ядра
oprofile (Linux) — более ранний системный профилировщик Linux
Valgrind (Linux) — средство динамического двоичного анализа программ, содержит 2 плагина для профилирования производительности — Cachegrind и Callgrind.
Слайд 168

Выводы Для отдельных языков программирования (подобные инструменты могут быть встроены в

Выводы

Для отдельных языков программирования (подобные инструменты могут быть встроены в среду разработки):
Xdebug —

средство профилирования PHP скриптов.
XHProf — профилировщик для языка PHP.
Пример программ, профилирующих потребление памяти:
dotMemory (.NET)
Valgrind (Linux) — несколько плагинов для профилирования памяти.
Слайд 169

СИСТЕМЫ УПРАВЛЕНИЯ ВЕРСИЯМИ

СИСТЕМЫ УПРАВЛЕНИЯ ВЕРСИЯМИ

Слайд 170

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

Системы управления версиями

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

версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов.
В частности, системы управления версиями применяются в САПР, обычно в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (Software Configuration Management Tools).
Слайд 171

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

Системы управления версиями

Позволяют создавать разные варианты одного документа, т.н. ветки, с

общей историей изменений до точки ветвления и с разными — после нее.
Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.
Слайд 172

Subversion (SVN) МОДЕЛЬ РАБОТЫ: ЦЕНТРАЛИЗОВАННАЯ СИСТЕМА (В ОТЛИЧИЕ ОТ РАСПРЕДЕЛЕННЫХ СИСТЕМ,

Subversion (SVN)

МОДЕЛЬ РАБОТЫ:
ЦЕНТРАЛИЗОВАННАЯ СИСТЕМА (В ОТЛИЧИЕ ОТ РАСПРЕДЕЛЕННЫХ СИСТЕМ, ТАКИХ КАК

GIT ИЛИ MERCURIAL).
Копирование — Изменение — Слияние, т.е. пользователь забирает файл себе, изменяет его и закачивает обратно.
Блокирование — Изменение — Разблокирование. Когда пользователь выбирает из репозитария файл, он блокируется на запись для всех остальных.
Используется дельта-компрессия.
Репозиторий (repository).
Рабочая копия/working copy (WC).
ТИПЫ РЕПОЗИТОРИЕВ:
Базы данных на основе Berkeley DB.
Обычные файлы специального формата.
ДОСТУП К РЕПОЗИТОРИЮ:
Локальная или сетевая файловая система.
WebDAV/DeltaV (поверх http или https) с использованием модуля mod_dav_svn для Apache 2.
Собственный протокол ‘svn’ (порт по умолчанию 3690).
Слайд 173

Subversion (SVN)

Subversion (SVN)

Слайд 174

Использование Subversion РАССМОТРИМ ПОШАГОВО ОСНОВНЫЕ КОМАНДЫ. В СКОБКАХ УКАЗАНЫ КОМАНДЫ ДЛЯ

Использование Subversion

РАССМОТРИМ ПОШАГОВО ОСНОВНЫЕ КОМАНДЫ. В СКОБКАХ УКАЗАНЫ КОМАНДЫ ДЛЯ КОМАНДНОЙ

СТРОКИ.
Создание хранилища (svnadmin create).
Создание рабочей копии (svn checkout).
Изменения файлов и директорий в рабочей копии.
Для файловых операций (svn delete, svn move, svn copy).
Просмотр локальных (еще не зафиксированных) изменений в рабочей копии (svn diff).
Любые локальные изменения, если они признаны неудачными, можно откатить (svn revert).
Получение в свою рабочую копию свежих изменений, зафиксированных в хранилище другими пользователями (svn update).
Фиксация своих изменений в хранилище (svn commit).
Регулярное обновление рабочей копии последними зафиксированными изменениями (svn update).
Слайд 175

Работа с ветвями Cоздание ветви (svn copy). Переключение имеющейся рабочей копии

Работа с ветвями

Cоздание ветви (svn copy).
Переключение имеющейся рабочей копии на ветвь

(svn switch) или создание новой рабочей копии путем закачки (svn checkout).
Изменение файлов и директорий в рабочей копии, фиксация этих изменений (svn commit).
Копирование в ветвь свежих изменений из родительской ветви, сделанных после ветвления (svn merge, svn commit).
Копирование изменений с ветви в родительскую ветвь (svn merge, svn commit).
Удаление ветви (svn delete), если ее жизненный цикл закончен.
Слайд 176

GIT

GIT

Слайд 177

Team Foundation Server

Team Foundation Server

Слайд 178

Рейтинг систем контроля версий 2016

Рейтинг систем контроля версий 2016

Слайд 179

Выводы 1. Первое поколение SCCS (Source Code Control System) RCS (Revision

Выводы

1. Первое поколение
SCCS (Source Code Control System)
RCS (Revision Control System)
2. Второе

поколение
CVS (Concurrent Versions System)
SVN (Apache Subversion)
3. Третье поколение
Git
Mercurial
4. GitLab 12.7, Arc, Kubernetes, GitHub Actions, Bazaar, Codeville, Monotone
5. AWS CodeCommit, Helix Core, BitBucket
Слайд 180

Выводы. Помощь Общая теория: https://ru.hexlet.io/courses/git_base/lessons/vcs_intro/theory_unit Система контроля версий (cvs) — Сравниваем:

Выводы. Помощь

Общая теория:
https://ru.hexlet.io/courses/git_base/lessons/vcs_intro/theory_unit
Система контроля версий (cvs) — Сравниваем: Git, SVN, Mercurial
https://biz30.timedoctor.com/ru/c%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9/
Рейтинг

систем контроля версий 2016
https://tagline.ru/version-control-systems-rating/
Слайд 181

ПАРСЕРЫ (СИНТАКСИЧЕСКИЕ АНАЛИЗАТОРЫ)

ПАРСЕРЫ (СИНТАКСИЧЕСКИЕ АНАЛИЗАТОРЫ)

Слайд 182

Парсеры (синтаксические анализаторы) Парсер или синтаксический анализатор, — часть программы, преобразующей

Парсеры (синтаксические анализаторы)

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

в структурированный формат. Парсер выполняет синтаксический анализ текста.
Инструменты web scraping (парсинг) разработаны для извлечения, сбора любой открытой информации с веб-сайтов. Эти ресурсы нужны тогда, когда необходимо быстро получить и сохранить в структурированном виде любые данные из интернета. Парсинг сайтов – это новый метод ввода данных, который не требует повторного ввода или копипастинга. Такого рода программное обеспечение ищет информацию под контролем пользователя или автоматически, выбирая новые или обновленные данные и сохраняя их в таком виде, чтобы у пользователя был к ним быстрый доступ. 
Слайд 183

Import.io Import.io предлагает разработчику легко формировать собственные пакеты данных: нужно только

Import.io

Import.io предлагает разработчику легко формировать собственные пакеты данных: нужно только импортировать информацию

с определенной веб-страницы и экспортировать ее в CSV. Можно извлекать тысячи веб-страниц за считанные минуты, не написав ни строчки кода, и создавать тысячи API согласно вашим требованиям.
Слайд 184

Dexi.io (ранее CloudScrape) CloudScrape способен парсить информацию с любого веб-сайта и

Dexi.io (ранее CloudScrape)

CloudScrape способен парсить информацию с любого веб-сайта и не требует

загрузки дополнительных приложений, как и Webhose.
Редактор самостоятельно устанавливает своих поисковых роботов и извлекает данные в режиме реального времени. Пользователь может сохранить собранные данные в облаке, например, Google Drive и Box.net, или экспортировать данные в форматах CSV или JSON.
Слайд 185

Scrapinghub это облачный инструмент парсинга данных, который помогает выбирать и собирать

Scrapinghub

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

данные для любых целей.
Scrapinghub использует Crawlera, умный прокси-ротатор, оснащенный механизмами, способными обходить защиты от ботов.
Сервис способен справляться с огромными по объему информации и защищенными от роботов сайтами.
Слайд 186

ParseHub может парсить один или много сайтов с поддержкой JavaScript, AJAX,

ParseHub

может парсить один или много сайтов с поддержкой JavaScript, AJAX, сеансов,

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

VisualScraper это еще одно ПО для парсинга больших объемов информации из

VisualScraper

это еще одно ПО для парсинга больших объемов информации из сети.


VisualScraper извлекает данные с нескольких веб-страниц и синтезирует результаты в режиме реального времени.
Кроме того, данные можно экспортировать в форматы CSV, XML, JSON и SQL.
Слайд 188

Выводы 10 инструментов, позволяющих парсить информацию с веб-сайтов https://habr.com/ru/post/340038/ ANTLR —

Выводы

10 инструментов, позволяющих парсить информацию с веб-сайтов
https://habr.com/ru/post/340038/
ANTLR — генератор парсеров Bison — генератор парсеров
Coco/R —

генератор сканера и парсера GOLD — парсер
JavaCC — генератор парсеров для языка Java
Lemon Parser — генератор парсеров Lex — генератор сканеров
Ragel — генератор встраиваемых парсеров Spirit Parser Framework — генератор парсеров
SYNTAX Syntax Definition Formalism[en]
UltraGram VivaCore
Yacc — генератор парсеров
1. https://www.antlr.org/
2. https://jsonformatter.org/json-parser
Слайд 189

Разделение по стадиями ЖЦ ПО (ЗАДАНИЕ)

Разделение по стадиями ЖЦ ПО (ЗАДАНИЕ)

Слайд 190

ЗАДАНИЕ НА ГРУППОВУЮ РАБОТУ 1. Разделиться на группы до 5 человек.

ЗАДАНИЕ НА ГРУППОВУЮ РАБОТУ

1. Разделиться на группы до 5 человек.
2. Выбрать

ПО 1 ТЕМЕ ИЗ КАЖДОГО РАЗДЕЛА «Проектирование», «Разработка», «Сопровождение» (примечание: 4-ому курсу – 1 тему из одного любого раздела).
3. В разделе «Выводы» после каждого семейства ИСРПО в лекционной презентации найти аналоги технологий ИСРПО. Осуществить поиск дополнительных аналогов.
4. Кратко описать функционал всех аналогов. Описание сопровождать скринами из Интернета.
5. Выполнить критериальное сравнение аналогов в виде таблицы или сравнительных диаграмм. Сделать авторские выводы.
6. Реализовать любой понравившийся аналог. Протестировать его на конкретной задаче. Сделать скрины примеров реальной работы.