Этапы разработки ПО
1. Описание потребностей и их анализ
2. Дизайн программного продукта
3. Разработка
4. Проверка
5. Выпуск и внедрение продукта
6. Обслуживание продукта
Модели жизненного цикла ПО
1. Waterfall (каскадная модель)
Чем плох Waterfall: 1. очень много документов; 2. пользователя и заказчика полностью изолируют от процесса разработки; 3. все требования должны быть сразу известны; 4. из-за того, что в Waterfall тестирование происходит только в самом конце, проектом могут заниматься некомпетентные специалисты, и этого никто не заметит, пока не станет поздно.
Чем хорош Waterfall: 1. устойчива к обновлению кадров; 2. дисциплинирует, благодаря плану и чёткой последовательности этапов и строгому менеджменту, 3. Гибкая на ранних этапах, до этапа разработки можно вполне легко вносить изменения в предыдущие этапы; 4. прозрачна, заранее понятно, на каком этапе что будет происходить, поэтому становится проще прогнозировать бюджеты и набирать команду.
2. Итерационная модель
Чем хороша Итерационная модель: 1. В жизненном цикле разработки программного обеспечения можно заранее создать несколько возможностей; 2. Он эффективно универсален для постоянно меняющихся требований проекта, а также клиента; 3. Это лучшее, что подходит для проворных компаний; 4. Кроме того, по разумной цене можно изменить диапазон спецификаций в Итерационной модели; 5. Совместное развитие может быть организовано; 6. Изучение и устранение неполадок, в то время как меньше итераций просто; 7. Опасности распознаются и исправляются путем итерации, и каждая итерация может быть просто обработана; 8. В модели итерации сжатое время расходуется на запись, а расширенное время предоставляется для обрисовки.
Чем плоха Итерационная модель: 1. Могут потребоваться расширенные ресурсы; 2. Несмотря на то, что цена изменения ниже, она не всегда соответствует спецификациям изменения; 3. Требуется дополнительное признание администрации; 4. Это не подходит для более коротких проектов; 5. Для экспертизы способностей требуются чрезвычайно опытные ресурсы; 6. Продвижение проекта в значительной степени зависит от этапов оценки рисков.
3. Спиральная модель
Чем хороша Спиральная модель: 1. наличие действий по анализу рисков, что обеспечивает их сокращение и заблаговременное определение непреодолимых рисков; 2. обеспечение разбиения большого потенциального объема работ по выполнению проекта на небольшие части; 3. первоочередность реализации решающих функций с высокой степенью риска, что позволяет при необходимости остановить работы над проектом на ранних циклах модели и уменьшить расходы; 4. возможность гибкого проектирования, основанная на преимуществах каскадной модели при одновременном разрешении итераций; 5. реализация преимуществ инкрементной модели (выпуск инкрементов, сокращение графика работ, неизменяемость ресурсов при постепенном росте системы); 6. реализация связи с пользователем с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества; 7. возможность оценки системы пользователем на ранних этапах, за счет использования в жизненном цикле разработки ускоренного прототипирования; 8. возможность пользователям принимать участие при планировании, анализе рисков, проектировании, разработке, выполнении оценочных действий; 9. усовершенствование административного управления процессами жизненного цикла разработки, затратами, соблюдением графика и кадровым обеспечением, что достигается путем выполнения анализа (обзора) в конце каждой итерации; 10. повышение производительности за счет использования пригодных для повторного использования результатов; 11. повышение вероятности предсказуемого поведения системы с помощью уточнения поставленных целей; 12. отсутствие необходимости в предварительном распределении всех нужных для выполнения проекта финансовых ресурсов; 13. возможность регулярной оценки совокупных затрат, что в результате приводит к их общему сокращению.
Чем плоха Спиральная модель: 1. высокая стоимость модели за счет стоимости и дополнительных временных затрат на планирование, определение целей, выполнение анализа рисков и прототипирование при прохождении каждого цикла спирали; 2. неоправданно высокая стоимость модели для проектов, имеющих низкую степень риска или небольшие размеры; 3. усложненность структуры модели, что приводит к сложности ее использования разработчиками, менеджерами и заказчиками; 4. необходимость в высокопрофессиональных знаниях для оценки рисков; 5. возможность отдаления окончания работы над проектом в связи с желанием заказчика улучшать каждую созданную версию; 6. необходимость в обработке дополнительной документации за счет большого количества промежуточных циклов; 7. необходимость в четком распределении работ между разработчиками; 8. сложность определения критериев для продолжения процесса разработки на следующей итерации; 9. необходимость мощных инструментальных средств и методов прототипирования.
4. Инкрементная модель
Чем хороша Инкрементная модель: 1. получение функционального продукта после реализации каждого инкремента; 2. предотвращение формирования громоздких перечней требований; 3. стабилизация требований во время создания определенного инкремента, за счет короткой продолжительности создания инкремента, включения в процесс пользователей и возможности отодвигания не важных изменений на последующие инкременты; 4. улучшение понимания требований для более поздних инкрементов, за счет практической работы с ранее разработанными инкрементами; 5. упрощение тестирования инкрементов по сравнению с продуктами промежуточных уровней при разработке систем по методу нисходящего проектирования; 6. возможность пересмотра рисков, связанных с затратами и соблюдением установленного графика, в конце каждой инкрементной поставки; 7. снижение риска неудачи и изменения требований; 8. распределение риска между несколькими небольшими инкрементами, что сокращает его общую величину; 9. снижение затрат на первоначальную поставку программного продукта; 10. возможность управляемого распределения денежных средств с учетом важности реализуемых в инкременте функций; 11. ускорение начального графика поставки и графика всего проекта в целом; 12. возможность выравнивания графика распределения рабочей силы посредством распределения по времени объема работы над проектом, что в итоге приводит к сокращению общего количества разработчиков; 13. упрощение работы над проектом при смене состава разработчиков. 14. возможности поддержки постоянного прогресса продукта, разработчиков и технологий в ходе выполнения проекта; 15. постепенное привыкание заказчика к системе; 16. возможность оценки заказчиком самых важных функциональных возможностей продукта на более ранних этапах разработки; 17. незначительное время разработки каждого инкремента, что упрощает работу с потребностями заказчика. 18. необходимость изначального использования характеристик системы; 19. пригодность для использования промежуточного продукта; 20. естественное разделение системы на наращиваемые компоненты (инкременты); 21. возможности наращивания привлекаемого персонала и средств.
Чем плоха Инкрементная модель: 1. непредусмотренность итераций в рамках каждого инкремента модели; 2. необходимость полного функционального определения системы в начале жизненного цикла, чтобы обеспечить определение инкрементов и управление проектом; 3. недостаточно чёткое определение требований; 4. необходимость в четко определенных интерфейсах между модулями, связанная с различными сроками их создания; 5. сложность формального анализа и проверки отдельных инкрементов; 6. наличие тенденции к оттягиванию решения трудных проблем на поздние инкременты, что может нарушить график работ; 7. отсутствие снижения общих затрат на выполнение проекта; 8. возможность изменений в технологиях работ, что может нарушить график работ; 9. нежелательность для руководства использования на этапе анализа общих целей вместо полностью сформулированных требований; 10. возможность текущего изменения требований к системе, которые уже реализованы в предыдущих инкрементах; 11. необходимость хорошего планирования и проектирования, грамотного распределения работы; 12. ограниченность привлечения ресурсов на длительный срок.
5. Agile
Чем хороша Agile: 1. тестирование на ранних стадиях; 2. возможность оценки добавленного функционала “в действии”; 3. исследование пользовательского опыта на всех этапах; 4. возможность быстрой презентации на рынке “сырой”, но работающей версии.
Чем плоха Agile: 1. отсутствие четкого плана развития проекта; 2. постоянная угроза переделывания большой части работы; 3. снижение качества продукта в угоду скорости и упрощения.
Типы ошибок при тестировании
1. Логические – баг, который приводит к некорректной работе программы, но не к краху программы.
2. Синтаксические – связаны с неправильным приминением тех или иных алгоритмических конструкций
3. Семантические – это ошибки, связанные с неправильным содержанием действий и использованием недопустимых значений величин.
Количество цветов в палитре (N) и количество информации, необходимое для кодирования каждой точки (i), связаны между собой и могут быть вычислены по формуле:
a. I=N2
b. N=2 ∙ i
c. N=2i (этот ответ правельний)
d. 2=Ni
e. I=N ∙ 2
В соответствии с кодовой таблицей ASCII символы английского алфавита кодируются
двузначными числами, причем сочетание «I LOVE» кодируется так 733276798669, а
сочетание «I LIVE»:
1. 763273737686
2. 733276738669 (этот ответ правельний)
3. 733279768669
4. 733276867669
5. 733273768669
На что разбивается непрерывная звуковая волна?
1. На отдельные маленькие временные участки (этот ответ правельний)
2. На интервалы
3. На непрерывную амплитуду
4. На отрезки
Единица измерения частоты дискретизации –
a. Гц этот ответ правельний (этот ответ правельний)
b. Мб
c. Кц
d. Кб
Что является минимальным объектом, используемым в векторном графическом редакторе?
a. знакоместо (символ).
b. Точка экрана (пиксель); (этот ответ правельний)
c. объект (линия и т.д.);
d. палитра цветов;
Основные модели программирования
Императивное программирование
это парадигма, основанная на составлении алгоритма действий (инструкций/команд), которые изменяют состояние (информацию/данные/память) программы. Первыми языками программирования, основанными на таком подходе, были машинные коды и ассемблеры.
Фактически, программа на этих языках — это код, который выполняется компьютером сразу, без предварительной компиляции.
Декларативное программирование
это парадигма программирования, в которой задаётся спецификация решения задачи: описывается, что представляет собой проблема и ожидаемый результат, но без описания способа достижения этого результата.
При создании HTML мы с помощью тегов описываем, какую хотим получить страничку в браузере, а не то, как нарисовать на экране заголовок статьи, оглавление и текст.
В SQL, если нам нужно посчитать количество сотрудников с фамилией «Сидоров», мы напишем SELECT count(*) FROM employee WHERE last_name = ‘Сидоров’;.
Структурное программирование
делает текст программы более понятным – алгоритм решения ясно
виден из исходного текста.
Согласно принципу модульности программа разбивается на отдельные смысловые части (модули).
Модуль – это функционально законченная часть программы. Например, модуль вычисления
определителя матрицы; модуль нахождения суммы элементов ряда.
Каждый модуль программируется отдельно, а затем модули объединяются в единую программу.
Модуль на языке программирования – это функция или процедура.
Использование при разработке модуля композиции трех базовых структур
Линейной
Ветвления
Циклической
Структурное программирование называют программированием без GOTO.
Функциональное программирование
Смысл в том, что мы задаём не последовательность нужных нам команд, а описываем взаимодействие между ними и подпрограммами.
В нём весь код — это правила работы с данными. Вы просто задаёте нужные правила, а код сам разбирается, как их применять.
Команды можно собирать в подпрограммы, но их последовательность не имеет значения. Нет разницы, в каком порядке вы напишете подпрограммы — это же просто правила, а правила применяются тогда, когда нужно, а не когда про них сказали.
Логическое программирование
´парадигма программирования, а также раздел дискретной математики изучающий методы и возможности этой парадигмы, основанная на выводе новых фактов из данных фактов согласно заданным логическим правилам.
´Логическое программирование возникло как упрощение функционального программирования для математиков и лингвистов, решающих задачи символьной обработки.
Объектно-ориентированное программирование
Суть ООП заключается в том, чтобы представить программу в виде объектов, которые каким-то образом взаимодействуют друг с другом.
Объект — это экземпляр какого-то класса.
Класс — это шаблон, в котором описаны все свойства будущего объекта и его методы.
При этом если класс воздушного шарика определяет свойство цвет, то сам класс никакого значения цвета не имеет. Но экземпляры этого класса, которых, к слову, можно создавать сколько угодно, уже будут раскрашены в любые цвета.
Компонентно-ориентированное программирование
Парадигма программирования, существенным образом опирающаяся на понятие компонента — независимого модуля исходного кода программы, предназначенного для повторного использования и развёртывания и реализующегося в виде множества языковых конструкций, объединённых по общему признаку и организованных в соответствии с определёнными правилами и ограничениями.
Прототипно-ориентированное программирование
стиль объектно-ориентированного программирования, при котором отсутствует понятие класса, а наследование производится путём клонирования существующего экземпляра объекта — прототипа. Каноническим примером прототип-ориентированного языка является язык Self.
Самые популярные языки
JavaScript, а также его библиотеки и фреймворки (React, Angular JS, Vue JS, Node JS, JQuery) – прототипно-ориентированное программирование, применяемое для разработки клиентской части вэб-сайтов;
Java – объектно-ориентированное программирование (ООП), применяется для разработки десктопных и мобильных приложений под Андроид;
Python – процедурное программирование и ООП. Применяется как в вэб, так и десктопной разработке;
PHP (для серверной веб разработки) – процедурное и ООП;
С# – ООП, для программирования игр, софта и вэб-приложений;
Swift – программирование для IOS;
Obective-C – программирование для IOS и MAC OS.
Алгоритм
это точное и понятное предписание (указание) исполнителю совершить определенную последовательность действий, направленных на достижение указанной цели или решение поставленной задачи.
СВОЙСТВА АЛГОРИТМОВ
1. Дискретность.
2. Понятность (определенность).
3. Однозначность (детерминированность).
4. Массовость
5. Результативность (конечность).
6. Правильность.
Виды алгоритмов
Линейный – все действия выполняются в строгой последовательности(приготовление пирога)
Разветвляющийся – действия выполняются в зависимости от выполнения или не выполнения условия(переход улицы по светофору)
Циклический – содержит повторяющиеся действия(колоть дрова)
Условные графические обозначения символов
Переменные
В ходе программирования обычно необходимо запоминать некоторое количество данных.
Эти значения приходится держать в памяти. Для этого объявляется место в памяти, которое используется для хранения данных и это объявленное место называется переменной.
При объявлении переменной, объявляется и тип данных, которые будут храниться в этой переменной (тип переменной).
