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

Порядок разработки программного модуля

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

38.(Лера)Опишите инструментальные средства поддержки процесса документирования.

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

1. Текстовые редакторы - позволяют создавать и редактировать текстовые документы, такие как спецификации, инструкции, руководства и т.д. Примеры таких редакторов: Microsoft Word, Google Docs, LibreOffice Writer.

2. Системы управления версиями - позволяют отслеживать изменения в документах, сохранять различные версии и возвращаться к предыдущим версиям при необходимости. Примеры таких систем: Git, SVN, Mercurial.

3. Программы для создания диаграмм и схем - позволяют создавать графические изображения, которые могут использоваться для пояснения иллюстраций в документации. Примеры таких программ: Microsoft Visio, Lucidchart, Draw.io.

4. Средства для генерации документации на основе исходного кода - позволяют автоматически генерировать документацию на основе комментариев в исходном коде программного обеспечения. Примеры таких средств: Doxygen, Javadoc, Sphinx.

5. Электронные таблицы - позволяют организовать и анализировать большие объемы данных, такие как таблицы с техническими характеристиками или списки требований. Примеры таких программ: Microsoft Excel, Google Sheets, LibreOffice Calc.

6. Системы управления проектами - позволяют организовать процесс создания документации, назначать ответственных за ее создание и отслеживать прогресс. Примеры таких систем: Trello, Asana, Jira.

---

7. Средства обратной связи - позволяют получать обратную связь от пользователей документации, что помогает улучшить ее качество и актуальность. Примеры таких средств: Google Forms, SurveyMonkey, Typeform.

39.(Влад)Опишите процесс тестирования интерфейса пользователя средствами инструментальной среды разработки.

Пользовательский интерфейс - это программное обеспечение, которое

содержит набор инструкций, сообщений и других свойств, которые позволяют

устройству и пользователю взаимодействовать друг с другом. Это "лицо" системы, и

от его продуманности зависит эффективность работы пользователя с системой.

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

Требования к пользовательскому интерфейсу могут быть разбиты

на две группы:

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

формам взаимодействия с пользователем;

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

при помощи пользовательского интерфейса.

Ручное тестирование

Ручное тестирование пользовательского интерфейса проводится

тестировщиком-оператором, который руководствуется в своей работе

описанием тестовых примеров в виде набора сценариев. Каждый

сценарий включает в себя перечисление последовательности действий,

которые должен выполнить оператор, и описание важных для анализа

результатов тестирования ответных реакций системы, отражаемых в

пользовательском интерфейсе.

(Это как Сергей Сергеевич ломает нам программы вводом

неподходящих данных)

Сценарии на формальных языках (языках программирования)

Естественный способ автоматизации тестирования

пользовательского интерфейса - использование программных

инструментов, эмулирующих поведение тестировщика-оператора при

ручном тестировании пользовательского интерфейса.

Такие инструменты используют в качестве входной информации

сценарии тестовых примеров, записанные на некотором формальном

языке, операторы которого соответствуют действиям пользователя -

вводу команд, перемещению курсора, активизации пунктов меню и

других интерфейсных элементов.

(Это тесты, которые Серегей Сергеевич нам показывал в С#)

40.(Аня)Дайте определение понятия обработка исключительных ситуаций. Опишите инструменты среды разработки для обработки исключительных ситуаций.

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

---

Обработка исключительных ситуаций самой программой заключается в том, что при возникновении исключительной ситуации управление передаётся некоторому заранее определённому обработчику — блоку кода, процедуре, функции, которые выполняют необходимые действия.

Существует два вида исключений:

• 
  Аппаратные (структурные, SE-Structured Exception), которые генерируются процессором. К ним относятся, например,
  
  • 
    деление на 0;
    
  • 
    выход за границы массива;
    
  • 
    обращение к невыделенной памяти;
    
  • 
    переполнение разрядной сетки.
    
• 
  Программные, генерируемые операционной системой и прикладными программами – возникают тогда, когда программа их явно инициирует. Когда встречается аномальная ситуация, та часть программы, которая ее обнаружила, может сгенерировать, или возбудить, исключение.
  

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

41.( не понятно, что из этого брать)(Ася)Опишите методические аспекты проектирования ПО. Общие принципы проектирования систем.

Методические аспекты проектирования ПО:

Методические аспекты программного обеспечения включают в себя следующие основные принципы:
1. Анализ требований - процесс изучения потребностей и ожиданий пользователей, а также определение функциональных и нефункциональных требований к системе.

2. Проектирование - процесс создания архитектуры и дизайна системы, учитывая требования и потребности пользователей, а также удобство использования.

3. Разработка - процесс создания программного кода и тестирования системы на соответствие требованиям.

4. Тестирование - процесс проверки работоспособности системы и ее соответствия требованиям и ожиданиям пользователей.

5. Развертывание - процесс установки и настройки системы на серверах или компьютерах пользователей.

6. Обслуживание - процесс поддержки и обновления системы, включая исправление ошибок, добавление новых функций и улучшение производительности.

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

---

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

8. Обучение пользователей - процесс обучения пользователей работе с системой и ее функционалом, а также привыкания к новому интерфейсу и функциям.

Общие принципы проектирования систем:

1. Принцип единственной ответственности (Single Responsibility Principle, SRP) - каждый модуль должен иметь только одну задачу, за которую он отвечает.

2. Принцип открытости/закрытости (Open/Closed Principle, OCP) - программное обеспечение должно быть открыто для расширения, но закрыто для изменения.

3. Принцип разделения интерфейсов (Interface Segregation Principle, ISP) - клиенты не должны зависеть от интерфейсов, которые они не используют.

4. Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) - зависимости между компонентами должны быть установлены через абстракции, а не через конкретные реализации.

