Руководство по формализации

Как мы ведём требования к ПО: формализация

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

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

Прежде всего зададим контекст. 

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

Типовая команда продукта состоит из:

• владельца продукта (product owner);

• команды разработки: системный аналитик, разработчики и тестировщик;

• часто к ним подключается дизайнер, отвечающий за проектирование пользовательского интерфейса;

• и архитектор, который помогает с проработкой архитектуры будущего решения.

Большинство продуктовых команд работают по Scrum со спринтами по 1-2 недели. У каждого спринта есть цель, которая связана с какой-то ценностью, в первую очередь, для клиента.

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

И здесь возникает формализация.

Этапы формализации требований

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

Сейчас расскажу, как это происходит. Общая схема проработки требований выглядит примерно так.

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

За определение потребностей бизнеса отвечает владелец соответствующего цифрового продукта (PO). Он общается с представителями бизнеса, изучает бизнес-процессы, проводит исследование рынка и формулирует бизнес-требования к продукту. У нас они обычно выражаются в виде документа Word (BRD) и эпиков (Epics) в Jira.

BRD содержит полное описание бизнес-требований, которым должен удовлетворять цифровой продукт. На основе данного документа и с учетом принятых архитектурных паттернов архитектор (Solution Architect) разрабатывает видение (Vision) архитектуры будущего решения. Ниже — общий вид BRD как пример.

Epics представляют собой набор отдельных бизнес-требований. Команда продукта (Product Team) проводит их анализ и декомпозицию на пользовательские истории (User Stories). Ниже — пример Epics и User Stories. Справа — Sab-Tasks (о них чуть дальше).

Каждая история характеризуется стейкхолдером, его потребностью и ценностью от её закрытия, критериями приёмки. Именно User Stories обычно и составляют основу бэклога текущего спринта команды. 

Однако на данном этапе их ещё нельзя брать в работу. Требования не до конца определены.

На основе Vision для User Stories системный аналитик (SA) разрабатывает проектные решения (Specs). 

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

При необходимости, для User Stories готовится дополнительный артефакт — дизайн пользовательских интерфейсов (UI). Для этого команда подключает к работе над продуктом дизайнера (Designer). Часто он ведёт разработку в Figma и помимо макетов пользовательского интерфейса готовит кликабельные прототипы для дальнейшей валидации требований. Ниже пример подобного UI.

Примечание: Дополнительно про прототипы в статье Использование прототипов в процессе разработки программных продуктов.

На основе Specs и UI команда разработки (DevTeam) выполняет декомпозицию User Stories на подзадачи (Sub-Tasks) для каждого члена команды. Пример Sub-Tasks на картинке.

Таким образом, бизнес-требования и требования стейкхолдеров определены, дизайн пользовательских интерфейсов и технических решений готов, перечень подзадач для их реализации сформирован. Остаётся только выполнить оценку User Stories, приоритезировать бэклог продукта и спланировать текущий спринт.

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

Но что произойдёт, если отклониться от процесса? Об этом расскажу дальше.

Отклонение от процесса

Правила существуют, чтобы их нарушать. А процессы — чтобы от них отступать. Время от времени продуктовые команды отклоняются от описанного процесса в надежде выпустить новую фичу как можно быстрее. Тогда схема проработки требований сократится до такого состояния.

Отклонения обычно проявляются в отказе от разработки технических артефактов — Vision и/или Specs.

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

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

Я — руководитель системных аналитиков. Мои ребята распределены по продуктовым командам. Однажды пришлось выслушивать недовольство PO одной из команд, связанное с двукратным увеличением оценки сроков проекта. Первичная оценка составляла три месяца. Но когда половина этого периода закончилась, пришло осознание, что необходимо полгода.

На протяжении нескольких спринтов одни и те же User Stories оставались в работе. Тот факт, что они не закрывались, говорит о том, что они не были проработаны должным образом. А DevTeam не до конца понимала требования к цифровому продукту.

Отсюда мы вывели правило — любое отклонение от процесса должно быть осознанным и обоснованным.

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

Итог

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

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

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

• Use Case VS User Story. Выбираем подход к специфицированию требований

• Георгий Савельев. Толковый бизнес-аналитик: Разработка бизнес-требований

• Демотивируй правильно! / Егор Бугаенко (Zerocracy)

---

Рекомендуем почитать [подборка редактора блога]

• Пять мифов о роботизации: как и зачем машинам делегируют рутину. Boston Dynamics не будет — мы больше про рутину: сканирование, распознавание, экономия минут и вот это всё.

• Скаутинг, fast track, пилоты, инновации? Выше было про роботов, а здесь — как их внедряют. Постарались без формальностей описать этот процесс.

