Стандарты представления требований
Еще раз об требования (интересно, сколько раз я уже обо всём этом тут писал?!). Традиционно требования понимаются как спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д
( Read more... )
Для этого нужно каким-то образом выйти на тех, кто участвует (или участвовал) в проверке систем такого класса, и расспросить, что конкретно делают с системой при проверке. И написать требования не на основании 30 тыс. страниц стандарта, а на основании рассказа человека продолжительностью в несколько часов.
Кстати, тут же может выясниться, что дело не [только] в системе. А также что обязательно должно быть, чтобы пройти проверку, на что могут закрыть глаза, если всё остальное хорошо, а что не проверяют совсем, потому что в стандарте написана абстракция или откровенная глупость.
Если выйти на людей не получается, то сначала нужно постараться выделить самые важные аспекты из этого стандарта, а затем накопить необходимую информацию о проверке на своём опыте. Возможно, для этого придётся пройти проверку не с первого раза. Всё это очень долго и дорого.
Но 30 тыс. страниц требований - это всё равно, что их полное отсутствие. В голове у человека, который их будет реализовывать руками, хорошо, если 30 страниц сразу поместятся.
Reply
Ваши рассуждения для таких продуктов не работают. А у меня все клиенты такие...
Reply
Reply
Reply
Т.е. безвозвратно преобразовать высказывание модальности требования «заправка 1 экземпляра ракеты должна стоить не более 200 тыс. $» в высказывание модальности модели «предположим, ракету нужно будет заправлять 200 т пары керосин-кислород при помощи электрического насоса марки ЭН-18». Нужно оставить оба, чтобы время от времени сверять их и генерировать высказывание модальности спецификации, вида «на 19.01.2011 действительно заправка разрабатываемой ракеты стоит не более 200 тыс. $, а именно 181 тыс.$» и вывод «продолжаем разработку». Цены гипотетические.
Я к тому, что мне кажется, что требования не модальность, а отдельная сущность, представляющая самостоятельную ценность.
Reply
Reply
При этом, было бы более привычно требованиями называть высказывания "система должна" (с указанием, кто обеспечивает, кому должна и подразумеванием, как будем выполнять приемку), а другие модальности называть проектными решениями.
И тогда, возможно, все будут довольны.
И дисциплину пора переименовать в "Управление проектными решениями".
Как вы думаете?
Reply
Различают также инженерию требований и инженерию системной архитектуры (системноинженерные дисциплины), а также проектирование (дисциплины специальной инженерии).
Reply
- "система обязательно должна"
- "очень желательно, чтобы система"
- "было бы хорошо, если бы система"
(можно придумать столько градаций, сколько степеней важности и приоритетов принято в проекте, по опыту хватает или трёх, при условии что обязательного не больше трети, или нужен сквозной список)
- "система не должна".
Потому что именно интенциональные, дебитивные и оптативные модальности необходимы, чтобы выразить цель создания системы. Но, конечно, только применения модальности как формы недостаточно, важен смысл.
Высказывания с остальными модальностями, IMHO, привычнее называть не требованиями, а моделями, спецификациями, орг. решениями, разнообразной дополнительной информацией.
Хотя, конечно, граница размыта: что для архитектора потенциальное "создавать новые экземпляры класса можно фабричным методом", то для разработчика после того, как архитектор принял эту опцию, становится дебитивным, "в классе таком-то должен быть реализован фабричный метод", а после отмашки тимлида, если он отличается от архитектора, императивным, "реализуй фабричный метод в классе таком-то".
Твиттеро-подобная система управления проектной информацией?
Reply
Насчет твиттеро-подобной системы, так issue tracker это как раз такая система: описания (требования, архитектурные модели и т.д.) лежат отдельно, а issues и что с ними когда делать создаются и путешествуют между исполнителями и менеджерами отдельно.
Reply
Применение же искусственного языка чревато тем, что его не будет понимать никто, кроме сочинившего, пока он не убедит остальных в преимуществе этого языка над существующими. Что непросто.
Применять искусственные языки для записи проектной информации более чем правильно, да они и используются - для проектирования, построения мат. моделей, кодирования. Но в случае с требованиями, да и с другими артефактами, это чревато тем, что становится сложно проверить эти артефакты, предоставив их пользователю, сотрудникам отдела маркетинга, инженерам-внедренцам «с полей». Для высказываний модальности «требование» это IMHO неприемлемо.
---
Про существующие issue tracker - мне, наверное, не повезло, и поэтому я отношусь к этим системам весьма скептически. Дело в том, что я видел штук 5 разных issue tracker’ов в работе, и каждый был неудобным, а внутри разводили беспорядок.
Одна из причин была в том, что они плохо интегрировались с системами, в которых хранилась остальная проектная информация. В результате, в issue tracker’е были либо копии (обычно устаревшие) текстовой части этой информации (потому что они не могли хранить ничего, кроме текста), либо ссылки «на раздел» требований или модели, обычно не гипертекстовые, и поэтому по ним переходили весьма редко.
Но если от issue всё же можно было перейти к артефакту, то от артефакта к issues, на основании которых он был создан или которые породил, перейти было практически невозможно. Было непонятно, например, почему появился тот или иной участок кода, и реализовали ли модель, или она так и осталась произведением абстрактного искусства.
Другая причина крылась в отсутствии целостной картины того, как применять issue tracker в проекте. Например, при постановке в виде issue требования и архитектурные решения либо не переформулировали в задачи «что сделать где в коде к какому сроку», либо переформулировали, но «закапывали» это в одном из десятка постов переписки по issue. В результате, появлялись задачки как на 15 минут, так и на месяц. Обычно они относились исключительно к коду, к остальным артефактам issues не создавали.
Кроме того, была проблема со связью issues и календарных планов, и с распределением issues по людям. Возникали ситуации, когда issue обрабатывали в «оперативном» режиме, и выделяли на это фиксированное время, и ставили их в планы, только когда времени переставало хватать. Разумеется, когда статус issue изменяли на «выполнено», нужно было ещё раз вручную изменить статус связанных с ним задач в плане.
Поэтому я считаю, что нужно, чтобы:
1) люди осознали проект как сеть из цепочек «источник - высказывание - модальность - участник - срок - порождённые высказывания», и научились с ними работать;
2) появились инструменты, поддерживающие такую организацию проектной информации, чем легковеснее - тем лучше.
А какими issue tracker и связанными с ними методологиями проектной работы пользуетесь вы?
Reply
А поскольку в последнее время мы работаем не столько с софтовыми инженерами, сколько с системными/"железными", то у них такие системы называются "документооборот", и реализуются вне инженерной действительности (т.е. артефакты и issues вообще развязаны, каждый issue начинается "Уважаемый Имя Отчество!", распечатывается на бумаге и имеют рукописные входящий и исходящий номер, адресацию на имя начальника, а "исполнитель", который в курсе сути проблемы, указывается где-нибудь внизу страницы вместе с номером офисного телефона, по которому его застать невозможно).
Reply
Leave a comment