0

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

Например, URS, SRS, ERD, DB Diagram, Class Diagram, Use Case, Test Scripts, Руководство пользователя и учебные материалы обычно являются разделенными документами.

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

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

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

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

Спасибо!

ответ

0

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

0

Мы используем Sphinx.

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

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

0

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

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

1

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

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

1

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

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

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

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

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