• Ещё одна подборка книг по фронтенду. Без официальных аннотаций. Прочитали — рассказали чем интересно, и ещё цитат добавили.

• Взболтать, но не смешивать: как упаковать находки исследования, миксуя JTBD, CJM и компас персон. Большое исследование.

• BPMN не в теории, а на практике

• «Гигиенический минимум» в работе тимлида

• Как снимать логи с устройств на Android и iOS: разбираемся с инструментами

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.

Анонс: 13 декабря пройдёт Alfa Digital Open, где будем говорить о мобильных приложениях для клиентов и сотрудников, аналитике, кроссплатформенном цифровом банкинге и работу банка в городах без отделений. Присоединяйтесь!

Основные принципы формализации

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

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

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

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

Формализация — процесс построения
информационных моделей с помощью
формальных языков.

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

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

Примером неформального описания модели
является кулинарный рецепт или словесное
описание модели парусника, или словесная
формулировка второго закона Ньютона.

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

разработка неформального описания
модели (словесное описание существенных
для рассматриваемой задачи характеристик
изучаемого объекта и связей между ними);

составление формализованного описания
на некотором языке кодирования ( с
использованием математических соотношений
и текстов);

реализация формализованного описания
в виде программы на некотором языке
программирования.

Например, формула F=m*a является
формализованным описанием второго
закона Ньютона.

Модель– некоторое упрощенное
подобие реального объекта, который
отражает существенные особенности
(свойства) изучаемого реального объекта,
явления или процесса.

Моделирование – метод познания,
состоящий в создании и исследовании
моделей. Т.е. исследование объектов
путем построения и изучения моделей.

Формализация– процесс построения
информационных моделей с помощью
формальных языков.

Объект– некоторая часть
окружающего мира, рассматриваемого
человеком как единое целое. Каждый
объект имеет имя и обладает параметрами.

Параметр– признак или величина,
характеризующая какое-либо свойство
объекта и принимаемая различные значения.

Среда – условие существование
объекта.

Операция– действие, изменяющее
свойство объекта.

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

Структура– состав системы,
свойства её элементов, их отношения и
связи между собой.

Этапы моделирования:

• Постановка задачи: описание
  задачи, цель моделирования, формализация
  задачи

• Разработка модели: информационная
  модель, компьютерная модель

• Компьютерный эксперимент–
  план эксперимента, проведение исследования

• Анализ результатов моделирования

9.4. Формализация

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

Земля вращается вокруг своей оси и вокруг Солнца; орбиты всех планет проходят вокруг Солнца.

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

Одним из наиболее широко распространенных формальных языков является математический. Модели, сформированные с использованием математических понятий и формул, называются математическими моделями. Язык математики представляет собой совокупность формальных языков; о некоторых из них (алгебраическом, геометрическом) вы узнали в школе, с другими сможете познакомиться при дальнейшем обучении.

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

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

В процессе познания окружающего мира человечество постоянно прибегает к моделированию и формализации.

Формализация – это сведение некоторого содержания (содержания текста, смысла научной теории, воспринимаемых сигналов и пр.) к выбранной форме.

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

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

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

Из основного тезиса формализации следует сама идея моделирования.

Для обозначения объекта вводится некоторый набор знаков.

Знак – это элемент конечного множества отличных друг от друга элементов.

Основные черты знака:

1. Способность выступать в качестве заместителя объекта;

2. Неотождественность знака и объекта – знак никогда не может полностью заменить обозначаемое;

3. Многозначность соответствия «знак – объект».

Данный текст является ознакомительным фрагментом.

Что такое формализация? Метод формализации. Понятие, суть, этапы, результат, примеры, виды формализации

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

Что такое формализация с научной точки зрения в общем понимании?

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

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

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

Компьютерная формализация

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

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

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

Данные примеры доступно объясняют, что такое формализация.

Принципы моделирования объектов и процессов

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

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

Посмотрите, ведь та же теория относительности Эйнштейна тоже может быть трактована как метод формализации, ведь на практике проверить доказательство не представляется возможным. В частности это касается константы распространения света, замедления времени на пороге ее достижения, увеличения гравитационной массы объекта и искривления пространства. Руками, как говорится, это не пощупаешь и глазами не увидишь.

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

Этапы формализации

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

Иными словами, при моделировании поведения объекта или процесса суть происходящего нужно описать чисто математическими символами, применив математический алгоритм.

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

Далее следует концептуализация поставленной задачи. Здесь есть два варианта: в первом случае это определение подхода в виде использования атрибутов и признаков; второй вариант подразумевает применение когнитивного анализа, не говоря уже о постановке задачи, сбора начально используемых данных, условий и т. д.

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

