Вы находитесь на странице: 1из 20

Ответы на аттестацию 1

Парадигмы проектной организации

1) В чем разница между фрилансом и командной работой с точки зрения


используемых технологий и инструментов?
Работа фрилансером означает труд вне штата компаний, наподобие частной
практики. Как правило, фрилансеров привлекают для выполнение конкретного
проекта, за который специалист получает деньги. Сегодня так называют
специалистов, которые выполняют свою работу без заключения долговременного
договора с работодателем (внештатный работник). Среди фрилансеров можно
встретить как высококвалифицированных сотрудников, так и студентов. Выбирают
такой вид занятости люди, которые предпочитают нести ответственность только за
собственные результаты труда и не зависеть от других сотрудников, и планировать
свое время и рабочий график по собственному желанию. фриланс обходится
дешевле, а команда дороже. Когда фрилансер работает над проектом, то его клиент
может видеть продвижение по задачам и успевают ли они по срокам оговоренного
тайминга, в целом. Заказчик в таких ситуациях мысленно выдыхает, а исполнитель
не нуждается в постоянной отчетности.
2) Какую парадигму разработки продукта вы знаете? Чем они схожи и чем
отличаются друг от друга?
Четыре основные модели:
Модель водопада, также известная как традиционный жизненный цикл разработки
программного обеспечения (SDLC).
Спиральная модель
Модель инкрементального процесса
Модель гибкой разработки
Другие модели включают:
Построить и исправить модель
Линейная последовательная модель
5.09.2019 Парадигмы и модели программной инженерии Эссе по информационным
технологиям
https://www.uniassignment.com/essay-samples/information-technology/software-
engineering-paradigms-and-models-information-technology-essay.php 3/7
Модель прототипирования (Rapid prototyping model)
Модель фонтана
Модель трансформации
Модель быстрой разработки приложений (RAD)
Модель эволюционного процесса
Инженерная модель программного обеспечения для чистых помещений
Модель аспектно-ориентированной разработки программного обеспечения (AOSD)
Инженер-программист выбирает конкретную модель разработки программного
обеспечения в зависимости от характера проекта и приложения, которое он / она
планирует.
развивать. Используемые методы и инструменты, а также средства управления и
результаты зависят от выбранной модели.
В следующих подразделах мы представляем некоторые вышеупомянутые модели
(парадигмы) программной инженерии.
3) Каковы этапы разработки программного продукта в парадигме
«пошаговой» разработки (водопад)? Какие основные действия
запланированы?
Это требует систематического, последовательного подхода к разработке
программного обеспечения, который начинается с анализа требований через
планирование, проектирование,
кодирование, тестирование и доставка.
Модель водопада, созданная на основе инженерной модели, используется для
управления разработкой больших программных систем. Водопад
Модель визуализирована в виде блок-схемы на рисунке 1. Она состоит из
различных этапов, которые обрабатываются линейно. Шаги в
водопадный режим: анализ требований, планирование, дизайн, кодирование,
тестирование и доставка. Краткое описание фаз водопада
модель представлена ниже.
4) Каковы этапы разработки программного продукта в парадигме Rational
Unified Process (RUP)? Какие основные действия запланированы?
https://compress.ru/article.aspx?id=9633
5) Каковы этапы разработки программного продукта в парадигме
«гибкой» разработки? Какие основные действия запланированы?
Среди основных игроков в разработке программного обеспечения обсуждается
вопрос о том, насколько привлекать клиентов на разных этапах SDLC и
насколько перекрывать эти фазы. Это проблема, которая привела к разработке
модели разработки Agile. Мотивация
разработка модели Agile разработки - заказчик
Не всегда доволен продуктом, потому что он / она не соответствовал всем
ожидаемым требованиям, а инженеры не всегда
понять требования. Эта модель вовлекает клиента на всех этапах и дает
постоянную обратную связь по поводу
товар. В этой модели тестирование, корректность, валидация и верификация
разработанного компонента осуществляются вместе с заказчиком.
участие для удовлетворения его / ее потребностей.
Agile-модель включает только 4 этапа SDLC: планирование, проектирование,
кодирование и тестирование. На рисунке 5 показана гибкая разработка.
модель. Модель разработки программного обеспечения Agile способствует
итерациям разработки на протяжении всего жизненного цикла проекта.
Рисунок 5: Модель гибкой разработки
Модель разработки Agile, также известная как модель «экстремального
программирования», ориентирована исключительно на время выполнения проекта.
это
разработан, чтобы обеспечить выполнение программных проектов в кратчайшие
сроки. Следовательно, модели гибкой разработки подходят для Интернета.
разработчики приложений, требующие быстрой доставки системы.
Модель инкрементального процесса имеет следующие особенности:
Есть много гибких методов разработки; максимально минимизировать риски,
создавая программное обеспечение в короткие сроки.
Одна итерация в модели гибкой разработки - это программное обеспечение,
разрабатываемое за одну единицу времени.
Каждая итерация - это целый программный проект, включающий все этапы,
которые существуют в модели: планирование, анализ требований, проектирование,
кодирование, тестирование и документация.
Итерация не обязательно добавляет достаточно функциональности, чтобы
гарантировать выпуск продукта на рынок. Но в конце итерации
должен существовать доступный релиз (без ошибок).
В конце каждой итерации команда разработчиков повторно оценивает приоритеты
проекта.
Гибкие методы делают упор на общение лицом к лицу, а не на письменных
документах.
6) Сравните парадигмы разработки пошагового программного продукта с
итеративной. Каковы преимущества и недостатки каждого?
Пошагово = постепенно , поэтапно , а другое на мелкие проекты разделают
7) Сравните парадигмы разработки инкрементального программного
продукта с «гибкой». Каковы преимущества и недостатки каждого?
инкрем = много водопадов по частям Модель разработки Agile, также известная
как модель «экстремального программирования», ориентирована исключительно
на время выполнения проекта. это
разработан, чтобы обеспечить выполнение программных проектов в кратчайшие
сроки. Следовательно, модели гибкой разработки подходят для Интернета.
разработчики приложений, требующие быстрой доставки системы.
Модель инкрементального процесса имеет следующие особенности:
Есть много гибких методов разработки; максимально минимизировать риски,
создавая программное обеспечение в короткие сроки.
Одна итерация в модели гибкой разработки - это программное обеспечение,
разрабатываемое за одну единицу времени.
Каждая итерация - это целый программный проект, включающий все этапы,
которые существуют в модели: планирование, анализ требований, проектирование,
кодирование, тестирование и документация.
Итерация не обязательно добавляет достаточно функциональности, чтобы
гарантировать выпуск продукта на рынок. Но в конце итерации
должен существовать доступный релиз (без ошибок).
В конце каждой итерации команда разработчиков повторно оценивает приоритеты
проекта.
Гибкие методы делают упор на общение лицом к лицу, а не на письменных
документах.
8) Какие роли в проекте разработки программного обеспечения вы знаете?
Какие основные функции они выполняют?
https://econ.wikireading.ru/78494
9) Что общего и чем отличается между ролью в проекте и сотрудником?
Как решается разница между ролью и сотрудником?
https://www.businessstudio.ru/articles/article/praktika_ispolzovaniya_roley_dlya_modeli
rovaniya_b/
Требования к программному продукту и их менеджмент
1) В чем суть термина «заинтересованная сторона»(stakeholder)? Какова его
роль в проекте? Назовите кого-нибудь, кто связан с проектом, кого можно
назвать «Заинтересованным лицом» (stakeholder).

