Каковы Ваши чувства на функциональных спецификациях? И Разработка программного обеспечения? [закрытый]
Ваш тестируемый метод возвращает карту, заполненную несколькими записями. Но ваш тест Junit не вызывает этот метод. Рассмотрим случай, когда тело метода из getColumnToIndexMap() изменяется со временем, считаете ли вы, что ваши тестовые примеры будут по-прежнему применяться?
Что, если getColumnToIndexMap() также использует удаление некоторых записей, будет ли проверка вашего покрытия покрытия проверять также? Нет, если вы не будете постоянно синхронизировать код в Junit с протестированным методом. Это высоко на обслуживании и никогда не рекомендуется.
15 ответов
Я не запущу внештатного проекта, пока я не буду иметь спецификацию дизайна и функциональную описанную спецификацию и закончу. Существует слишком много комнаты для клиентов жулика к никелю и десяти центов Вы до смерти, если у Вас нет его. Функциональная спецификация позволяет, Вы для оставлений предназначаетесь/фокусируете, и дает Вам естественный контрольный список для работы к.
Если нет никакой функциональной спецификации затем, Вы получаете все "что, если", начинающее закрадываться и разработчики, думающие - Вы знаете, это было бы полезно, и мне только потребуется час. Уверенный час, чтобы кодировать прототип и заставить его в основном рабочий - плюс день разрабатывать все тесты и удостоверяться все тестовые сценарии покрыты, затем еще несколько дней для сглаживания всех ошибок, затем время для записи документации. Существует слишком много комнаты для того, что походит на тривиальное дополнение, которое будет вставлено, когда нет никакой спецификации. Вы не сомневаетесь, слышал о печально известном "расползании границ проекта". Существует также слишком много комнаты для клиентов, чтобы сказать, что "это не то, что я хотел...", когда Вы поставляете ее и пытаетесь извиваться из оплаты Вас.
Если у Вас есть спецификация дизайна и функциональная спецификация, описанная перед разработкой, и и Вы и клиент закончили, что Ваше понимание не только основные детали, но и все нюансы используемого языка являются одними и теми же - только затем может реальная работа начинаться.
Существует несколько историй там, первое довольно верно, в то время как другой распространенное заблуждение:
- Разработка программного обеспечения составляет только 15% о коде, остальное - ресурс/управление персоналом.
- Требуется 20% времени для завершения первых 80% проекта и остающихся 80% времени для завершения последних 20%.
Неправильное представление состоит в том, что рабочий прототип составляет 80% пути там - не дурачатся, это не. Таким образом, для клиента легко сказать, "что занимает много времени, я думал, что Вы были почти сделаны!" и затем каламбур, который они оплачивают слишком много что-то, что должно было быть несколько законченных месяцы назад. Некоторые методологии проектирования там действительно предоставляют себя хорошо этому популярному неправильному представлению. Методология проектирования водопада является одним из них, если это не используется правильно.
Мое представление, удостоверяются, что Ваше понимание является тем же, оба заканчивают. Этапы набора и делают клиент очень знающим в начале, что прототипы являются длинным путем от завершения проекта и ожиданий набора с самого начала относительно того, что те этапы и когда клиент может ожидать видеть их поставленный.
Поскольку менеджеры проектов документации групп разработчиков и ожиданий - все. Вы не можете жить без него, это - единственная форма обращения за помощью, против которого Вы имеете, "Это не то, что я сказал" или "Это не то, что я имел в виду" и следовательно "я не плачу Вам".
Я узнал из большого количества ошибок, сделанных намного более квалифицированными разработчиками, чем я, и видел то, что это сделало им. Два самых важных документа для Вашего проекта являются спецификацией дизайна и функциональной спецификацией. Не уезжайте из дома без них, или он может [или скорее всего будет] возвращаться и кусать Вас в заднице.
Ре приложения: Пользовательские Истории:
Дополнительное примечание о пользовательских историях - то, что они являются великими для того, каковы они. Они должны быть включены в Вашу функциональную спецификацию, но не должны быть Вашей функциональной спецификацией.
Пользовательская история только описывает единственную задачу. Это очень легко и не содержит чрезмерную деталь. Когда общие рекомендации идут, это должно соответствовать на 3x5 карта..., если бы Вы как менеджер проектов вручили мне 3x5 карта и сказали мне писать часть программного обеспечения на основе того, что я считал, то несомненно это было бы вручено пользователю в конце, и они сказали бы менеджеру проектов, что это не то, что они хотели.
Вам нужен намного больший уровень детализации в функциональной спецификации. Это не должно быть ограничено основными рабочими процессами. Функциональная спецификация является целым набором пользовательских историй наряду с примечаниями по интерпретации тех пользовательских историй, улучшениям, которые могут быть сделаны им, общие задачи, которые могут быть объединены для повышения эффективности. Список продолжается.
Таким образом, пользовательские истории являются хорошим началом, но они не замена для функциональной спецификации, они - пункты маркированного списка в функциональной спецификации.
Я видел и записал много спецификаций, некоторые были очень хороши, большинство не было. Главное, которое они все имели общего, состоит в том, что они никогда не сопровождались. У них всех была паутина на них к 3-му дню кодирования.
Запишите спецификацию, если Вы хотите, наилучшее время, чтобы сделать это в конце проекта. Будет бесполезно для разработчиков следовать, но это, по крайней мере, будет точное представление того, что было сделано (я знаю - не действительно спецификация). Но не ожидайте, что спецификация запишет код для Вас. Это - реальное задание. Если Вы не знаете, что записать, говорят с Вашими заинтересованными сторонами и пользователями и получают некоторые хорошие пользовательские истории и затем продолжают его.
Одна интересная замена для func спецификации или пользовательских историй, что я видел защищенный, должна записать руководство пользователя для программного обеспечения сначала.
Даже если это является только условным (т.е. если Вы не намереваетесь поставить какое-либо руководство - который Вы, вероятно, не были должны, поскольку никто не считает его), это может быть полезный и довольно легкий способ достигнуть взаимопонимания того, что программное обеспечение сделает и похоже. И это вынуждает Вас сделать дизайн впереди.
Я нашел что, даже если Вы пишете Функциональные Спецификации, много детали иногда теряется на человеке, к которому Вы пытаетесь обратиться. Теперь, если Функциональная Спецификация записана наряду с некоторым макетом UI, который имеет огромное значение. Макеты UI не только показывают пользователю, что Вы предполагаете, это также инициировало пользователей в запоминание вещей, они не думали бы прочь во-первых.
Называете ли Вы их функциональными спецификациями, бизнес-требованиями или пользовательскими историями, они все очень выгодны для процесса разработки.
Проблема с ними прибывает, когда они высекаются в камне и используются в качестве устройства для раздавания вины, когда система utimately не соответствует реальным потребностям пользователя. Я предпочитаю использовать functionals или требования как начальная точка для итеративного процесса не как библия для точно, как система посмотрит, когда это будет завершено. У изменения вещей и пользователей обычно нет понимания того, что они хотят, пока у них нет чего-то (рабочий прототип возможно) в их руках, что они могут работать с вместо того, чтобы осмыслять на листке бумаги, как оно будет функционировать в реальном мире. Самые успешные проекты, которые я реализовал, были, где группа разработчиков и пользователи были тесно выровненные и смогли быстро изменить к лучшему изменения вместо того, чтобы содержать людей к тому, что они хотели на листке бумаги шесть месяцев назад.
Конечно, этот процесс не работал бы, если бы Вы были в фиксировано предложенном типе ситуации как один из более ранних ответов, на которые указывают.
Это зависит от функциональной спецификации. У меня были функциональные спецификации, где писатель знал систему от и до и записал спецификацию как таковую, и я сделал, чтобы другие устройства записи записали это с, что они ожидали рассматривать как пользователя.
С первым это легче, потому что я знаю точно, что я должен записать и где я должен записать это, но это ограничивает, как легко я могу осуществить рефакторинг существующий код, так как оценки приняли во внимание просто эту функцию и не рефакторинг существующего кода, которого это касается.
С последним у меня есть свобода осуществить рефакторинг (пока функциональность конца является тем же), но если это - система, я незнаком с, временную оценку более трудно сделать.
В целом, я люблю функциональные спецификации - мне также нравится напоминать людям, что они записаны на бумаге, которая изгибается, и как таковой, должно быть гибким.
Всего несколько комментариев к некоторым ответам здесь...
В первую очередь, я действительно полагаю, что хороший документ спецификации важен для любого moderatly сложного требования (и определенно для очень сложных). Но удостоверьтесь, что это - хорошая спецификация, т.е. только заявите очевидное (как один плакат, уже упомянутый), но также и не не учитывайте те части, которые могут казаться тривиальными Вам (или даже разработчики), так как у Вас могло бы быть больше знания той части системы, чем вовлеченные некоторые другие (например, тестеры или документаторы), который будет ценить иначе "недостающие биты".
И если Ваша спецификация будет хороша, то она будет считана - по моему опыту (и я записал и считал много спецификаций за прошлые годы), это - плохие спецификации, которые выводятся и хорошие, которые сопровождаются.
Касающиеся пользовательские истории (или иногда также названный вариантами использования): Я думаю, что они важны для понимания сценарий, но они обычно не могут заменять детали (например, экранировать макеты, как, где и если функцией является настраиваемая, модель данных, проблемы миграции и т.д.), таким образом, Вам, вероятно, будут нужны оба для более сложных требований.
По моему опыту, функциональные спецификации имеют тонкую грань между не высказыванием достаточно и высказыванием слишком много.
Если они не говорят достаточно, то они оставляют области открытыми для недоразумения.
Если они говорят слишком много, они не оставляют достаточно "пространства для маневра" для улучшения решения.
И они должны всегда быть открыты для процесса пересмотра.
Я нахожу правильно написанные функциональные спецификации очень полезными. Хорошо организованная функциональная спецификация может также помочь организовать Ваши тесты (many-many отображающийся от отдельных требований до тестовых сценариев).
<p style="tongue: in-cheek">Они также оказываются полезными для взаимных упреков в более крупных организациях (Требования были неточны! Реализация не следовала за требованием! QA правильно не протестировал это требование! и т.д.)</p>
Я буду ссылка второго Codeslave на Безболезненную Функциональную спецификацию. Это - хороший ряд статей о спецификациях. См. также это сообщение Stackoverflow для обсуждения какой содержание поместить в функциональные спецификации.
Я сделал несколько крупных проектов, включая один с некоторым hundereds человеко-годов общего усилия. Поскольку проектная группа становится более многочисленной, количество неофициальных каналов передачи повышается с квадратичной верхней границей. Без спецификации этот неофициальный механизм связи является единственным способом, которым могут быть переданы вещи. Со спецификацией каналы передачи приближаются к концентратору-и-спицам, делая рост больше как линейная функция размера проектной группы.
Спецификация является действительно единственным масштабируемым путем к получить команду, 'поющую от того же листа гимна'. Должен быть некоторый обзор и согласование о спецификации, но в конечном счете кто-то должен взять владение этого для предотвращения проекта, становящегося дискуссией.
Откровенно говоря, Функциональные спецификации должны уже быть частью Вашего Большого-M (Водопад) методология. Ваша функциональная спецификация - то, ЧТО Вы собираетесь создать; не обязательно, как Вы собираетесь создать его (который был бы Вашим детальным проектированием / спецификация и следующий шаг в водопаде).
Если Вы еще не записали тот, остановите то, что Вы делаете и пишете тому. Вы, просто напрасно тратят время, если Вы делаете иначе. Можно запустить здесь со статьи Joel.
Другой способ выполнить это использует пользовательские истории
Мне потребовались больше чем 10 лет, чтобы заставить его удар в мою голову писать функциональную спецификацию прежде, чем сделать любой код. Теперь я запишу один для чего-либо занимающего больше чем день для записи. Уровень детализации и уровень предположений должны быть так же по мере необходимости для ясного определения, какие потребности быть сделанным и передают его другим (или напомните себе), что-либо кроме того - отходы.
Другие предпочитают Пользовательские Истории..., который прекрасен также, пока Вы делаете некоторое планирование.
Я работаю с главным образом Водопадной моделью, и только с функциональными спецификациями. При работе самостоятельно (где я могу установить свою собственную модель и программу любым путем, я хочу) я запускаю путем описывания функциональных спецификаций и затем реализации их. Это дает мне намного лучшую идею размера и объем работ, помогает мне оценить время, включенное, и помогает гарантировать, чтобы я ничего не пропускал.
Кроме того, можно передать этот документ:
- Пользователи так, чтобы они могли ясно дать понять свои требования
- Разработчики для создания функциональности
- Тестеры для проверки они тестируют правильную вещь
- Архитекторы так, чтобы они могли проанализировать требования
Используя функциональные требования по пользователю истории вопрос предпочтения и объем проекта. Если у Вас есть небольшая база пользователей, то Вы можете сходить с рук пользовательские истории (которые обрисовывают в общих чертах различные последовательности события, которые пользователь мог бы сделать), но для больших проектов, необходимо использовать функциональные требования, поскольку они имеют больше детали и приводят к меньшему количеству недоразумений. Думайте о них как о средстве сообщения со всеми людьми, вовлеченными в проект.
Я думаю, что они - прекрасная идея и должны судиться.