Рубрика «анализ требований»

Должен признаться – мне нравится разрабатывать LED-драйверы. Видимо есть что-то особенное в том, чтобы создавать свет, какая-то магия. Пусть продолжаются споры про вредность так называемого «синего пика», пускай в магазине мы всё ещё можем купить ужасные светодиодные лампочки с пульсацией 100%, тем не менее, разработать хороший LED-драйвер – отличная задача. Впрочем, это лирика и пора перейти к теме.

«Листая скучные ГОСТы…» или анализ требований при разработке LED-драйвера - 1

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

Такие мысли подтолкнули меня к написанию этой статьи-экскурса в мир ГОСТов.

Итак, если вас интересуют требования к светодиодному оборудованию, а также рекомендации по сертификации CE – добро пожаловать под кат.
Читать полностью »

image

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.
https://ru.wikipedia.org/wiki/анализ_требований

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

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

На мой взгляд, для того чтобы избежать этой ситуации, надо всего-лишь посмотреть на процесс под другим углом… Читать полностью »

Введение

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

Доброе время суток, дорогие читатели! Данная статья является продолжением топика, и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.
Как стать настоящим аналитиком? Часть 2. Выявляем требования
Стадию создания или разработки требований условно можно разделить на 4 этапа.Читать полностью »

image

5 Whys — как лекарство против Muda

...«Муда» как любые действия, которые не добавляют ценности, не могут и не должны быть неизбежными, а значит, они должны непрерывно устраняться…
Масааки Имаи «Гемба Кайдзен»

Понаблюдав можно заметить, что в повседневной жизни мы имеем дело с “цепочками создания ценности”, т.е. выполняем различные действия, направленные на достижение целей. Очень часто наши цели являются отправными точками для достижения других целей. Часто мы выполняем действия даже не подразумевая “зачем?”, таким образом тратя время и силы на действия не приносящие ценности (Muda) или тратя силы и время на результаты, которые того и не стоят…
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js