Стейкхолдер (stakeholder) — понятие, которое описывает человека, группу лиц или


отдельные организации, чьи действия, поведение или решения могут влиять на
успешность системы.

Стейкхолдеры — это “действующие лица” (как в театре) проекта, а исполнители этих


ролей — конкретные люди и организации.

o Партнеры - основные стейкхолдеры проекта, должны максимально привлекаться к


принятию решений в проекте. Необходимо повышать заинтересованность группы в
проекте и полностью удовлетворять ее потребности. Рекомендуется использовать
принцип партнерства в коммуникации при ведении переговоров по проекту с этой
группой.

o Консультанты - второстепенные стейкхолдеры. Их рекомендуется привлекать в


качестве консультантов и согласовывать с ними только важные стратегические
решения по проекту.

o Поддержка - второстепенные стейкхолдеры. Данная группа должна быть


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

o Временные работники - второстепенные стейкхолдеры. Рекомендуется


исключительно привлекать данную группу к выполнению требуемых задач, не
погружать ее в детали проекта и использовать самый низкий уровень
информирования. Стратегия "игнорирование".
2) Что общего и чем отличается потребность (необходимость - needs) от
требований (requirements) к программному продукту?
Требования к программному обеспечению — совокупность утверждений
относительно атрибутов, свойств или качеств программной системы, подлежащей
реализации. Создаются в процессе разработки требований к программному
обеспечению (ПО), в результате анализа требований. Требования могут выражаться в
виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на
стадии проектирования ПО. Требования также используются в процессе проверки
ПО, так как тесты основываются на определённых требованиях.
Потребность – область проблемы
3) Каковы основные источники требований к программному продукту?
Расставьте их с нескольких точек зрения.
· Федеральное и муниципальное отраслевое законодательство (конституция, законы,
распоряжения)
· Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
· Текущая организация деятельности объекта автоматизации
· Модели деятельности (диаграммы бизнес-процессов)
· Представления и ожидания потребителей и пользователей системы
· Журналы использования существующих программно-аппаратных систем
· Конкурирующие программные продукты
4) Что нужно, чтобы потребность превратилась в требование? Как осуществить
такое преобразование?
На стадии анализа осуществимости определяется стоимость требований.
Для пользовательских требований текущая стоимость работы сравнивается с
будущей стоимостью установленной системы. Задаются вопросы, такие как:
«Сколько нам сейчас стоят ошибки ввода данных?» или «Какова стоимость потери
данных из-за ошибки оператора связанной с используемым интерфейсом?».
Фактически, потребность в новом инструменте часто распознаётся, когда подобные
вопросы попадают во внимание людей, занимающихся в организации финансами.
Деловая стоимость включает ответы на такие вопросы, как: «У какого отдела есть
бюджет для этого?» «Каков уровень возврата средств от нового продукта на рынке?»
«Каков уровень сокращения внутренних расходов на обучение и поддержку, если мы
сделаем новую, более простую в использовании систему?»
Техническая стоимость связана со стоимостью разработки программного
обеспечения и аппаратной стоимостью. «Есть ли у нас нужные люди, чтобы создать
инструмент?» «Нуждаемся ли мы в новом оборудовании для поддержки новой
системы?»
Подобные вопросы очень важны. Группа должна выяснить, будет ли новый
автоматизированный инструмент иметь достаточную эффективность чтобы
перенести часть бремени пользователей на систему и экономить время людей.
Эти вопросы также указывают на основную суть управления требованиями. Человек
и инструмент формируют систему, и это понимание особенно важно, если
инструмент — компьютер или новое приложение на компьютере. Человеческий
разум крайне эффективен в параллельной обработке и интерпретации тенденций с
недостаточными данными. Компьютерный процессор эффективен в
последовательной обработке и точном математическом вычислении. Основная цель
управления требованиями для программного проекта состояла бы в том, чтобы
гарантировать, что автоматизируемая работа назначена «правильному» процессору.
Например, «не заставляйте
человека помнить, где она находится в системе. Заставьте интерфейс всегда сообщать
о местоположении человека в системе». Или «не заставляйте человека вводить те же
самые данные в два экрана. Заставьте систему хранить данные и заполнять их где
необходимо автоматически».
Результатом стадии анализа осуществимости является бюджет и график проекта.
5.Какие типы требований к программному продукту вам известны? Что у них
общего и чем они отличаются?

