Как стать автором
Обновить
24
Карма
0
Рейтинг
Наталья Желнова @enotinka

Пользователь

  • Подписчики 24
  • Подписки 4

Нефункциональные требования к программному обеспечению. Часть 1

Хороший вопрос.
Я думаю, что нынешним летом (но уже ближе к августу) я ее напишу.

Откуда берутся бизнес-аналитики?

«Быстро печатать» — это несомненное преимущество для бизнес-аналитика, равно как и моделировать «во всяких интересных нотациях».

Я удивляюсь, что подобные статьи могут появляться в эпоху, когда существует множество профессиональных ресурсов для бизнес- и системных аналитиков. Хотя бы:
IIBA Russian Chapter Initiative (https://www.facebook.com/groups/IIBARussianChapter/?fref=ts),
Анализ в IT-проектах (https://www.facebook.com/groups/Analiz.v.IT/),
Сообщество аналитиков (http://www.uml2.ru/)

Класс объектов или объекты класса?

Ну, я бы так не сказала — что он сводится к одной инженерии требований. У классиков жанра это так, однако реальные обязанности аналитика выходят за рамки Requirements Engineering.

Нефункциональные требования к программному обеспечению. Часть 1

Журнал запросов на выполнение работ — на мой взгляд, не самый удачный перевод. Лучше, мне кажется, журнал запросов на изменение.
У «Русской редакции когда-то была мода ставить в информацию об издании фамилию редактора. По крайней мере, свою я там видела, когда редактировала книги по SQL Server (администрирование и разработка). Иногда ставили фамилии переводчиков (по крайней мере я на этом настаивала, когда работала вместе с людьми, которые начинали свой путь в программировании с разработки движков для баз данных).
Теперь эта мода у „Русской редакции“ прошла — они переводят книги силами компании Логрус, занимающейся локализацией разных программных продуктов, в том числе и Microsoft. Работу переводчиков в Логрусе часто выполняют студенты. Что касается редактуры — похоже, что от нее и вовсе отказались.

Нефункциональные требования к программному обеспечению. Часть 1

Да, но разница в том, что бизнес-правило может диктовать, как именно должен выполняться сценарий. Если бы бизнес-правила не существовало, этот сценарий мог бы быть реализован 10-20 различными вариантами. А если оно есть — то только одним.

Нефункциональные требования к программному обеспечению. Часть 1

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

Нефункциональные требования к программному обеспечению. Часть 1

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

Нефункциональные требования к программному обеспечению. Часть 1

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

Нефункциональные требования к программному обеспечению. Часть 1

Вигерс Карл, Разработка требований к программному обеспечению, Москва, «Русская Редакция», Подписано в печать 03.12.03
Глава 1 стр. 8
Знаменитый рисунок, проводящий границу между функциональными и нефункциональными требованиями:

image

Думаю, что на основании этой картинки (там еще текст к ней есть) можно однозначно сказать, к какому виду требований относит Вигерс бизнес-правила.

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

Ну и Макконел — не аналитик, так сказать, в чистом виде, ему то, что не относится непосредственно к модели качества и метрикам, которые отражаются в коде, видимо, неинтересно.

Нефункциональные требования к программному обеспечению. Часть 1

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

Нефункциональные требования к программному обеспечению. Часть 1

Я думаю, что мы должны в первую очередь определиться с терминологией.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.

Метрики в проектах по разработке ПО

Так зачем тогда метрики?
Хороший вопрос. Мне кажется, первая фраза уже содержит ответ на него: чтобы понимать состояние проекта.
И сотни метрик, как мне кажется, не нужны. Нужны только те метрики, которые помогут нам ответить на вопросы:
1. Сколько денег мы должны иметь в распоряжении, чтобы они не закончились в самый неожиданный момент (нижняя и верхняя граница)?
2. Сколько людей и с какой квалификацией мы должны привлекать к работам, в какие сроки?
3. Каково общее состояние проекта, сколько работы сделано, сколько еще осталось?
Ответив на эти вопросы, мы получим искомое.

Идеи для проектов: UI сайта знакомств, ч. I

Теперь я буду знать, кто такие undev!

Метрики в проектах по разработке ПО

Мне дали поручение сформулировать требования к надстройке к известной Redmine.
Вот, сижу, пока думаю.

Метрики в проектах по разработке ПО

Да, спасибо за замечание — считается отклонение сумм, конечно же.

Почему крупные заказчики не работают с маленькими, но гордыми подрядчиками

В качестве «формализатора условий SLA», я имею непосредственное отношение к двум видам деятельности:
1. Локализация программного обеспечения (нет, это не просто перевод ресурсных строчек, а изменение программного продукта для его адаптации к условиям российского рынка и требованиям законодательства). Руководство этими проектами. Разные компании в разное время, в основном до 2000 года. Иных уже нет, а те далече.
2. Разработка ПО. Тоже разные компании в разное время.
В их числе — проданная какому-то системному интегратору компания, являвшаяся «собственным» отделом разработки при Sybase CIS. Здесь я выступала в роли инициатора определения SLA для нас со стороны нашего заказчика.
«Высокие технологии и стратегические системы», компания, принадлежащая АФК «Система» (входит в концерн «РТИ Системы», наряду с NVision и Sitronics — компаниями, которые разрабатывают софт для крупных операторов мобильной связи) 2011 — 2012 г. Когда мы начинали отдавать часть работ на аутсорсинг, выяснилось, что только трое человек в компании знают, что такое SLA. Поэтому писать эти условия пришлось мне (под редакцией Дмитрия Новоселова, руководителя департамента разработки — здесь до некоторых пор я многое делала под его редакцией, и это было испытание почище «Баланса Белого» с его «Яндексом»).
Дмитрий Новоселов — человек, начавший свою карьеру как системный программист, лет 7 в совокупности посвятивший роли системного архитектора, и только потом ушедший в проектный менеджмент (последние 5 лет в роли PM — в компании КРОК). Знаю я его уже около 15 лет.
Поскольку о Новоселове я могу рассказывать долго и вдохновенно, надеюсь, что это был не вполне само-пиар.

Почему крупные заказчики не работают с маленькими, но гордыми подрядчиками

Принимать ситуацию как явление природы и пытаться в ней выжить с пользой для кошелька — на мой взгляд, достойная задача. Но тогда нужно быть готовым к тому, чтобы несколько первых итераций работы с новым заказчиком провалились. Потом уже человек с аналитическим складом ума всегда сообразит в процессе этих мук, чего от него хочет заказчик (восстановление незапротоколированных требований, классика практики любого аналитика).
Проблема только в том, что это высокорисковые проекты. И вести их на условиях fixed price — на мой взгляд, просто инвестиции в будущего клиента, которого любишь-понимаешь. Опять же, смена вкуса Ивана Никифоровича на вкус Семена Ильича (при смене менеджмента на стороне клиента) может добаить еще три неожиданных проваленных итерации. У меня лично уже не всегда хватает терпения догадываться о предъявляемых требованиях методом проб и ошибок. Мне это скучно, и я обычно первой предлагаю договориться об SLA или изменить условия контракта — пусть даже с заметной выгодой для заказчика, но с четкими условиями «если — то».
При этом, когда я выполняю менеджерские функции, я всегда помню позитивный опыт работы с Microsoft и многие вещи «из прошлой жизни» использую, так или иначе видоизменив. Обычно и те, кто работает со мной на условиях субподряда, при этом не жалуются. Криков и воплей не раздается, ни одного субподрядчика пока по моей вине не пострадало. Правда, ни одного субподрядчика, не умеющего читать (особенно условия SLA), я тоже пока вокруг себя не видела. Быть может, мне повезло.
1

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирована
Активность