В прошлом семестре я прошел вводный курс по разработке программного обеспечения и был удивлен, насколько он меня заинтересовал. Заходя в него, я мало что знал об этом предмете. Я ожидал, что он будет сосредоточен на архитектуре кода и заимствует много концепций из моих прошлых курсов по структурам данных. Хотя я не совсем ошибся, «Введение в программную инженерию» оказалось гораздо большим, чем просто структура программы и перефразированные концепции; Я узнал о важности и предназначении инженеров-программистов и чем именно они отличаются от программистов и разработчиков.

Инженеры-программисты — это не просто программисты высокого уровня, но в то же время они не совсем подходят под общепринятое определение «инженер». Когда большинство людей слышат термин «инженер», они думают об инженере-строителе или инженере-механике, которые занимаются проектированием, анализом и строительством системы, будь то дороги, инфраструктура или даже электропроводка. Несмотря на то, что этим типам инженеров требуются разные навыки, теория, лежащая в их основе, такая же, как и разработка программного обеспечения; для создания чертежей системы. Перед инженером-программистом ставится задача создать для клиента определенное программное обеспечение, иногда веб-сайт, мобильное приложение и т. д. Следующим шагом является надлежащее распределение рабочей нагрузки внутри команды инженеров, состоящей из программистов, дизайнеров, системных архитекторов и других. Таким образом, инженер-программист должен задать себе вопрос: «Кто, что, как и когда может делать?»

Прежде чем будут установлены отдельные задачи, цель продукта должна быть определена простыми словами и понятна всем участникам. Это называется «определением проблемы» и является одним из трех основных направлений деятельности инженера-программиста. Думайте об отсутствии продукта как о проблеме. Чтобы определить проблему, нужно определить потребности решения, другими словами, что требуется для завершения продукта. Этот первый шаг можно охарактеризовать как «инженерию требований», и он достигается с помощью 7 задач: создание, выявление, разработка, обсуждение, спецификация, проверка и, наконец, управление требованиями. На первый взгляд эти задачи могут показаться непосильными, но на самом деле это всего лишь способ организовать требования к продукту по разным категориям.

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

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

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

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

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

Валидация — это этап проверки 7 задач. Во время проверки инженер ищет ошибки, недостающую информацию, неясные области, требующие уточнения, и так далее.

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

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

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

На этом этапе анализа важно понимать разницу между структурой и поведением. Модели вариантов использования ориентированы на поведение и описывают мотивы и ожидания пользователя при взаимодействии с системой, в то время как модели на основе классов ориентированы на структуру и фиксируют и документируют понимание инженером продукта, а также функциональность каждого класса. Модели предметной области перекрываются между структурой и поведением, поскольку они используются для описания поведения взаимодействующих предопределенных элементов внутри программного обеспечения и пользователя. Разница между структурой и поведением важна, потому что, по словам моего профессора, структура + поведение = программное обеспечение. Структура и поведение также имеют свое собственное уравнение; время + события = поведение и данные + управление = структура или поток данных + управление потоком = структура. Проще говоря; то, как программное обеспечение обрабатывает данные, предоставленные пользователем, делает программное обеспечение привлекательным или, по крайней мере, простым в использовании. Таким образом, к концу этапа анализа инженер-программист должен понимать поведение типичного пользователя, структуру, которую будет иметь программное обеспечение, и, самое главное, саму проблему.

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

Это не так запутанно, как кажется.

Думайте о классах сущностей как о буквальном классе людей. Сущностными объектами будут все люди в комнате, хотя они будут охарактеризованы как «профессор» и «студент», возможно, даже «помощник учителя». У учащихся есть разные способы взаимодействия с классом, например, задать вопрос, дать ответ и т. д. Эти взаимодействия с классом будут граничными объектами внутри граничного класса. Думайте о классе контроллера как о списке поведений или методов, которые должны быть у студентов или профессора. Несколько примеров методов, которые может иметь студенческий объект, могут быть «takeNotes(), askQuestion(), cryAlone(), reconsiderDegree() и т. д.».

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

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

  1. Пользователи, которые будут взаимодействовать с системой через интерфейс.
  2. Задачи, которые пользователи должны выполнять для выполнения своей работы.
  3. Контент представлен как часть интерфейса.
  4. Среда, в которой будут выполняться задачи пользователя.

Информация из этих четырех концепций называется «Анализ интерфейса», и с ее помощью инженер может перейти к разработке интерфейса. Инженер также должен использовать информацию из моделей вариантов использования, чтобы предсказать, как пользователи будут взаимодействовать с интерфейсом. Какие события приведут к изменению состояния пользовательского интерфейса? Как информация, полученная в результате анализа интерфейса, повлияет на интерфейсные объекты и действия? Ответы на эти вопросы могут быть разными, но они исходят из понимания поведения пользователя, которое будет формировать структуру интерфейса.

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