Сквозной цикл разработки программного обеспечения в веб-приложении? - PullRequest
0 голосов
/ 19 марта 2009

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

Например, URS, SRS, ERD, диаграмма DB, диаграмма классов, сценарий использования, тестовые сценарии, руководство пользователя и учебные материалы обычно являются отдельными документами.

Кто-нибудь делал все это в одной веб-системе?

Он начинается с ввода всех требований в систему и позволяет легко создавать URS. Всякий раз, когда какие-либо изменения в требованиях, они должны быть введены в систему, но могут быть легко созданы.

Самая важная часть - это прослеживаемость, где мы можем увидеть, как требования реализуются до конца. Иногда они находятся в URS, но отсутствуют в процессе, так как их трудно сравнивать / проверять вручную. Очень часто разные люди делают отдельный процесс, поэтому вещи могут случайно пропустить. Например, функция может существовать в системе и тестовом скрипте, но не в руководстве пользователя.

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

Спасибо!

Ответы [ 5 ]

1 голос
/ 24 сентября 2012

Я предлагаю использовать одну из многих Вики-систем (обычно собранных с трекером) для документации. Хорошие примеры: Trac, Redmine и (коммерческий) FogBugz, Jira.

Вы можете ссылаться на вики из билетов, что позволяет

  • легкий поток информации: spec -> команда внедрения
  • возможность поиска
  • версия документа
  • ...

Эти решения работают в режиме онлайн , никакого специального локального программного обеспечения не требуется.

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

1 голос
/ 21 апреля 2011

Если вы используете гибкую методологию, TeamForge из Collabnet поможет. URL: http://www.collab.net/downloads/ctf/

Teamforge построен на SVN, так как является основой и обладает множеством возможностей, которые вы ищете в Agile проекте.

0 голосов
/ 19 марта 2009

Используем Сфинкс .

Документация находится в репозитории с кодом.

Документация включает ссылки на код с помощью команд Sphinx .. addmodule.

0 голосов
/ 19 марта 2009

Используем XPlanner . Он в основном ориентирован на итерации в программировании Xtreme, но мы также используем его как инструмент планирования требований. Вы можете добавить аннотации произвольной формы к «историям» (= функциям в XP), которые являются просто вики-страницами (плюс вложения файлов). Вы также можете оценить время, создавать задачи и т. Д.

Или вы можете просто использовать вики. из которых есть много. Я бы предпочел что-то «в свободной форме», например вики, чему-то, что обеспечивает / форсирует определенный рабочий процесс, поскольку планирование в любом случае часто не следует жестко за конкретным рабочим процессом. (Хорошо это или плохо - другое дело ...)

0 голосов
/ 19 марта 2009

Вы смотрели на Requisite Pro от Rational / IBM, наша компания прошла процесс поиска пакета управления требованиями, и этот пакет был окончательно выбран. В конце мы реализовали использование Wiki для всех документов, главной электронной таблицы, которая пронумеровала все функции, и базы данных Access, которая перекрестно ссылалась на функции по их количеству ошибок и сгорела, довольно ручной процесс, но он удивительно хорошо работал с менеджером проекта. который имел некоторый опыт кодирования.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...