Функциональные требования описывают, как ведет себя система. Эти требования


обычно ориентированы на действия (“Когда пользователь делает x, система будет
делать y”). Большинство продуктов и приложений, предназначенных для выполнения
полезной работы, содержит множество функциональных требований к программному
обеспечению. Программное обеспечение используется для реализации большей части
функциональных возможностей.
Функциональные требования описывают, как система должна вес- ти себя, когда ей
предоставляются определенные входные данные или условия.
Нефункциональные требования
􏰀Практичность(Usability)
􏰀Надежность(Reliability)
􏰀Производительность(Performance)
􏰀Возможность обслуживания(Supportability)

Эти требования, как правило, используются для описания некоторых “атрибутов сис-
темы” или “атрибутов системного окружения” из нашего сложного определения.
Благо- даря их удобной классификации мы можем больше узнать о системе, которую
необходи- мо создать.
6) Какова цель управления требованиями к программному продукту и из чего
оно состоит? К какой роли в проекте принадлежит эта функция?
Управление требованиями к программному обеспечению (англ. software requirements
management) — процесс, включающий идентификацию, выявление,
документирование, анализ, отслеживание, приоритизацию требований, достижение
соглашения по требованиям и затем управление изменениями и уведомление
соответствующих заинтересованных лиц.

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


документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и
внутренних или внешних заинтересованных лиц. Управление требованиями
начинается с выявления и анализа целей и ограничений клиента. Управление
требованиями, далее, включает поддержку требований, интеграцию требований и
организацию работы с требованиями и сопутствующей информацией,
поставляющейся вместе с требованиями.
Какие артефакты задействованы в управлении требованиями программного
продукта? Какова цель каждого артефакта?
Артефакты — это некоторые продукты проекта, порождаемые или используемые в
нем при работе над окончательным продуктом.
Артефакты-модели — используется Rational Rose:
• модель бизнес-процессов — определение бизнес-требований к разрабатываемой
системе;
• модель структуры предприятия — артефакт для разработки функциональной
модели системы;
• модели документов, бизнес-сущностей, модели сценариев бизнес-функций,
модели состояний бизнес-сущностей — для проектирования пользовательского
интерфейса, БД системы; представляют собой описание статического и
динамического состояний системы с различных точек зрения;
• модели бизнес-правил — артефакт используется для моделирования правил в ПО.
Артефакты-документы — используются RequisitePro, SoDA, текстовые
процессоры, Microsoft Project:
• оценка организации заказчика, структура бизнеса;
• словарь терминов предметной области;
• набор бизнес-правил;
• коммерческое предложение;
• спецификации бизнес-функций;
• план работ на этапе бизнес-моделирования;
• рекомендации по проведению бизнес-моделирования;
• запросы на изменение.
Requirements
Артефакты-модели — используется Rational Rose:
• модель функции системы;
• модель сценариев функций системы;
• модель интерфейсов пользователя;
• модель сценариев работы пользователя системы;
• модель выходных форм;
• модель правил системы.
Артефакты-документы — используются RequisitePro, SoDA, текстовые
процессоры, MS Project:
• план управления требованиями;
• словарь терминов системы;
• спецификация на программную систему;
• спецификация на функции системы;
• правила системы;
• запросы заинтересованных лиц;
• план работ на этапе определения требований к системе;
• рекомендации по моделированию на этапе определения требований;
• запросы на изменение.
Analysis and design
Артефакты-модели — используется Rational Rose:
• логическая модель данных;
• физическая модель данных;
• модель спецификаций компонентов системы;
• сценарии взаимодействия классов, реализующих компоненты системы.
Артефакты-документы — используются RequisitePro, SoDA, текстовые
процессоры, MS Project:
• архитектура программного обеспечения;
• спецификации программных компонентов;
• рекомендации на этапе анализа и проектирования;
• план работ на этапе анализа и проектирования;
• запросы на изменение.
Implementation
Артефакты-модели — используется Rational Rose:
• компонентная модель приложения.
Артефакты-код — используются Rational Rose, средства программирования,
текстовые процессоры:
• элементы генерации кода, полученные в Rational Rose;
• собственно код приложения;
• документация.
Артефакты-документы — используются RequisitePro, SoDA, текстовые
процессоры, MS Project:
• план сборки приложения;
• план работ на этапе реализации.
Test
Артефакты-модели:
• модель тестовых примеров;
• функциональная модель тестовой программы;
• модель спецификации компонентов тестовой программы;
• сценарии взаимодействия классов, реализующих взаимодействие компонентов
тестовой программы.
Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:
• описание тестовых примеров;
• план тестирования;
• план работ на этапе тестирования;
• запросы на изменение.
Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad,
SiteCheck.
Deployment
Артефакты-модели — используется Rational Rose:
• модель размещения — описание размещения компонентов по узлам обработки.
Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:
• обучающие материалы;
• документы по инсталляции;
• описание версий системы;
• план внедрения.
Предложите рабочий процесс(workflow) для управления требованиями
программного продукта.
Процессы более низкого уровня описываются как микропроцессы, или рабочие
процессы (workflow), в результате которых возникают рабочие продукты. Термин
«рабочий процесс» используется для обозначения потока связных и в основном
последовательных действий. Рабочим процессам соответствуют рабочие продукты
и команды, работающие над проектом.
Существуют семь рабочих процессов самого верхнего уровня:.
1. Процесс управления проектом: контроль за ходом работ и гарантия условий
достижения успеха для всех заинтересованных сторон.
2. Процесс создания рабочей среды: автоматизация процесса и развитие среды
сопровождения и эксплуатации.
3. Процесс управления требованиями: анализ проблемной области и
совершенствование рабочих продуктов требований.
4. Процесс проектирования: моделирование решения и совершенствование
архитектуры и рабочих продуктов проектирования.
5. Процесс реализации: программирование компонентов и совершенствование
рабочих продуктов реализации и внедрения.
6. Процесс оценки: оценки тенденций и качества продукта.
7. Процесс внедрения: передача конечных продуктов пользователю
Какие отдельные и интегрированные инструменты вы предлагаете использовать
для управления требованиями программного продукта? Какие преимущества и
недостатки вы видите в их использовании?
Интегрированные:
Инструменты программирования
Эти инструменты состоят из сред программирования, таких как IDE
(интегрированная среда разработки), встроенных библиотек модулей и
инструментов моделирования. Эти инструменты предоставляют всестороннюю
помощь в создании программного продукта и включают функции для
моделирования и тестирования. Например, Cscope для поиска кода в C, Eclipse.

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


Программный прототип представляет собой смоделированную версию
предполагаемого программного продукта. Прототип обеспечивает первоначальный
внешний вид продукта и имитирует несколько аспектов реального продукта.
Инструменты для создания прототипов CASE в основном поставляются с
графическими библиотеками. Они могут создавать аппаратно-независимые
пользовательские интерфейсы и дизайн. Эти инструменты помогают нам создавать
быстрые прототипы на основе существующей информации. Кроме того, они
обеспечивают симуляцию программного прототипа. Например, композитор-
прототип Серены, конструктор макетов.

Отдельные:
Инструменты диаграммы
Эти инструменты используются для представления компонентов системы, данных
и потока управления между различными компонентами программного обеспечения
и структурой системы в графической форме. Например, инструмент Flow Chart
Maker для создания современных блок-схем.

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


Моделирование процесса — это метод для создания модели процесса
программного обеспечения, которая используется для разработки программного
обеспечения. Инструменты моделирования процессов помогают менеджерам
выбрать модель процесса или изменить ее в соответствии с требованиями
программного продукта. Например, EPF Composer

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


