Перевод «TBD» на русский
To give the material plasticity, they added a chemical called 1,5,7-triazabicyclo[4.4.0]dec-5-ene (TBD).
Для придания ему пластичности в него был добавлен пластификатор 1,5,7-triazabicyclo [4.4.0] dec-5-ene (TBD).
Abbreviations: N/A, not applicable; TBD, to be determined.
Сокращения: НП — не применимо; БОП — будет определено позднее.
The exact timing on this is still TBD, but I’m guessing we’ll see it before year-end.
Точное время на этом все равно TBD, но я предполагаю, что мы увидим его до конца года.
Though the TBD had only entered service in 1937, it was quickly being outclassed as aircraft development rapidly advanced.
Хотя TBD лишь вступил в строй в 1937 году, он уже не соответствовал требованиям времени, так как прогресс далеко продвинулся.
Where things go from here are, as they say TBD (to be determined).
В общем, как говорят в Америке, TBD (to be determined = будет определено).
We have 96 blogs and news sites already signed up for the TBD Community Network, and we still have our sights set on dozens more.
Участниками сетевого сообщества TBD уже стали 96 блогов и новостных сайтов, и мы знаем о существовании еще десятков подобных ресурсов.
Many planes «Hornet» could not reach the target and the wave merging in 41 «Douglas» TBD lost 35 aircrafts.
Многие самолеты «Хорнета» не смогли выйти на цель, а объединенная волна в 41 «Дуглас» TBD, вступившая вдело в 10.18, потеряла 35 самолетов.
Between 0930 and 1030, Douglas TBD Devastator torpedo bombers from the three American carriers attacked the Japanese carriers.
В промежуток времени между 9.30 и 10.30, торпедоносцы Дуглас TBD («Devastator») с трёх американских авианосцев атаковали японские авианосцы.
Personally, I wouldn’t trust any vault associated with the COMEX, and I believe it is a very bad idea for TBD to be considering a partnership with the CME Group.
Лично я не стал бы доверять ни одному хранилищу, ассоциируемому с СОМЕХ, и считаю очень плохой идеей то, что TBD рассматривает партнерство с CME Group.
Should the maximum amount be reached prior to the end of the sale on TBD, which is 4 weeks after the start of the token sale, we will cut off the token sale.
Если максимальная сумма будет достигнута до окончания продажи по TBD, которая через 4 недели после начала продажи Hero, мы прекратим его продажу.
They remained in service until 1938, being eventually replaced by the TBD Devastator and becoming the last biplane torpedo bomber of the U.S. Navy.
Martin T4M оставались на службе до 1938 г., в конечном счете, будучи замененным на TBD Devastator и став последним биплановым бомбардировщиком ВМС США.
The first ships to bear the formal designation «torpedo boat destroyer» TBD were the Daring -class of two ships and Havock -class of two ships of the Royal Navy.
Первые суда, которые будут иметь формальное обозначение «разрушитель торпедного катера» (TBD), были двух судов и двух судов Королевского флота.
The Pillars of Chinese Innovation TBD.
Три кита китайских инноваций, TBD.
Although the term «destroyer» had been used interchangeably with «TBD» and «torpedo boat destroyer» by navies since 1892, the term «torpedo boat destroyer» had been shortened to «destroyer» by nearly all navies by the First World War.
Хотя термин «разрушитель» был использован наравне с «TBD» и «разрушителем торпедного катера» военно-морскими флотами с 1892, термин «торпедный катер разрушителя» обычно сокращался просто «разрушителю» почти всеми военно-морскими флотами Первой мировой войной.
Что означают наиболее распространенные аббревиатуры в деловой электронной переписке
Все больше людей в Украине ведет деловую переписку в электронном виде с зарубежными партнерами или работодателями. Но даже хорошего знания иностранного языка часто бывает недостаточно, чтобы разобраться в ставших уже общепринятыми на Западе сокращениях, используемых в электронных посланиях. Предлагаем с помощью Deutsche Welle разобраться в этих аббревиатурах. В подавляющем большинстве своем они пришли из английского языка.
Пожалуй, чаще всего употребляется аббревиатура asap. Это расшифровывается как as soon as possible, что переводится «как можно скорее», срочно.
Есть еще один вариант сокращения, отражающего то же пожелание — t2du (things to do urgently).
И asap, и t2du нередко сопровождаются стоящими перед ними двумя буквами — FB. Это вовсе не Facebook, как может показаться сначала. Это feedback, что означает «обратный отзыв» или ответ.
Сокращение afaik пришло в деловую электронную переписку из молодежного сленга. Это означает as far as I know- насколько мне известно.
Еще одно распространенное сокращение — fyi (for your information). Означает «для справки», обязательного ответа данное послание не требует. Хотя будет вежливо поблагодарить человека, поделившегося с вами полезной с его точки зрения информацией.
Еще одна аббревиатура с примерно тем же значением — nre (no response expected). Она так и переводится — «отвечать не обязательно».
Буквы tba означают to be announced. Перевод простой — «будет объявлено дополнительно». Из этой же категории еще две аббревиатуры — tbc (to be confirmed) и tbd (to be determined). Перевод, соответственно, такой: «будет утверждено» и «будет определено». Хотя с tbd следует быть внимательнее. У этого сокращения есть еще два значения, поэтому определить, какое из них имелось в виду, можно только из контекста. А значения такие: to be discussed («выносится на обсуждение») и to be done («должно быть сделано»).
Полезно знать также аббревиатуры, означающие должности тех, с кем вы состоите в переписке, или о ком может идти речь. Вот основные сокращения, входящие в данную группу:
— CEO (Chief Executive Officer): главный исполнительный директор или генеральный директор. Обычно это человек, от которого зависит общая стратегия компании.
— CFO (Chief Financial Officer): финансовый директор. Осуществляет контроль за расходами, а также занимается большинством финансовых вопросов.
— CIO (Chief Information Officer): директор по информационным технологиям.
— CHRO (Chief Human Resource Officer): директор по персоналу, отвечает за кадровые вопросы.
— CMO (Chief Marketing Officer): директор по маркетингу.
— COB (Chairman of the Board): председатель совета директоров.
Следует обратить внимание, что любая должность, начинающаяся с буквы «C» (Chief), означает, что вы переписываетесь с кем-то из руководства, либо речь в письме идет о ком-то из руководства.
Стартапы и ненормальное программирование. TBD
В преддверии HolyJS мы обсудили проблемы стартапов, географические отличия разработки и влияние open source на отрасль с Джорджем Мандисом (George Mandis). В свое время он уже доказал на практике, что для разработчика на самом деле не важны политические границы и географические координаты, на протяжении нескольких лет работая из разных стран мира. А сегодня решил поделиться с нами своими наблюдениями.
— Мы хотели бы задать несколько вопросов о вашем опыте работы со стартапами: сталкивались ли вы с неудачами, которые вдохновили на дальнейшую работу?
George Mandis: Хотя в течение 11 лет я был независимым разработчиком, меня не затронули многочисленные традиционные проблемы стартапов. Меня приглашали, как внешнего специалиста.
Не буду перечислять проблемы поименно, но лично мне кажутся неудачными многие аспекты «стартап-культуры». Поскольку сам факт вливания больших объемов денег не делает работу автоматически, так же, как он не делает индустрию в целом важной или изменяющей мир.
Что касается вдохновляющих успехов — в свое время у меня был проект, который считаю личным успехом: я построил социальный сервис полностью с нуля, написав собственную библиотеку аутентификации. Были и другие вещи, которые я абсолютно не должен был делать. С точки зрения карьеры эти начинания были амбициозны и не своевременны (очень и очень рано). Но задачи были решены и все это так и не сломалось (удивительно!).
В процессе я получил огромное количество знаний. Это было в период до iPad, немногим после iPhone, но когда разработка еще вращалась вокруг Internet Explorer 6.0. Я бы не повторил это снова. Но я горжусь результатом.
— Как с точки зрения независимого разработчика отличаются жизнь стартап и стандартная корпоративная среда (enterprise-сегмент)?
George Mandis: В enterprise-сегменте больше денег и уверенности, но стартапы почти всегда звучат сексуальнее — особенно когда вы молоды. В enterprise я не беспокоюсь об оплате, не получаю предложений по выплате акциями, и если я хорошо поработаю, могу ожидать повторного заказа.
Работа со стартапами скорее похожа на игру, но я думаю, можно выбрать правильные проекты, чтобы это не всегда было так. После нескольких напряженных проектов ранее я придумал выражение: «Будьте осторожны, ступая на первый этаж мечты других людей». Оставаться на всю ночь и отлаживать свои собственные проекты — это одно. Делать это для другого человека, независимо от того, сколько он мне платит, — это другое. Побывав пару раз в такой ситуации, я стал более внимателен к тому, в каких стартапах участвовать, и научился выявлять такие «головные боли» на ранней стадии.
Я работал на профессиональную спортивную команду в течение полутора лет, и у этой работы было много общего со стартапом. У нас была небольшая команда разработчиков, множество различных проектов, которые формулировались по мере создания, и удивительно ограниченный бюджет. Частые изменения курса и внутренняя организация оказались одними из самых больших проблем. И теперь этот опыт побуждает меня ожидать большего от стартапа. Вещи не всегда такие, какими вам кажутся!
— Каковы различия между странами, в которых вы работали (с точки зрения технических и социальных условий)?
George Mandis: Я провел годы, работая и путешествуя по миру. В общей сложности жил в 18 разных странах. Это полностью изменило меня, и я все время вспоминаю об этом.
Во время путешествий я часто обращался к местным разработчикам, отчасти чтобы понять, каково там работать, а также чтобы завязать общение на новом месте. В итоге у меня сложились определенные представления.
Некоторые вещи одинаковы. Стремление к подключению и сети, кажется, были везде, куда я приезжал, и особенно восторженно и оптимистично они воспринимались среди разработчиков. Во-вторых, я говорил людям, что делаю визитки из дерева, и разговор сразу переходил на бизнес-идеи. Испания, Турция, Кения, Сербия, Таиланд, Япония — так было во всех этих местах. В один незабываемый момент я постучал в неправильную дверь в поисках офиса веб-разработки. С помощью моего ломаного испанского мы смогли устранить путаницу, но я ушел с визиткой, адресом электронной почты и серьезным предложением «оставаться на связи».
А вот работа, как мне показалось, отличается и даже несколько ограничена в некоторых местах. В Турции, например, я встречал много замечательных, дружелюбных разработчиков самых разных специализаций. Их навыки и технический бекграунд были разнообразными, но большая часть, похоже, работала на Türk Telekom, что меня немного удивило. Возможно, это нормально, а может просто так совпало в команде, которую я нашел.
Я обнаружил салон разработки и дизайна в Найроби! По разным причинам эта попытка встретиться с другими разработчиками была одной из самых примечательных. Они сосредоточились на веб-сайтах для малого бизнеса, но также работали на американские компании — отправляли электронные письма, которые, честно говоря, попадают в США посреди ночи и, вероятно, удаляются утром без прочтения.
Они работали посменно, чтобы пересекаться с рабочим временем в США. Значительная часть их бизнеса была связана с текстовыми сообщениями и M-PESA, очень популярным в Восточной Африке. Было увлекательно узнать о подобных вещах и своими глазами увидеть все в действии.
Еще одно отличие: иногда поиск чистой воды — более сложная проблема, чем доступ в интернет.
Работа в часовом поясе на 10 часов раньше большинства моих клиентов в США оказалась для меня идеальной и способствовала лучшему балансу работы и жизни: я мог работать утром и вечером, когда рабочие часы пересекались, и проводить дневное время, изучая новое место.
— Запомнилась ли какая-то специфика: интернет-соединение, действия регулятора, часовые пояса и т.д.?
George Mandis: В некоторых странах мне не удалось получить доступ к определенным сайтам. К одним блокировкам я был готов и имел запасные пути, как в Китае. Но другие меня удивили. Неожиданно в Южной Америке мне заблокировали доступ к нескольким хостинговым компаниям. Правда, это не так сложно было исправить: VPN и прокси — друг разработчика!
Во время визита я узнал кое-что интересное об интернете в Северной Корее… но я никогда не пытался работать оттуда. Честно говоря, это было бы невозможно. Ситуация с Wi-Fi в аэропортах отличается по всему миру.
Я также был удивлен тем, что в некоторых странах интернет измеряется. Это было в Исландии. Я жил в доме с 4 или 5 другими людьми, и в один прекрасный день интернет замедлился. В конце месяца он возобновился. Это случилось на следующий день, но я к такому не привык. В США немобильные тарифные планы почти никогда не ограничены по объему данных, и я никогда об этом не думаю.
— Был ли какой-нибудь странный опыт?
George Mandis: Ха-ха! Всегда есть странный опыт! Некоторые договоренности были нарушены. Получение оплаты в Биткоин было не столько странным, сколько новым и забавным.
— Не могли бы вы сказать пару слов о ваших коммерческих проектах, за которые вы получаете деньги? Было бы здорово, если бы вы рассказали об используемых технологиях и причинах, по которым вы их выбрали.
George Mandis: У меня нет отдельных коммерческих проектов, которые приносят деньги. Это все разработка, консалтинг и — в последнее время — обучение.
Я думаю, что за всю карьеру JavaScript дал мне наибольшую отдачу в пересчете на вложенные усилия, но вряд ли это знание полезно другим!
У меня есть несколько внутренних инструментов на Python и Ruby, которые я использую для управления своим временем, проектами и выставлением счетов. Большинство моих новых, более забавных вещей, построены с помощью Express. У меня все еще есть хорошая работа через агентства с WordPress и за последние пару лет я унаследовал несколько проектов на PHP. Я пытаюсь найти хороший проект для React.js, но этого пока не произошло.
Вы должны выбирать стеки технологий на основе сочетания собственных представлений о пользе, врожденной привлекательности / легкости для понимания и интересах сообщества. Вероятно, последнее имеет больше влияния на то, что кто-либо из нас использует, чем мы хотели бы думать.
Я действительно утверждаю, что для 90% того, что мы делаем, язык не имеет такого значения, как мы считаем. Различные способы мышления, разная эффективность имеют значение в масштабе для действительно крупных компаний со сложными потребностями (Google, Facebook, Netflix и др.). Но для подавляющего большинства из нас действительно ли часто этот фактор вступает в игру? Я много думаю об этом.
— Open source — это современный тренд и даже модное слово. Что вы думаете об OSS? Некоторые говорят, что OSS будет править миром через 10 лет. Корпорации инвестируют сюда огромные средства. Означает ли это, что мы все будем фрилансерами, которые пишут открытый код?
George Mandis: Он уже правит миром! Может быть все просто выглядит не так, как люди себе это представляли.
Веб буквально не может работать без open source, поэтому мне трудно рассматривать его как модное словечко или современный тренд. Безусловно, наше отношение к open-source и сама его концепция изменились. Существует различие в пред- и пост-GitHub восприятии того, что для некоторых людей означает open-source, которое я не могу описать, но могу видеть. Также для меня есть большая разница между GNU и Free Software Foundation, которые используют OSS как своего рода философию, а разработчики участвуют в инициативах OSS, инициированных корпорациями, используя это как шаг в карьере.
Некоторые OSS представляют собой инструмент расширения возможностей или повышения общественного блага. Хороший пример — SecureDrop. В других случаях я чувствую, что корпорации пытаются получить бесплатный труд для внутреннего инструмента. Схема может работать нормально, пока проект продолжает соответствовать потребностям корпораций, но как только фокус сместится, компания покинет проект в поисках более зеленых лугов. Проект может быть заморожен. Честно говоря, я не очень доверяю Facebook в этом плане (это корпорация, о которой я думаю в первую очередь, когда говорю о подобном недоверии). Возможно, в этом и заключается одна из существенных причин моего медленного принятия React.js!
Строго говоря, большинство проектов с открытым исходным кодом, о которых мы говорим, представляют собой инструменты и фреймворки для создания других вещей. Почти все мы используем эти вещи, даже если не содействуем активно их развитию. Я делал крошечный вклад только тогда, когда спотыкался о пограничные условия и ошибки или мне требовалось разработать адаптер или плагин, чтобы он общался со службой, которая в настоящее время не поддерживается.
Так что если вопрос в том, будем ли мы все работать исключительно для создания инструментов, я думаю — нет. Работа над инструментами хороша, но настоящая работа — использование этих инструментов для создания вещей для не разработчиков. Вот где вы сталкиваетесь с реальными пограничными условиями, ошибками и проблемами, которые нужно решить.
Небольшое замечание: мой самый большой вклад в ОС полностью фриволен: konami-js. Я горжусь этим.
— Сегодня распространенная практика для разработчиков — найти теплое место в крупной компании, чтобы получать зарплату в 100 тыс. долларов в год. Как вы думаете, все изменится, когда OSS распространится повсеместно?
George Mandis: Как я уже сказал, я думаю, что OSS уже достаточно распространено. OSS значительно выравнивает игровое поле во многих областях. К слову о проекте, который я уже упоминал — я считаю невероятным, что издание, подобное New Yorker, может запустить SecureDrop и обеспечить безопасное место для анонимных советов. Если бы площадка была проприетарной и скрытной, мы почти наверняка увидели бы меньше организаций, способных предложить такую услугу.
Поэтому я думаю, что игровое поле будет по-прежнему выравниваться. Технологии, которые 10 или 15 лет назад были недостижимыми для небольших организаций из-за стоимости или других ограничений, станут дешевле и доступнее. Платформы для публикации, безопасность, распознавание голоса и образов, искусственный интеллект и глубокое обучение — все эти вещи сегодня я могу перетащить в свой проект, и это замечательно!
С обратной стороны этого оптимизма: инструменты являются open-source, но конечный продукт часто таковым не является. Крупные корпорации с очень разными интересами и потребностями диктуют направление развития и популярность этих инструментов.
А с точки зрения наемного работника я вообще не уверен, что есть разница между открытым и закрытым ПО (но это очень США-центрированный взгляд на вещи).
— И последний вопрос: жизненный цикл современного JS-фреймворка довольно короткий (несколько лет). Сейчас React, Redux, Angular, Vue и т.д. управляют JS-миром. Как долго они будут жить? И что будет дальше?
George Mandis: Если жизненный цикл инструмента короткий, я бы сказал, что это не жизненный цикл, а тренд (хотя я понимаю, что с некоторыми своими ответами я похож на старикана).
Люди любят переизобретать колеса. Я на самом деле думаю, что это хорошо — для обучения — но становится сложно, когда очередные новые колеса рекламируются как направление, в котором все должно идти. Самое смешное, что все это мы уже видели раньше. Я помню Google Web Toolkit и SproutCore, и Cappucino, и другие фреймворки, призванные помочь нам в создании лучших веб-приложений.
Инструменты заново изобретаются с нуля, но концепции, как правило, только корректируются. Я думаю, это важно помнить.
Лучший совет, который я могу дать: научитесь изучать вещи, в идеале — быстро. Достаточно знать, как выявить «суть» чего-то и куда нужно смотреть позже, чтобы уточнить некоторые особенности. Если можете, отождествляйте себя с разработчиком, который знает интегральные концепции программирования на любом языке или фреймворке, или с тем, кто знает основной язык, но я бы предостерег от того, чтобы слишком сильно ограничивать себя инструментами.
На мой взгляд, это немного похоже на подрядчика, который специализируется на использовании только определенного молотка. Вы бы наняли его для работы на своей кухне? Не нашли бы вы немного странным, что он ограничивает себя подобным образом? Возможно. Но в конечном итоге вы хотите специалиста, который создает вещи и понимает, как они построены.
Если кратко: не путайте навыки с инструментами. Я вижу много людей, которые так делают, и когда технологии сдвигаются, они чувствуют, что остались позади.
Некоторое время назад я взял машину Lyft (аналог Uber) и завел с водителем разговор о работе. Водитель сказал мне, что тоже занимался веб-разработкой. Я спросил, что это за работа, и он ответил: «Много PHP и MySQL для финансовых учреждений… Но все задания PHP и MySQL иссякли! Очень жаль.»
Этот стек не супер-сексуальный и не передовой, но основные понятия и возможность писать объектно-ориентированный код, который взаимодействует с базой данных SQL, должны быть очень переносимым набором навыков! Т.е. иногда люди слишком сильно идентифицируют язык / рамки / инструмент.
Итак, изучите базовые концепции, изучите основной язык в основе фреймворка. Обновляйте свои знания по общим алгоритмам программирования, но опасайтесь слишком сильно идентифицировать себя с «Разработчиком React» или «Angular разработчиком». Сейчас в этой сфере есть много рабочих мест, и такая ситуация может сохраняться в течение длительного времени. Но если вы продолжите этот путь… Когда-нибудь все это устареет.
Эй, есть ли еще программисты COBOL и магазины Cold Fusion?
George Mandis интересует самыми разнообразными задачами. Его более практический доклад о применении JS для работы с малыми компьютерами (Raspberry, Arduino и т.п.) — Make More Than Music with Tiny Computers, JavaScript and MIDI — запланирован на первый день HolyJS в Санкт-Петербурге.
- Блог компании JUG Ru Group
- Open source
- JavaScript
Словарь терминов (глоссарий) по разработке требований (Вигерс, 2013)
CRUD-матрица ~ CRUD matrix — таблица, связывающая действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется (Updated) и удаляется (Deleted). Planguage — основанный на ключевых словах язык, предложенный Томом Гилбом (Tom Gilb) и позволяющий создать точную и количественно оцениваемую спецификацию требований.
Swimlane-диаграмма ~ diagram — модель анализа, показывающая последовательные шаги потока бизнес-процессов предлагаемой программной системы. Процесс разбивается на визуальные компоненты, называемые дорожками, которые показывают системы или действующие лица, выполняющие эти шаги.
TBD — сокращение от To Be Determined. Служит для отметки неясностей или пропусков, которые надо заполнить, в информации требований.
UML (Unified Modeling Language) — набор стандартной нотации для создания различных визуальных моделей систем, особенно в объектно-ориентированном программировании.
Альтернативное направление ~ alternative flow — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач или при взаимодействии объекта с системой.
Анализ первопричин ~ root cause analysis — действия, которые предпринимаются для поиска основных причин, вызывающих наблюдаемые проблемы.
Анализ расхождение ~ gap analysis — сравнение текущего состояния и альтернативного или возможного состояния системы, процесса или другого аспекта бизнес-ситуации для выявления значительных расхождений между ними.
Анализ требований ~ requirements analysis — процесс классификации информации, касающейся требований, по различным категориям, оценка требований для определения желаемого качества, представление требований в различных формах, выделение детальных требований из требований более высокого уровня, обсуждение приоритетов требований и т. д.
Архитектура ~ architecture — структура системы, включающая все ПО, оборудование и людей, из которых она состоит, интерфейсы и взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.
Атрибут качества ~ quality attribute — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта. Примеры атрибутов качества: удобство и простота использования, легкость перемещения, легкость в эксплуатации, целостность, надежность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов качества, до которых продукт демонстрирует желаемые характеристики.
Атрибут требования ~ requirement attribute — описательная информация о требованиях, которая дополняет описание желаемой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик ~ business analyst — роль члена команды по разработке требований, основная обязанность которой — работа с заинтересованными лицами над выявлением, анализом, определением, утверждением и управлением требованиями в проекте. Эта роль также может называться аналитик требований, системный аналитик, разработчик требований и просто аналитик.
Бизнес-правило ~ business rule — политика, предписание, стандарт, правило или вычислительная формула, определяющая или ограничивающая некоторые стороны бизнес-процессов.
Бизнес-требования ~ business requirement — объем информации, который в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. Бизнес-требования включают бизнес-возможности, бизнес-цели, метрики успеха, концепция и границы и ограничения.
Бизнес-цель ~ business objective — финансовая или нефинансовая выгода, которую организация ожидает получить в результате реализации проекта или другой инициативы.
Блок-схема ~ flowchart — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.
Большие данные ~ big data — обычно описывают массив данных, отличительные особенности которых — большой объем (много данных), высокая скорость (данные быстро поступают в организацию) и/или высокая сложность (данные очень разнородны). Управление большими данными предусматривает обнаружение, сбор, хранение и обработку больших объемов данных быстро и эффективно.
Бумажный прототип ~ paper prototype — непрограммная модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.
Вариант использования ~ use case — описание набора логически связанных возможных взаимодействий действующего лица и системы, которые дают результат, ценный для действующего лица. Может включать много сценариев.
Взаимосвязь «расширить» ~ extend relationship — конструкция, в которой альтернативное направление ответвляется от нормального направления в отдельный «расширенный» вариант использования.
Владелец продукта ~ product owner — роль, обычно в команде проекта гибкой разработки, представляющая клиента и отвечающая за определение концепции продукта, предоставление границ и ограничений проекта, определение приоритетов запаса продукта и принятие решений по продукту.
Внешняя сущность ~ external entity — объект в контекстной диаграмме или диаграмма потока данных, представляющая класс пользователей, действующее лицо, программную или аппаратную систему и являющийся внешним к описываемой системе, но так или иначе взаимодействует с ней. Также называется оконечным устройством.
Водопадный жизненный цикл проекта ~ waterfall development life cycle — модель процесса разработки ПО, в которой различные действия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложением или итерациями.
Встроенная система ~ embedded system — система, содержащая аппаратные компоненты, управляемые ПО, работающем на выделенном компьютере, являющемся частью более крупного продукта.
Выходное условие ~ postcondition — условие, описывающее состояние системы после успешного завершения варианта использования.
Выявление требований ~ requirements elicitation — процесс определения требований из различных источников посредством интервью, семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Гибкая разработка ~ agile development — методы разработки ПО, характеризующиеся постоянным взаимодействием между разработчиками и клиентами. К методам гибкой разработки относятся экстремальное программирование (Extreme Programming), Scrum, разработка, управляемая функциональностью (Feature Driven Development), бережливая разработка программного обеспечения (Lean Software Development) и Kanban.
Граница проекта ~ scope — часть концепции конечного продукта, реализуемой в ходе текущего проекта. Определяет границу между тем, что входит и что не входит в проект, в котором создается определенный выпуск или итерация.
Действующее лицо ~ actor — лицо, играющее конкретную роль, программная система или аппаратное устройство, которое взаимодействует с системой для достижения полезных целей. Также называется ролью пользователя.
Дерево решений ~ decision tree — модель анализа, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.
Дерево функций ~ feature tree — модель анализа, отображающая функции, запланированные для продукта, в виде иерархического дерева и отображающая до двух уровней подчиненных функций в каждой функции.
Дефект требования ~ requirement issue — проблема, открытый вопрос или решение относительно требования. Это могут быть элементы, помеченные как «TBD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.
Диаграмма (или машина) состояний ~ state machine diagram — модель анализа, показывающая представления различных состояний, которые могут принимать объекты системы на протяжении своего жизненного цикла в ответ на то или иное событие или отображающая возможные состояния системы в целом. Похожа на диаграмму перехода состояний.
Диаграмма «сущность–связь» ~ entity-relationship diagram — модель анализа, которая показывает логические взаимосвязи между парами объектов. Используется для моделирования данных.
Диаграмма вариантов использования ~ use case diagram — модель анализа с указанием действующих лиц, которые могут взаимодействовать с системой для выполнения задач, и различные варианты использования, в которых может участвовать действующее лицо.
Диаграмма взаимодействия ~ activity diagram — аналитическая модель, которая позволяет динамически представить систему, посредством изображения потока процессов от одной функции к другой. Схожа с блок-схемой.
Диаграмма классов ~ class diagram — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи.
Диаграмма перехода состояний ~ state-transition diagram — модель анализа, показывающая возможные состояния системы или объектов в ней, разрешенные переходы между ними и условия и/или события, инициирующие каждый переход. Аналогична диаграмме или машине состояний.
Диаграмма потока данных ~ data flow diagram — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Документ о концепции и границах ~ vision and scope document — документ, в котором определены бизнес-требования к новой системе, в том числе положения о концепции продукта и описания границы проекта.
Документы процесса ~ process assets — документы, такие как шаблоны, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного применения в организации с целью улучшить приемы разработки ПО.
Допущение ~ assumption — положение, которое считается верным в отсутствие доказательств или точных знаний.
Зависимость ~ dependency — зависимость проекта от внешних факторов, событий или групп, находящихся вне зоны контроля.
Заинтересованное лицо ~ stakeholder — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.
Исключение ~ exception — условие, которое может помешать успешному завершению варианта использования. Если некоторые возвратные механизмы не работают, то выходные условия варианта использования не достигаются и желаемая цель не достигается.
Итерация ~ iteration — непрерывный период разработки, обычно от одного до четырех недель, во время которого команда разработки реализует определенный набор функциональности, выбранной из резерва продукта, или базовой версии требований к продукту.
Каркас ~ wireframe — разновидность одноразового прототипа, который используется для предварительного дизайна веб-страниц.
Карта диалоговых окон ~ dialog map — модель анализа, описывающая архитектуру пользовательского интерфейса, показывая видимые диалоговые элементы и навигацию между ними.
Карта экосистемы ~ ecosystem map — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи. В отличие от контекстных диаграмм, карта экосистемы показывает системы, имеющие отношения друг с другом, даже если между ними нет интерфейса.
Класс пользователей ~ user class — группа пользователей системы, имеющих схожие требования к системе. Члены пользовательского класса функционируют как действующие лица при взаимодействии с системой.
Класс ~ class — описание набора объектов, имеющих общие свойства и поведение, которые стандартным образом соотносятся с элементами реального мира (людьми, местами или вещами) в бизнесе или определенной предметной области.
Клиент ~ customer — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта.
Количество элементов ~ cardinality — количество элементов данных объектов или данных, которые связаны с элементами других объектов или данных. Например, «один к одному», «один ко многим» или «многие ко многим».
Контекстная диаграмма ~ context diagram — аналитическая модель, которая описывает абстрактную систему высокого уровня. Контекстная диаграмма определяет внешние для системы объекты, которые взаимодействуют с ней, но не отображает ничего из внутренней структуры или поведения системы.
Концепция ~ vision — утверждение, описывающее стратегический принцип конечной цели и формы новой системы.
Критерий приемлемости ~ acceptance criteria — условия, которым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Матрица отслеживания связей требований ~ requirements traceability matrix — таблица, отображающая логические связи между функциональными требованиями и другими системными артефактами, в том числе функциональными требованиями, пользовательскими требованиями, бизнес-требованиями, элементами архитектуры и дизайна, модулями кода, тестами и бизнес-правилами.
Модель ~ mock-up — частичная или возможная реализация пользовательского интерфейса для систем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Может представлять собой программу или прототип на бумаге. Также называется горизонтальным прототипом.
Модель бизнес-целей ~ business objectives model — визуальное представление иерархии бизнес-задач и бизнес-целей.
Нефункциональное требование ~ nonfunctional requirement — описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать.
Нормальное направление ~ normal course — последовательность действий, заданная по умолчанию в варианте использования, которая ведет к удовлетворению выходных условий этого варианта использования или достижению целей пользователей. Другие названия: нормальное направления развития, базовый поток, нормальная последовательность, основной успешный сценарий и счастливый путь (happy path).
Ограничение ~ constraint — налагается на доступные разработчику возможности дизайна или конструирования продукта. Другие типы ограничений могут ограничить возможности, доступные для менеджеров проектов. Бизнес-правила часто накладывают ограничения на бизнес-операции, а значит, на программные системы.
Одноразовый прототип ~ throwaway prototype — прототип, который создается с расчетом, что после его использования для уточнения и утверждения требований и вариантов дизайна он будет выброшен.
Оперативный профиль ~ operational profile — комплект сценариев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия ~ facilitator — лицо, ответственное за планирование и работу группы, например работу семинара по выявлению требований.
Основная версия требований ~ requirements baseline — зафиксированный в определенный момент времени, согласованный, просмотренный и одобренный набор требований, обычно определяющих определенный выпуск продукта или итерацию разработки. Служит основой для дальнейшей разработки.
Отношение включения ~ include relationship — конструкция, в которой несколько шагов, повторяющихся во многих вариантах использования, выделяются в отдельный вложенный вариант использования, который вызывается по мере необходимости.
Отслеживание ~ tracing — процесс определения логических связей между одним элементом системы (вариантом использования, функциональными требованиями, бизнес-правилами, компонентами дизайна, фрагментами кода, тестами и т. д.) и другим.
Панель мониторинга ~ dashboard — изображение на экране или в печатном документе с множественными текстовыми и/или графическими представлениями данных, предоставляющее консолидированное многомерное представление происходящего в организации или процессе.
Пилотная версия ~ pilot — контролируемое выполнение нового решения (такого как процесс, инструмент, программная система или учебный курс) для оценки его работы в реальных условиях и готовности к развертыванию.
Повторное использование требований ~ requirements reuse — использование существующих требований во многих системах, отличающихся одинаковой функциональностью.
Пользователь ~ user — клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы, хотя не генерирует эти результаты). Также называется конечным пользователем.
Пользовательская история ~ user story — способ выражения пользовательских требований в проектах гибкой разработки в форме одного или двух предложений, формулирующих потребность пользователя или описывающих единицу необходимой функциональности, а также говорящих о пользе, какую эта функциональность приносит пользователю.
Пользовательское требование ~ user requirement — цель и задача, которую пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы. Пользовательские требования обычно представляются в виде вариантов использования, пользовательских историй и сценариев.
Поток процесса ~ process flow — последовательные шаги бизнес-процесса или операций предложенной программной системы. Обычно предоставляется с применением диаграммы взаимодействия, блок-схемы, swimlane-диаграммы или другой нотации моделирования.
Правило решения ~ decision rule — согласованный способ выработки единого решения в группе людей.
Предварительные условия ~ precondition — условия, которые должны быть удовлетворены, или состояние, в котором система должна пребывать, чтобы мог начаться вариант использования.
Приемочный тест ~ acceptance test — тест для проверки ожидаемых вариантов использования с целью определения приемлемости ПО. Используется в проектах гибкой разработки для представления подробностей пользовательских историй и определения правильности их реализации.
Приоритизация, определение приоритетов, расстановка приоритетов ~ prioritization — акт определения того, какие требования программного продукта наиболее важны для достижения бизнес-успеха и в каком порядке должны реализовываться требования.
Проверка ~ verification — процесс оценки рабочего продукта, позволяющий определить, удовлетворяет ли он спецификации, на основе которой создан. Обычно формулируется в виде вопроса: «Правильно ли мы создаем продукт?»
Продукт ~ product — конечный результат разработки, выполняемой в рамках проекта. В этой книге используются также термины-синонимы «приложение», «система» и «решение».
Проект с чистого листа ~ green-field project — проект, в котором разрабатывается новое ПО или новая система.
Прототип ~ prototype — частичная, предварительная или возможная реализация программы. Применяется для исследования и утверждения требований, а также для разработки приемов. Прототипы бывают эволюционные, одноразовые, бумажные, горизонтальные и вертикальные.
Процедура ~ procedure — пошаговое описание направления действия для выполнения и завершения конкретной работы.
Процесс ~ process — последовательность действий, выполняемых для достижения конкретной цели. Описание процесса представляет собой документированное определение этих действий.
Процесс создания требований, процесс построения требований ~ requirements engineering — область, которая охватывает все стороны жизненного цикла проекта, связанные с необходимыми возможностями и атрибутами продукта. Состоит из разработки требований и управления требованиями. Считается подобластью процессов построения системы и ПО.
Рабочий продукт ~ work product — любой промежуточный или окончательный результат, созданный в проекте разработки ПО.
Разработка требований ~ requirements development — процесс определения границ проекта, классов и представителей пользователей, выявления, анализа, спецификации и утверждения требований. Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта ~ scope creep — условия, при которых границы проекта неконтролируемо расширяются на протяжении всего процесса.
Распределение требований, назначение требований ~ requirements allocation — процесс распределения системных требований по различным архитектурным и компонентным подсистемам.
Резерв продукта ~ product backlog — в проекте гибкой разработки, распределенные по приоритетам список еще не реализованных задач проекта. Резерв может содержать пользовательские истории, бизнес-процессы, запросы на изменение и разработку инфраструктуры. Рабочие элементы из резерва назначаются на будущие итерации на основе их приоритетов.
Ретроспектива ~ retrospective — рецензирование, в котором участники анализируют действия и результаты проекта с целью определения путей повышения успешности последующих проектов.
Рецензирование ~ peer review — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.
Решение ~ solution — все компоненты, которые должны быть созданы в процессе реализации проекта для достижения бизнес-целей, определенных организацией, в том числе ПО, оборудование, бизнес-процессы, руководство пользователя и обучение.
Риск ~ risk — условие, которое может привести к потере или иным образом поставить под угрозу успех проекта.
Серийные продукты, коммерческие готовые продукты ~ COTS (commercial offtheshelf) product — готовый пакет ПО, приобретаемый у поставщика. Применяется как готовое решение или интегрируется, настраивается и расширяется в соответствии с потребностями клиента для удовлетворения нужд последнего.
Система ~ system — продукт, содержащий много программных или аппаратных подсистем. В общеупотребимом смысле используется в этой книге в отношении приложения, продукта и решения для обозначения любого содержащего ПО результата, создаваемого командой.
Система бизнес-аналитики ~ business analytics system — программная система, служащая для преобразования больших и сложных наборов данных в осмысленную информацию, на основе которой можно принимать решения.
Система реального времени ~ real-time system — аппаратная или программная система, которая должна реагировать в четко определенное время на заданные события.
Системное требование ~ system requirement — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Словарь данных ~ data dictionary — набор определений элементов данных, структуры и атрибутов, относящихся к определенной предметной области.
Событие ~ event — инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции или изменение состояния.
Совет по управлению изменениями ~ change control board — группа сотрудников, отвечающая за решение о принятии или отклонении предлагаемых изменений в требованиях к ПО.
Спецификация требований к продукту ~ software requirements specification — набор функциональных и нефункциональных требований к продукту ПО.
Сторонник продукта ~ product champion — назначенный представитель отдельного класса пользователей, который предоставляет пользовательские требования представляемых им групп пользователей.
Сущность ~ entity — элемент области бизнеса, данные о котором собираются и сохраняются.
Схема требования ~ requirement pattern — систематический подход к определению определенного типа требований.
Сценарий ~ scenario — описание взаимодействия пользователя и системы с целью достижения некоторой цели. Пример работы с системой. Один из путей развития варианта использования.
Таблица «событие–реакция» ~ event-response table — перечень внешних или зависящих от времени событий, которые могут влиять на систему, и описание того, как система будет отвечать на каждое из них.
Таблица решения ~ decision table — модель анализа в виде матрицы, где показаны все комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Таблица состояний ~ state table — модель анализа, показывающая в виде матрицы состояния, в которых может находиться система или ее объекты, а также какие возможны переходы между состояниями.
Требование ~ requirement — документ, где указаны потребности или цели пользователей либо условия и возможности, которыми должен обладать продукт, чтобы удовлетворить такие возможности или цели. Свойство, которым должен обладать продукт, чтобы представлять ценность для заинтересованного лица.
Требования для интерфейса внешнего устройства ~ external interface requirement — описание интерфейса между системой ПО и пользователем, другой системой ПО или оборудованием.
Требования-«бантики», украшательство ~ gold plating — не являющаяся необходимой или избыточно сложная функциональность, запланированная и разработанная для продукта, иногда без одобрения клиента.
Управление требованиями ~ requirements management — работа с определенным набором требований к продукту, начиная от процесса разработки продукта и заканчивая поддержкой действующего продукта. Управление подразумевает отслеживание состояния продукта, управление изменениями требований и версиями спецификаций требований, а также отслеживание требований до других требований и элементов системы.
Утверждение ~ validation — процесс оценки рабочего продукта, позволяющий определить, действительно ли он удовлетворяет потребности клиента. Обычно формулируется в виде вопроса: «Создаем ли мы правильный продукт?»
Функциональная точка ~ function point — мера размера ПО, основанная на числе и сложности внутренних логических файлов, файлов интерфейса внешнего устройства, вводимых извне данных, результатов и запросов.
Функциональное требование ~ functional requirement — описание поведения системы в определенных условиях.
Функция ~ feature — одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
Цикл разработки ПО ~ software development life cycle — последовательность действий, в которой ПО определяется, конструируется, строится и проверяется.
Шаблон ~ template — образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип ~ evolutionary prototype — полностью функциональный прототип, построенный как скелет или некая стадия конечного продукта, которые постепенно будут «обрастать мясом» по мере прояснения требований.
Экспериментальный образец ~ proof of concept — прототип, реализующий часть содержащей программную часть системы и охватывающий много уровней архитектуры. Применяется для оценки технической осуществимости и производительности. То же самое, что вертикальный прототип.
Эксперт предметной области ~ subject matter expert — лицо, имеющее обширный опыт и знания в предметной области и считающееся полномочным источником информации о предметной области.
Экспертиза ~ inspection — тип рецензирования, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Эпика ~ epic — пользовательская история в проекте гибкой разработки, которая слишком большая, чтобы ее можно было реализовать в одной итерации разработки. Эпика разбивается на более мелкие истории, каждая из которых может быть реализована в одной итерации.
Литература
Карл Вигерс и Джой Битти — Разработка требований к программному обеспечению. Издание третье, дополненное. 2013 год.