waterfall +/-
- +Работа ограничена сроками и команда всегда знает про четкий дедлайн.
- Команда понимает, что в процессе разработки требования меняться не будут.
- Команда может планировать работу на длительный период сразу на старте проекта.
- У команды есть детальная документация, по которой двигается весь проект.
- Главная задача команды — реализовать проект, уложившись в сроки и бюджет.
- -Продукт реализуется не гибким, потому что все требования были зафиксированы на старте работ.
- Заказчик не может вклиниться в какой-либо этап работ и, например, дать правки по дизайну.
- Пощупать продукт можно только после релиза, которого приходится ждать месяцами. А промежуточного варианта нет.
- Команда тестирования приступает к работе только на последнем этапе, а здесь может всплыть много багов и критических ошибок. А из-за правок релиз может сдвинуться.
Agile +/- - +Команда понимает, что нужно ежедневно работать над проектом в связке с заказчиком — на каждом этапе будут новые согласования и обсуждения.
- Команда готова к тому, что вводные или требования могут измениться на любом этапе проекта.
- Команда осознает, что каждый новый релиз не должен негативно влиять на предыдущий, а функционал будет постоянно работать.
- Команда постоянно совершенствует проект: его кодовую базу, дизайн-систему, саму методологию.
- Команда самоорганизована и каждый может принимать решения по продукту.
- -Решения обычно принимают самые активные участники команды — большинство людей по складу исполнители и не готовы нести ответственность.
- Команда постоянно думает о двух- или трехнедельных итерациях и спешит. Не всегда есть время, чтобы хорошо проработать решение и реализовать.
- Из-за работы в формате спринтов иногда страдает качество: кодовая база неидеальна, то же касается дизайн-работ и некоторых креативных решений. Менеджеру нужно закладывать время на доделывание.
- При запуске проекта практически невозможно рассчитать, сколько денег в итоге будет потрачено — требования могут постоянно меняться.
- Постоянные правки могут влиять и на конечное качество продукта. Разработка может не закончиться никогда и продукт всегда будет недоделанным.
- А еще правки демотивируют команду и менеджеру нужно дополнительно работать над мотивацией.
interacionnaja sistema +/- - +В жизненном цикле разработки программного обеспечения можно заранее создать несколько возможностей.
- Он эффективно универсален для постоянно меняющихся требований проекта, а также клиента.
- Это лучшее, что подходит для проворных компаний.
- Кроме того, по разумной цене можно изменить диапазон спецификаций в Итерационной модели.
- Совместное развитие может быть организовано.
- Изучение и устранение неполадок, в то время как меньше итераций просто.
- Опасности распознаются и исправляются путем итерации, и каждая итерация может быть просто обработана.
- В модели итерации сжатое время расходуется на запись, а расширенное время предоставляется для обрисовки.
– - -Могут потребоваться расширенные ресурсы.
- Несмотря на то, что цена изменения ниже, она не всегда соответствует спецификациям изменения.
- Требуется дополнительное признание администрации.
- Это не подходит для более коротких проектов.
- Для экспертизы способностей требуются чрезвычайно опытные ресурсы.
- Продвижение проекта в значительной степени зависит от этапов оценки рисков.
спиральная модель +/- - Плюсы и минусы спиральной модели:
- + улучшенный анализ рисков;
- + хорошая документация процесса разработки;
- + гибкость – возможность внесения изменений и добавления новой функциональности даже на относительно поздних этапах;
- + раннее создание рабочих прототипов.
- — может быть достаточно дорогой в использовании;
- — управление рисками требует привлечения высококлассных специалистов;
- — успех процесса в большой степени зависит от стадии анализа рисков;
- — не подходит для небольших проектов.
- Когда использовать спиральную модель:
- – когда важен анализ рисков и затрат;
- – крупные долгосрочные проекты с отсутствием четких требований или вероятностью их динамического изменения;
- – при разработке новой линейки продуктов.
инкриминантноя модель +/- - +
- олучение функционального продукта после реализации каждого инкремента;
- предотвращение формирования громоздких перечней требований;
- стабилизация требований во время создания определенного инкремента, за счет короткой продолжительности создания инкремента, включения в процесс пользователей и возможности отодвигания не важных изменений на последующие инкременты;
- улучшение понимания требований для более поздних инкрементов, за счет практической работы с ранее разработанными инкрементами;
- упрощение тестирования инкрементов по сравнению с продуктами промежуточных уровней при разработке систем по методу нисходящего проектирования;
- —
- непредусмотренность итераций в рамках каждого инкремента модели;
- необходимость полного функционального определения системы в начале жизненного цикла, чтобы обеспечить определение инкрементов и управление проектом;
- недостаточно чёткое определение требований;
- необходимость в четко определенных интерфейсах между модулями, связанная с различными сроками их создания;
- сложность формального анализа и проверки отдельных инкрементов;
- наличие тенденции к оттягиванию решения трудных проблем на поздние инкременты, что может нарушить график работ;
- отсутствие снижения общих затрат на выполнение проекта;
- возможность изменений в технологиях работ, что может нарушить график работ;
- нежелательность для руководства использования на этапе анализа общих целей вместо полностью сформулированных требований;
- возможность текущего изменения требований к системе, которые уже реализованы в предыдущих инкрементах;
- необходимость хорошего планирования и проектирования, грамотного распределения работы;
- ограниченность привлечения ресурсов на длительный срок.
rabota nad oshibkami
3.sistema ischelslenija javlaetsa prinatij sposob zapisi chisel
6. правило, описывающее отображение набора знаков одного алфавита в набор знаков другого
алфавита.
7.N=2i
8.733276738669
9.В процессе преобразования растрового графического изображения количество цветов уменьшилось с 4 096 до 16. Во сколько раз уменьшится его информационный объем? в 3 раза
11.количество информации,которое используется для кодирования цвета точки изображения Что называется глубиной цвета?
13.Графические изображения преобразуются путем пространственной дискретизации: из аналоговой формы в цифровую
12.объект (линия и т.д.);
14. На что разбивается непрерывная звуковая волна? На отдельные маленькие временные участки
15. Частота дискретизации – это… количество измерений уровней громкости звука за секунду
16.На что заменяется непрерывная амплитуда сигнала? На дискретную последовательность уровней громкости
17.Из каких цветов состоит растровое изображение(в простейшем случае)? черный, белый
1 tund https://scratch.mit.edu/projects/763870570
…
Декларативное программирование
это парадигма программирования, в которой задаётся спецификация решения задачи: описывается, что представляет собой проблема и ожидаемый результат, но без описания способа достижения этого результата.
При создании HTML мы с помощью тегов описываем, какую хотим получить страничку в браузере, а не то, как нарисовать на экране заголовок статьи, оглавление и текст.
В SQL, если нам нужно посчитать количество сотрудников с фамилией «Сидоров», мы напишем SELECT count(*) FROM employee WHERE last_name = ‘Сидоров’;.
Структурное программирование
делает текст программы более понятным – алгоритм решения ясно
виден из исходного текста.
Согласно принципу модульности программа разбивается на отдельные смысловые части (модули).
Модуль – это функционально законченная часть программы. Например, модуль вычисления
определителя матрицы; модуль нахождения суммы элементов ряда.
Каждый модуль программируется отдельно, а затем модули объединяются в единую программу.
Модуль на языке программирования – это функция или процедура.
Использование при разработке модуля композиции трех базовых структур
´Линейной
´Ветвления
´Циклической Структурное программирование называют программированием без GOTO.
Функциональное программирование
Смысл в том, что мы задаём не последовательность нужных нам команд, а описываем взаимодействие между ними и подпрограммами.
В нём весь код — это правила работы с данными. Вы просто задаёте нужные правила, а код сам разбирается, как их применять.
Команды можно собирать в подпрограммы, но их последовательность не имеет значения. Нет разницы, в каком порядке вы напишете подпрограммы — это же просто правила, а правила применяются тогда, когда нужно, а не когда про них сказали.
Логическое программирование
´парадигма программирования, а также раздел дискретной математики изучающий методы и возможности этой парадигмы, основанная на выводе новых фактов из данных фактов согласно заданным логическим правилам.
´Логическое программирование возникло как упрощение функционального программирования для математиков и лингвистов, решающих задачи символьной обработки.
Объектно-ориентированное программирование
Суть ООП заключается в том, чтобы представить программу в виде объектов, которые каким-то образом взаимодействуют друг с другом.
Объект — это экземпляр какого-то класса.
Класс — это шаблон, в котором описаны все свойства будущего объекта и его методы.
При этом если класс воздушного шарика определяет свойство цвет, то сам класс никакого значения цвета не имеет. Но экземпляры этого класса, которых, к слову, можно создавать сколько угодно, уже будут раскрашены в любые цвета.
Tean float,int,input,print,if,else,elif,except,while,while true,for,in