Эти инструменты используются для планирования проекта, оценки затрат и
усилий, планирования проекта и планирования ресурсов. Менеджеры должны
строго соблюдать выполнение проекта с каждым упомянутым этапом в управлении
программным проектом.Инструменты управления проектами помогают хранить и
обмениваться информацией о проектах в реальном времени по всей организации.
Например, Creative Pro Office, Trac Project, Basecamp.

Инструменты документации
Документация в программном проекте начинается до процесса разработки
программного обеспечения, проходит через все фазы SDLC и после завершения
проекта.
Инструменты документирования генерируют документы для технических
пользователей и конечных пользователей. Технические пользователи — это, в
основном, собственные специалисты команды разработчиков, которые ссылаются
на системное руководство, справочное руководство, учебное руководство,
руководства по установке и т. Д. Документы конечного пользователя описывают
функционирование и инструкции системы, такие как руководство пользователя.
Например, Doxygen, DrExplain, Adobe RoboHelp для документации.

Какие атрибуты потребуются для присвоения требованиям к программному


продукту? Мотивируйте ответ.
Атрибуты качества (quality attributes) представляют собой дополнительное
описание функций продукта, выраженное через описание его характеристик,
важных для пользователей или разработчиков. К таким характеристикам относятся
легкость и простота использования, легкость перемещения, целостность,
эффективность и устойчивость к сбоям.

Выявляя качественные характеристики, удовлетворяющие потребности клиента,


не ограничивайтесь только обсуждением функциональности. Выясните ожидаемые
производительность, эффективность, надежность, удобство использованичи др.
Информация от клиентов об относительной важности тех или иных качественных
характеристиках позволит разработчику принять правильные решения,
касающиеся архитектуры приложения.
Что такое иерархическая структура работ (Work Breakdown Structure - WBS) и
как ее можно использовать для определения дерева требований к программному
продукту?
WBS проекта (она же Work Breakdown Structure или ИСР, Иерархическая
Структура Работ) – это разбиение проекта на конкретные результаты, которые
должны быть достигнуты для достижения целей проекта.

Как правило, на верхнем уровне указывается сам проект, под ним (на первом
уровне) – основные результаты, каждый из которых, в свою очередь,
детализируется, то есть следующий уровень всегда меньше предыдущего по
объему работ и, как правило, включает 2 и более пакетов работ. При этом в разных
ветках WBS может быть разное количество уровней в зависимости от нужной
степени детализации.

1. WBS – если не единственный, но точно самый эффективный способ наглядно


отразить весь объем проекта.
2. WBS фокусирует внимание не на процессе а на ожидаемом результате, и
создает нужный «посыл».
3. В идеале в разработке WBS участвует заказчик или его представитель и вся
команда, что позволяет а) обеспечить единое понимание результатов проекта и его
объема б) увидеть важность и вклад отдельных элементов в общий результат
4. С помощью WBS можно наглядно обосновать необходимости в финансах
или человеческих ресурсах, так как против конкретного описанного объема
возражать гораздо сложнее, чем против «да что там системку написать, посадите
программиста и все».
5. WBS помогает предотвратить риски и изменения или по крайней мере
значительно (очень значительно!) снизить их вероятность и влияние, так как
именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем
другое» (и так и должно быть, для этого инструмент и предназначен).
6. На уровне WBS уже можно определить и согласовать контрольные точки
проекта (как для решений о продолжении проекта после очередного этапа, так и
для контроля затрат человеческих и финансовых ресурсов).
Что такое «сбалансированное» дерево требований и как его получить?
Внедрение программного продукта
1.В чем суть дилеммы - «коммерческое предложение» (Commercial-of-the-shelf
COTS) или «индивидуальное приложение»( Bespoke Application)?
Существует множество типов коммерческих программных приложений. Они
включают в себя специально разработанное, принадлежащее государству и
коммерческое готовое программное обеспечение (COTS). Программное
обеспечение COTS-это компьютерное приложение, которое можно приобрести на
коммерческой основе в большинстве торговых точек. Некоторые примеры этого
типа программного обеспечения включают Microsoft® Office и большинство
антивирусных пакетов. Программное обеспечение COTS обычно не требует каких-
либо изменений, потому что оно работает в готовом виде.

Общий:
• Оба подхода потребуют
усилий по развитию.
Разница:
• COTS может быть дешевле и быстрее

2.Какие подходы к процессу внедрения программного продукта вам известны?


Какие преимущества у каждого подхода? Как выбрать оптимальный подход к
реализации?
При использовании Entity Framework в приложении существует три подхода для
организации взаимодействия Entity Framework с базой данных: Code-First, Model-
First и Database-First, OBJECT-ORIENTED.(преимущества ниже)
(и Ad-Hoc наверно, ad-hoc testing — вид тестирования, который выполняется без
подготовки к тестам, без определения ожидаемых результатов, проектирования
тестовых сценариев. Это неформальное, импровизационное тестирование. Он не
требует никакой документации, планирования, процессов которых следует
придерживаться в выполнении. Также на данный вид тестирования не пишутся
тест-кейсы, что в свою очередь может вызвать определенные затруднения в
попытках воспроизвести дефект в системе. Такой вид зачастую может дать сходу
больше результата чем тестирование по заранее определенным сценариям. Это
обусловлено тем, что тестировщик на первых шагах приступает к тестированию
основного функционала и выполняет нестандартные проверки, точнее некоторые
из его проверок будут нестандартными.)