Далее следует обработка начальных данных на основе выбранного алгоритма, после чего выдается результат с указанием процента погрешности. Как правило, она не превышает 5%, а в большинстве случаев результат вероятности доходит до 99%. Любой человек или машина все равно оставляют «запас прочности» на непредвиденные обстоятельства, ведь абсолютно все учесть невозможно.

Зачем все это нужно?

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

Теперь уже понятно, что такое формализация. Давайте рассмотрим простейший пример.

Применение формализации на практике, простейшие примеры

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

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

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

Основные результаты

Результат математического моделирования во многом (если не на все сто процентов, то с вероятностью до 95%) может стать весомым аргументом в пользу выпуска современной техники, поможет предсказать погоду, даже спрогнозировать общественное поведение как реакцию на события в мире.

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

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

Заключение

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

Источник

Формализованная модель обработки информации

Обработка информации

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

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

К примеру, начальная стадия информационного процесса — рецепция. В различных информационных системах рецепция выражается в таких конкретных процессах, как сбор и/или отбор информации (в системах научно-технической информации), преобразование физических величин в измерительный сигнал (в информационно-измерительных системах), раздражимость и ощущения (в биологических системах) и т. п.

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

Следует отметить, что, независимо от того, как «глубоко» будет отодвинута внутренняя граница, рецепцию всегда можно рассматривать как процесс классификации.

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

Рис. 2.1. Технологический процесс переработки информации в виде иерархической структуры по уровням

Используемые в производственной сфере такие технологические понятия, как «технологический процесс», «технологическая операция», «метрика», «норматив» и т. п. могут применяться и в ИТ. Для этого нужно начинать с определения цели. Затем следует попытаться провести структурирование всех предполагаемых действий, приводящих к намеченной цели, и выбрать необходимый программный инструментарий (рис. 2.1).

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

2-й уровень — операции, в результате выполнения которых будет создан конкретный объект в выбранной на 1-м уровне программной среде.

3-й уровень — действия, совокупность стандартных для каждой программной среды приемов работы, приводящих к выполнению поставленной в соответствующей операции цели.

4-й уровень — элементарные операции по управлению элементарными действиями объектов.

ИТ, как и другие технологии, должны отвечать следующим требованиям:

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

Традиционно в процессе обработки информации используются как измерительная аппаратура, обеспечивающая входные данные, так и собственно обрабатывающие (вычислительные) системы. И те и другие прошли длинную дорогу развития вместе с человеческой цивилизацией. В следующем пункте будут перечислены основные вехи их истории.

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

Предположим, вам надо сложить 1000 последовательных данных измерений. Заводим специальный счетчик-сумматор и присваиваем ему значение 0. Для каждого из данных надо получить результат измерений и добавить его к счетчику, то есть вам надо сделать 2001 операцию при «ручном» счете. Другой вариант — написать шесть инструкций для машины:

1. завести счетчик-сумматор и присвоить ему значение 0;
2. завести индекс (номер) текущей операции и присвоить ему значение 0;
3. получить новый результат измерений;
4. добавить его к счетчику-сумматору;
5. увеличить на 1 индекс текущей операции;
6. если он меньше 1000, то перейти к шагу 3.

За прошедшее время существенно усложнились задачи обработки информации, развились способы формулировки и записи правил работы машин (программ работы). Вычислительные устройства превратились в компьютеры, а правила работы — в компьютерные программы.

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

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

Составителями программ являются программисты. Большая часть работы программиста связана с написанием и отладкой исходного кода на одном из языков программирования.

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

Единственный язык, напрямую выполняемый процессором, — это машинный язык (также называемый машинным кодом). Изначально все программисты прорабатывали весь алгоритм в машинном коде, но сейчас эта трудная работа уже не делается. Вместо этого программисты пишут исходный код на языке высокого уровня (например, С, С++, С#, Java), а компьютер, используя компилятор или интерпретатор и уточняя все детали, транслирует его за один или несколько этапов в машинный код, готовый к исполнению на целевом процессоре. Если требуется полный низкоуровневый контроль над системой, программисты пишут программу на языке ассемблера, мнемонические инструкции которого преобразуются один к одному в соответствующие инструкции машинного языка целевого процессора.

В некоторых языках вместо машинного кода генерируется интерпретируемый двоичный код «виртуальной машины», также называемый байт-кодом (byte-code). Такой подход применяется в языке Forth, некоторых реализациях языков Lisp, Java, Perl, Python, а также в языках платформы Microsoft .NET.

Типичный процесс разработки программ состоит, в общем, из семи этапов:

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

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

Источник