Документы для проекта? [закрытый]
Просто сделайте то же самое, что и вы, но измените параметры. Если вы передадите только один параметр, SubString будет идти до конца.
Dim hyphenHold As String = "9077-this is a string - with a hyphen"
Dim string1 As String = hyphenHold.Substring(0, hyphenHold.IndexOf("-")).Trim
Dim string2 As String = hyphenHold.Substring(hyphenHold.IndexOf("-") + 1).Trim
7 ответов
Ключевой документ является хорошей функциональной спецификацией. Должен быть один и только один справочный документ для системы.
Переусердствовать документацию распространяется, большое количество небольших требований и спецификации документирует каждый раз, когда кто-то изменяет систему или интерфейс. Для системы любой сложности в ближайшее время у Вас есть своя спецификация, распределенная приблизительно несколько сотен различных слов, Excel, Visio и даже powerpoint файлы. Когда это происходит, Вы теряете ясность о том, что является текущим или даже определили ли Вы местоположение и определили всю подходящую документацию.
Прогрессия спецификации BRD-SRD-Tech основана на предположении, что бизнес заканчивает BRD, бизнес-аналитик заканчивает, SRD против требований, зарегистрированных в BRD и техническую спецификацию, закончен против SRD. Это генерирует сеть выходов, нескольких документов с избыточной информацией и мешает и неуклюжий, чтобы усовершенствовать документы спецификации.
Из-за этого последующие требования documentatation имеют тенденцию принимать форму ряда запроса на изменение и дополнительного требования и документов спецификации, каждого с их собственным выходом и контрольным процессом. Вы получаете CYA и журнал аудита (или по крайней мере появление журнала аудита), но Вы теряете ясность. Нет теперь никакого категорического справочного документа для системы, и трудно установить то, что является текущим или относится к какому-то конкретному действию. Конечный результат состоит в том, что Ваш процесс бизнес-анализа увязает в судебном исследовании, которое добавляет издержки и задержку к графикам поставки.
Документ спецификации должен быть создан таким способом, которым существует одна категорическая ссылка для любой данной системы или подсистемы. Документ должен быть усовершенствован и имеющим версию. Получите хороший инструмент технической документации как Плотник, таким образом, Ваш процесс может масштабироваться, и документ имеет некоторую структурную целостность вида, недостающего на Word.
Документация похожа на тофу - большинство людей ненавидит его, пока они не понимают, что при правильных условиях, это может быть действительно хорошо.
Проблема состоит в том, что, что Вы рассматриваете, документация главным образом сделана для пользы документации. Вы, как разработчик, не видите непосредственного значения в документах, которые Вы представляете, потому что Вы знаете, что можно сделать задание без всех отчетов TPS, которые Вы обязаны делать.
К сожалению, я собираюсь держать пари, что нет много, можно сделать о в компании, где Вы вынуждаетесь съесть необработанное тофу все время. Необходимо будет, вероятно, просто высосать его и записать документы, которых требует компания, но можно, по крайней мере, сделать одну вещь... можно записать документы, которые, по крайней мере, полезны для Вас, и можно передать их наряду с кодом для других, которые поддержат его.
Кроме встроенной документации, Вы могли настроить Wiki, которая будет использоваться собой и людьми в Вашей команде. Этот тип документации доступен для поиска, который уже является большим плюс разработчикам, плюс он - больше живущего документа вместо подобной домашней работе работы, которую необходимо было написать. Вы уже отправляете на Так, поэтому просто думаете о своей документации как об объединении Вашего знания в более полезном месте.
Для меня единственный реальный документ, который я когда-либо использую, является спецификацией. Чем больше детали, тем лучше. Однако это не должно быть все завершено когда-то, и это не должно быть особенно формально. То, что намного более полезно для меня, чем документы, которые проверены и подписаны и проверены дважды и удваиваются подписанный, всегда является способностью получить последнюю версию документа. И способность говорить с людьми о том, что они записали и получают решение в случае любой неоднозначности. это намного более полезно для меня, чем что-либо еще.
Подводя итоги: спецификация является единственным документом, который я когда-либо находил полезными, однако это бледнеет по сравнению с наличием менеджера проектов, который очень хорошо знает предложенную систему и может принять разумные решения на основе того, что они знают.
Что Вы думаете, самые важные документы для проекта?
У различных людей есть различные потребности: например, документы, в которых нуждается владелец (например, бизнес-контракт) не являются тем же как документами, в которых нуждается QA.
Какие документы могут использоваться в конечном счете другим разработчиком?
IMO самый важный документ (за исключением исходного кода) является функциональной спецификацией: потому что, что программное обеспечение, как предполагается, делает (в противоположность, что оно делает) одна вещь, которая не может обязательно быть перепроектирована. См. также, Как хороший разработчик удерживается от создания кода с низким фактором хита шины?
С точки зрения проекта самые важные документы - те, которые обычно включают слово План, такой как План Проекта, План управления конфигурацией, План качества, и т.д.
То, что Вы описываете, распространено в усовершенствованиях процесса и обычно отвечает на две главных причины. Каждый - это, система действительно перехитряет и мешает реальной сделанной работе. Другому на самом деле отвечают в Вашем вопросе: не то, чтобы документы только сделаны ради аудитов, и Ваш фокус не должен только быть, насколько полезный документ для других разработчиков, но для проекта или компании в целом.
Каждый обычно смотрит на вещи со своей собственной точки зрения, иногда необходимо посмотреть на общую картину.
Я - поклонник старого 4+1 представления:
Представление Use Case (a/k/a пользовательские истории). Существует несколько форм: случаи надлежащего использования, перспективные варианты использования, которые также не определяются и эпопеи, которые должны анализироваться.
Логическое представление. "Статическое" представление. Диаграммы классов UML и т.п. работают хорошо здесь документом дизайна. Это также включает запрос и форматы ответа для различных протоколов. Вот то, где мы документируем УСПОКОИТЕЛЬНЫЕ запросы и ответы. Это включает остальных дизайн URI.
Представление Process. "Динамическое" представление. Схемы действия UML, диаграммы последовательности и диаграммы состояний и т.п. для здесь для документов дизайна. В некоторых случаях простые рассказы работают хорошо. В других случаях существует шаблон разработки состояния, и он требует, чтобы комбинация диаграмм классов и диаграмм состояний показала, как объекты с сохранением информации взаимодействуют.
Это также включает протоколы (например, REST). Вот то, где мы определяем любую специальную обработку для различных запросов REST.
Это также включает аутентификацию или авторизацию правила и любые другие сквозные аспекты как безопасность, вход, и т.д.
Представление компонента. Части мы создаем для развертывания. Это включает материал, мы зависим от, структура модулей и пакетов, и т.д. Это часто - простая диаграмма компонентов или список компонентов и их зависимостей.
Представление Deployment. Мы пытаемся генерировать это из кода, как развернуто. Так как мы используем Python, мы используем epydoc для создания документации API. Мы также используем Сфинкса для импорта документации модуля в это представление программного обеспечения.
Это также включает параметры, настройки и детали конфигурации.
Это, однако, не достаточно.
Когда проекты запускаются, необходимо работать до этого через серию спринтов.
Первые спринты создают просто представление варианта использования.
Последующие спринты создают "архитектуру" для реализации вариантов использования. Документ архитектуры имеет 4+1 представление, но на высоком уровне абстракции. Это суммирует структуру образцовых схем, запросов и ответов, УСПОКОИТЕЛЬНОЙ обработки, другой обработки, ожидаемых компонентов, и т.д. Это никогда не имеет представление Deployment. Мы обычно ссылочное руководство оператора и документы API как представление развертывания архитектуры.
Затем сборка спринтов проектирования и строительства (и обновление) подробно изложила 4+1 документ представления для различных компонентов.
Затем выпустите сборку спринтов (и обновление) представления развертывания.