В объектно-ориентированном подходе основное внимание уделяется


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

Модель ОО полезна в следующих отношениях −


-Это облегчает внесение изменений в систему при низких затратах.
-Это способствует повторному использованию компонентов.
-Это упрощает задачу интеграции компонентов для настройки большой системы.
-Это упрощает проектирование распределенных систем.
ЭТАПЫ ООП
• Определите контекст и модели использования приложения (PCI)
• Определите архитектуру приложения (PA)
• Определите основные объекты приложения (PO)
• Разработка моделей дизайна
• Укажите интерфейсы объектов
3.Каков подход «Code-First» к реализации программного продукта?
Подход Code-First, который впервые появился в Entity Framework 4.1, обычно
используется, когда у вас есть уже существующее приложение, содержащее модель
данных. Эта модель, как правило, описывается с помощью нескольких классов и
кода взаимодействия между этими классами.
Подход Code-First появился позже подходов Model-First и Database-First и, как
вы уже поняли, больше всего подходит для разработчиков, которые хотят писать
код, а не работать с дизайнером модели EDM или средствами работы с базами
данных (SQL Server Management Studio и T-SQL).
Преимущества:
-Никакого генерированного кода
-База — это снова просто хранилище. Над ней не надо дрожать, дропается
легко и без проблем.
-Простейшая установка среды разработки. Выкачал код и запустил — никакой
возни с бэкапами.
Из презентации его:
БД не существует, и код сначала создаст ее / добавит новые таблицы.
Подход к рабочему процессу:
• Создание / изменение доменных классов
• Настройка классов и свойств домена
• Создание / обновление схемы БД с помощью автоматической или кодовой
миграции
Для Entity Framework есть Code First подход, где главным становится код, а не база.
4.Каков подход «Model-First» к реализации программного продукта?
Подход Model-First, впервые появившийся в версии Entity Framework 4,
применяется разработчиками, которые не хотят использовать инструменты СУБД
для создания и управления базами данных, а также не хотят вручную настраивать
классы модели EDM. Фактически это самый простой подход при работе с Entity
Framework. Проектирование модели происходит в графическом дизайнере EDM
среды Visual Studio. Вы могли наблюдать использование Model-First в предыдущей
статье, где мы создали простое приложение ASP.NET.
Рабочий процесс создания модели при подходе Model-First начинается в тот
момент, когда вы проектируете базу данных. При этом вам необходимы
минимальные знания устройства баз данных, например, для настройки отношений
между таблицами в графическом дизайнере или указания типов данных SQL полей
таблицы.
Как и в случае подхода Code-First, вся работа строится вокруг класса контекста
базы данных. Фактически, взаимодействие с базой данных в этих подходах
одинаковое. Например, для вставки объекта, используется следующая
последовательность действий:
-Создать объект модели и наполнить его данными.
-Создать класс контекста, унаследованный от DbContext (в подходе Code-First
это делается вручную, в Model-First этот класс генерируется автоматически вместе
с сущностными классами).
-Добавить объект в базу данных, используя класс контекста.
-Сохранить изменения.
Из презентации его:
Предположение: БД не существует, модель хранится в EDMXformat.
Подход к рабочему процессу:
• Модель данных сущностей (EDM) разработана с учетом сущностей, отношений и
иерархии
наследования.
• На основе EDM генерируется DDL-скрипт, а затем создается схема БД
• На основе EDM автоматически генерируются классы для взаимодействия с
приложениями
5.Каков подход «Database-First» к реализации программного продукта?
Подход Database-First, появившийся вместе c Entity Framework, позволяет писать
приложения для существующих баз данных. Базы данных в реальных приложениях
довольно быстро становятся сложными и пытаться создать модель для
существующей базы данных, которую могут понять разработчики, довольно
трудно. Еще тяжелее написать код использования модели, в котором происходит
взаимодействие с базой данных. Во многих отношениях, подход Database-First
является противоположностью подходу Model-First. При подходе Database-First
база данных уже существует, поэтому разработчик должен знать, где расположена
база данных, а также иметь информацию об имени базы данных. Тем не менее,
разработчик не должен понимать внутреннюю работу базы данных - Entity
Framework по-прежнему скрывает внутреннюю реализацию из поля зрения.
При этом подходе, рабочий процесс создания модели начинается с создания и
проектирования базы данных. После генерации сущностных классов модели из
существующей базы данных, работа с Entity Framework аналогична подходам
Code-First и Model-First. Это означает создание объекта класса контекста и
использование этого объекта для выполнения необходимых задач.
6.Какими способами можно повторно использовать программное обеспечение? В
чем их преимущества и недостатки?(Хрен пойми какие конкретные способы
есть)
Чтобы повторное использование ПО было эффективным, его необходимо
учитывать на всех этапах процесса проектирования ПО или процесса разработки
требований. Во время программирования возможно повторное использование на
этапе подбора компонентов, соответствующих требованиям. Однако для
систематического повторного использования необходим такой процесс
проектирования, в ходе которого постоянно рассматривалась бы возможность
повторного использования уже существующих архитектур, где система была бы
явно организована из доступных имеющихся компонентов ПО.
Альтернативой повторному использованию программных компонентов
является применение программных генераторов. Согласно этому подходу
информация, необходимая для повторного использования, записывается в систему
генератора программ с учетом знаний о той предметной области, где будет
эксплуатироваться разрабатываемая система. В данном случае в системной
спецификации должно быть точно указано, какие именно компоненты выбраны для
повторного использования, а также описаны их интерфейсы и то, как они должны
компоноваться. На основе такой информации генерируется система ПО