5. Принцип композиции/агрегации (Composition/Aggregation Principle, CAP) - при проектировании системы следует использовать композицию и агрегацию вместо наследования.

6. Принцип единообразия (Uniformity Principle) - все элементы системы должны быть единообразными и согласованными между собой.

7. Принцип минимальной избыточности (Principle of Least Astonishment, POLA) - система должна работать так, как ожидает пользователь, и не должна содержать ненужных или неожиданных элементов.

—-------_—----------------------------------------

Для охарактеризования аспектов проектирования ПО была введена аббревиатура SOLID:

• 
  S -- Single Responsibility (единственная ответственность): Для каждого класса важно определить единственное назначение, а все ресурсы, которые нужны для его реализации, следует инкапсулировать в данный класс и подчинить только единственной задаче.
  
• 
  O -- Open Closed (открытость/закрытость): Класс должен быть открыт для расширения, однако закрыт для изменений. То есть мы можем добавить в класс новую функциональность, однако не можем редактировать существующие функции так, чтобы они противоречили используемому коду.
  
• 
  L -- Liskov substitution (принцип подстановки Барбары Лисков): Согласно данному принципу, программисту следует соблюдать наследственность так, чтобы логика программного приложения нигде не нарушалась.(Наследственный класс не может изменить функционал родительского(имеются в виду не перегрузки, а прямое изменение поведения))
  
• 
  I -- Interface Segregation (принцип разделения интерфейсов): По принципу разделения интерфейсов класс должен обладать способностью реализовывать множество интерфейсов.(много интерфейсов, которые специально предназначены для клиентов, - это лучше, чем 1 интерфейс общего назначения.)
  
• 
  D -- Dependency Inversion Principles  (принцип инверсии зависимостей): Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций. Абстракции никогда не должны зависеть от деталей. Детали должны зависеть от абстракций.
  

---

Общие принципы проектирования систем.

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

1. 
   Слабая связанность – low coupling (количество связей между отдельными подсистемами должно быть минимальным);
   
2. 
   Сильное сцепление – high cohesion (связность отдельных частей внутри каждой подсистемы должна быть максимальной).
   

Так же структура ПО должна удовлетворять следующим требованиям:

1. 
   Каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
   
2. 
   Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
   

42.(Аня)Сформулируйте основные этапы документирования результатов тестирования.

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

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Последовательность проведения работ:

подготовка (Test Preparation),

тестирование (Testing),

анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.

Анализ результатов тестирования проводится периодически в процессе работы с проектом. Его основная задача - оценить текущее или финальное качество проекта и принять соответствующие решения и меры.

Документирование результатов тестирования состоит из следующих этапов:

Описание процесса тестирования (какие использовались методы, техники, инструменты и т.п.)

Статистика по ошибкам (перечисление количества и важности ошибок, их местоположение и статус (Исправлено/Не исправлено) )

43.(Лера)Перечислите стандарты качества программных средств.



44.(Влад)Опишите процесс выявление ошибок системных компонентов.

Меры по обнаружению ошибок можно разбить на две подгруппы:

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

---

Смотрите также файлы

• Письменная работа по дисциплине Иностранный язык.docx

• Практическая работа по дисциплине Основы предпринимательской деятельности.docx

• Создание макета вебсайта Russian Startup challenge.pdf

• Лекция 1 Правоохранительные органы.ppt

• Методические указания по оформлению печатных работ по дисциплинам кафедры экономики.doc