Повторное использование может обеспечить прогресс на следующих


направлениях:
Своевременность (timeliness) (в том смысле, который определен при
обсуждении показателей качества: быстрота доведения проектов до завершения и
продукции до рынка). При использовании уже существующих компонентов нужно
меньше разрабатывать, а, следовательно, ПО создается быстрее.
Сокращение объема работ по сопровождению ПО (decreased maintenance
effort). Если кто-то разработал ПО, то он же отвечает и за его последующее
развитие. Известен парадокс компетентного разработчика ПО: "чем больше вы
работаете, тем больше работы вы себе создаете". Довольные пользователи вашей
продукции начнут просить добавления новых функциональных возможностей,
переноса на новые платформы. Если не надеяться "на дядю", то единственное
решение парадокса - стать некомпетентным разработчиком, - чтобы никто больше
не был заинтересован в вашей продукции. В этой книге подобное решение не
поощряется.
Надежность. Получая компоненты от поставщика с хорошей репутацией, вы
имеете определенную гарантию, что разработчики предприняли все нужные меры,
включая всестороннее тестирование и другие методы контроля качества. В
большинстве случаев можно ожидать, что кто-то уже испытал эти компоненты до
вас и обнаружил все возможно остававшиеся ошибки. Заметьте, вовсе не
предполагается, что разработчики компонентов умнее вас. Для них создаваемые
компоненты - будь то графические модули, интерфейсы баз данных, алгоритмы
сортировки - это служебная обязанность, цель работы. Для вас это лишь
второстепенная, рутинная работа, поскольку вашей целью является создание
некоторой прикладной системы в вашей собственной области деятельности.
Эффективность. Факторы, способствующие возможности повторного
использования ПО, побуждают разработчиков компонентов пользоваться
наилучшими алгоритмами и структурами данных, известными в их конкретной
сфере деятельности. Однако в команде, разрабатывающей большой прикладной
проект, трудно ожидать наличия специалистов по каждой проблеме, затрагиваемой
в этом проекте. При разработке большого проекта невозможно оптимизировать все
его детали. Следует стремиться к достижению наилучших решений в своей
области знаний, а в остальном использовать профессиональные разработки.
Совместимость. Если использовать хорошую современную ОО-библиотеку, то ее
стиль повлияет, за счет естественного "процесса диффузии", на стиль разработки
всего ПО. Это существенно помогает повысить качество программного продукта.
Инвестирование. Создание повторно используемого ПО позволяет сберечь
плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в
постоянные.

7.Что такое программные компоненты (software) и что они предлагают при


внедрении программного продукта?
Понятие программного компонента (software component) является одним из
ключевых в современной инженерии ПО
Если речь идет об архитектуре ПО (или ведет ее архитектор ПО), под компонентом
имеется в виду то же, что часто называется программным модулем. Это достаточно
произвольный и абстрактный элемент структуры системы, определенным образом
выделенный среди окружения, решающий некоторые подзадачи в рамках общих задач
системы и взаимодействующий с окружением через определенный интерфейс. В этом
курсе для этого понятия употребляется термин архитектурный компонент или
компонент архитектуры.
Программный компонент – это автономный элемент программного обеспечения,
предназначенный для многократного использования, который может
распространяться для использования в других программах в виде скомпилированного
кода. ¥ Подключение к этим программам осуществляется с помощью интерфейсов
компонента
8.Что такое шаблоны проектирования (design patterns) и что они предлагают при
реализации программного продукта? Какие категории дизайнерских моделей вы
знаете?
Шаблон проектирования или паттерн (англ. design pattern) в разработке
программного обеспечения — повторяемая архитектурная конструкция,
представляющая собой решение проблемы проектирования в рамках некоторого
часто возникающего контекста.
*Проверенные решения. Вы тратите меньше времени, используя готовые решения,
вместо повторного изобретения велосипеда. До некоторых решений вы смогли бы
додуматься и сами, но многие могут быть для вас открытием
Примеры паттернов (MVC, MVP, MVVM)
*Стандартизация кода. Вы делаете меньше просчётов при проектировании,
используя типовые унифицированные решения, так как все скрытые проблемы в
них уже давно найдены.
*Общий программистский словарь. Вы произносите название паттерна, вместо
того, чтобы час объяснять другим программистам, какой крутой дизайн вы
придумали и какие классы для этого нужны.
9.Какова роль сторонних продуктов во внедрении программного продукта?
Какая от них польза?
Ключевыми элементами успеха является правильное определение целей проекта
внедрения, его задач, требуемый уровень качества, необходимое сочетание всех
видов ресурсов: человеческих, финансовых, временных и пр.
Сторонние продукты могут помочь в реализации финального, нужного вида
продукта. В оптимизации продукта, упрощения, ускорения работы.
Упрощает выполнение проекта и гарантирует, что в проекте с каждым следующим
этапом реализуется все больше запланированных задач.
10.Какое влияние оказывает инфраструктура проекта на процесс разработки?
Инфраструктура — это техническое и организационное обеспечение проекта. Для
проектирования и реализации необходимы аппаратные ресурсы и специальное ПО,
требуется механизм, позволяющий контролировать создаваемую документацию и
код.
Чем сложнее структура организации, чем больше ответвлений проекта, чем больше
специалистов или команд со специфической задачей, тем эффективнее разработка.
Тем проще локализировать проблемы на стадии производства и проще отыскивать
недочеты.
11.Какова цель управления версиями компонентов проекта?
Цель заключается в обеспечении корректного взаимодействия разных ответвлений
проекта при их соединении в единую рабочую систему. (пример сайта бэкэнд и
фронт)
12.Какова роль прототипирования программного продукта и когда он
используется?
Прототип – это простая экспериментальная модель предполагаемого решения,
используемая для тестирования идей, проектирования предположений и способов
использования продукта быстро и дешево и позволяющая вносить необходимые
уточнения и изменения в направление развития продукта.
Может использоваться на этапе контроля качества перед релизов.
13.Чем сборка (build) программного продукта отличается от выпуска (release) ?
Главное отличие между сборкой и выпуском в тестировании программного
обеспечения является то, что Build - это версия программного обеспечения,
которую команда разработчиков передает команде тестирования для целей
тестирования, а Release - это программное обеспечение, которое команда
тестирования передает клиенту.
Билд — это в буквальном переводе — "сборка". Т.е. берём срез исходников,
создаём некие deliverables, т.е. исполняемые файлы, конфиги, скрипты SQL и т.п.
Т.е. билд — полученные из исходников рабочие продукты. Создаётся как вручную
по требованию, так и автоматическими системами сборок по расписанию. Как
угодно, в общем — было бы что собирать.
Релиз — это билд, который команда разработчиков предоставляет наружу. В
качестве потребителя релиза может быть как команда тестеров, так и пользователи.
Соответствнно, внутренний релиз — это то, что отдаётся потребителю внутри
компании (или команды), внешний релиз — соответственно, отдаётся наружу.
Как правило, релиз создаётся на основе т.н. baseline, т.е. базиса, базовой
конфигурации. Команда, путём стабилизации свое работы, выбирает срез
исхдников, который может быть использован или как основа для синхронизации
всей команды (путём создания билда и его тестирования), или как основа для
создания релиза (путём, опять же, создания билда, его тестирования и проверки
соответствия критериям качества потребителя).
14.Что общего и чем отличается 1.фазовая интеграция, 2.инкрементная
интеграция и 3.непрерывная интеграция программного продукта?
Непрерывная интеграция – это практика разработки программного обеспечения
DevOps, при которой разработчики регулярно объединяют изменения программного
кода в центральном репозитории, после чего автоматически выполняется сборка,
тестирование и запуск.
При непрерывной интеграции разработчики часто подтверждают записи в совместно
используемый репозиторий, используя систему контроля версий, например Git. Перед
каждым подтверждением записи разработчики могут запускать локальные модульные
тесты программного кода в качестве дополнительного уровня проверки перед
интеграцией. Сервис непрерывной интеграции автоматически выполняет сборку и
запуск модульных тестов для изменений кода, что позволяет моментально выявлять
ошибки.
--фазовая интеграция - старые, новые и измененные компоненты, интегрируются
одновременно, но тяжело найти ошибки.
--Инкрементированный - код пишется и тестируется малыми кусочками и
добавляется часть, за частью.
--Непрерывная- Интеграция проводится автоматически с соответствующей
инфраструктурой(как правило ежедневно)
15.Каков период интеграции программного продукта, какой из них вы
предпочитаете и почему?

16.Какие отдельные и интегрированные инструменты вы предлагаете


использовать при реализации программного продукта?

Анализ и дизайн программного продукта

1) Каковы входные и выходные артефакты дизайна программного продукта?

2) Какие отдельные и интегрированные инструменты вы предлагаете для


использования при разработке программного продукта?