Как подготовить SRS и документацию для программных проектов
Привет...
Can u tel,как подготовить документацию или отправить образцы шаблонов документации и СГД для проектов.
Спасибо тебе.
Конечно же, вот так.
http://en.wikipedia.org/wiki/Software_requirements_specification[^]
http://en.wikipedia.org/wiki/Software_documentation[^]
А вот больше чем пара способов узнать что-либо в Интернете.
Необходимо Образование[^]
Большое спасибо.
Как написать спецификацию требований к программному обеспечению
Роберт Джапенга
Что делает большую спецификацию требований к программному обеспечению?
Существует много хороших определений спецификаций требований к системе и программному обеспечению, которые обеспечат нам хорошую основу, на которой мы сможем как определить отличную спецификацию, так и помочь нам выявить недостатки в наших прошлых усилиях. Есть также много замечательных вещей в интернете о написании хороших спецификаций. Проблема не в недостатке знаний о том, как создать правильно отформатированную спецификацию или даже что должно входить в спецификацию. Проблема в том, что мы не следуем этим определениям.
Мы должны помнить, что цель состоит не в том, чтобы создать отличные спецификации, а в том, чтобы создать отличные продукты и отличное программное обеспечение. Можете ли вы создать отличный продукт без отличной спецификации? Совершенно верно! Вы также можете сделать свой первый миллион через лотерею – но зачем рисковать? Системы и программное обеспечение в наши дни настолько сложны, что приступать к проектированию, не зная, что вы собираетесь построить, глупо и рискованно.
Стандарт IEEE (www.ieee.org) является отличным источником для определения системы и спецификации программного обеспечения. Как разработчики встроенного системного программного обеспечения реального времени, мы используем IEEE STD 830-1998 в качестве основы для всех наших спецификаций программного обеспечения, если только это специально не требуется нашими клиентами. Для того чтобы иметь отличную спецификацию программного обеспечения, необходимо иметь отличную спецификацию системы. Эквивалентный стандарт IEEE для этого является стандарт IEEE std для 1233-1998. Однако для большинства целей в небольших системах можно использовать одни и те же шаблоны.
В чем преимущества большого эсера?
Стандарт IEEE 830 определяет преимущества хорошего SRS:
Установите основу для соглашения между заказчиками и поставщиками о том, что должен делать программный продукт. Полное описание функций, выполняемых программным обеспечением, указанным в СГД, поможет потенциальным пользователям определить, соответствует ли указанное программное обеспечение их потребностям или каким образом программное обеспечение должно быть изменено для удовлетворения их потребностей. [Примечание: мы постоянно используем его в качестве основы нашего контракта с нашими клиентами].
Сократите усилия по разработке. Подготовка SRS заставляет различные заинтересованные группы в организации заказчика тщательно рассмотреть все требования до начала проектирования и сокращает последующую переработку, перекодирование и повторное тестирование. Тщательный анализ требований СГД может выявить упущения, недоразумения и несоответствия на ранних этапах цикла разработки, когда эти проблемы легче исправить.
Обеспечьте основу для оценки затрат и графиков. Описание разрабатываемого продукта, приведенное в СГД, является реалистичной основой для оценки стоимости проекта и может быть использовано для получения одобрения заявок или оценки цен. [Примечание: опять же, мы используем SRS в качестве основы для наших оценок фиксированных цен]
Заложить основу для валидации и верификации. Организации могут разрабатывать свои планы валидации и верификации гораздо более продуктивно с помощью хорошей SRS. В рамках контракта на разработку СГД обеспечивает базовую основу, по которой можно измерить соблюдение требований. [Примечание: мы используем SRS для создания плана тестирования].
Содействовать передаче.SRS облегчает передачу программного продукта новым пользователям или новым машинам. Таким образом, заказчикам легче переносить программное обеспечение в другие подразделения своей организации, а поставщикам - в новые подразделения.
Служить основой для совершенствования. Поскольку СГД обсуждает продукт, но не проект, который его разработал, СГД служит основой для последующего совершенствования готового продукта. СГД, возможно, потребуется изменить, но она обеспечивает основу для дальнейшей оценки производства. [Примечание: это часто является серьезной ловушкой – когда СГД не постоянно обновляется с изменениями]
К чему должна обратиться СГД?
Опять же из стандарта IEEE:
Основными вопросами, которые должен решать автор(ы) СГД, являются следующие:
функциональность. Что должно делать программное обеспечение?
б) внешние интерфейсы. Как программное обеспечение взаимодействует с людьми, аппаратным обеспечением системы, другими аппаратными средствами и другим программным обеспечением?
в) производительность. Какова скорость, доступность, время отклика, время восстановления различных программных функций и т. д.?
г) атрибуты. Каковы соображения переносимости, корректности, ремонтопригодности, безопасности и т. д.?
д) проектные ограничения, накладываемые на реализацию. Существуют ли какие-либо требуемые действующие стандарты, язык реализации, политика обеспечения целостности базы данных, ограничения ресурсов, операционная среда(Ы) и т.д.?
Каковы характеристики великого эсера?
Опять же из стандарта IEEE:
СГД должен быть
а) правильно
б) недвусмысленный
в) полный
d) последовательный
д) ранжирование по важности и/или стабильности
е) проверяемый
г) изменяемый
з) вычерчиваем
Правильно - это как материнство и яблочный пирог. Конечно, вы хотите, чтобы спецификация была правильной. Никто не пишет спецификацию, которая, как они знают, неверна. Мы любим говорить: "исправлять и всегда исправлять." Дисциплина состоит в том, чтобы поддерживать спецификацию в актуальном состоянии, когда вы находите вещи, которые не являются правильными.
Однозначность - СГД является однозначной тогда и только тогда, когда каждое требование, изложенное в ней, имеет только одно толкование. Опять же, легче сказать, чем сделать. Тратить время на эту область до выпуска SRS может быть пустой тратой времени. Но как только вы обнаружите неясности - исправьте их.
Полный - простой судья этого заключается в том, что это должно быть все, что нужно разработчикам программного обеспечения для создания программного обеспечения.
Согласованность - СГД должна быть согласованной внутри себя и согласованной со своими справочными документами. Если вы называете ввод "Start and Stop" в одном месте, Не называйте его "Start/Stop" в другом.
Ранжирование по важности - очень часто новая система имеет требования, которые на самом деле являются маркетинговыми списками пожеланий. Некоторые из них могут оказаться недостижимыми. Полезно предоставить эту информацию в СГД.
Поддающийся проверке - не ставьте требований типа: "он должен обеспечить пользователю быстрый ответ." Еще один из моих любимых - "система никогда не должна терпеть крах". вместо этого предоставьте количественное требование, например: "каждый ход клавиши должен обеспечивать реакцию пользователя в течение 100 миллисекунд."
Модифицируемый - наличие одного и того же требования в нескольких местах не может быть неправильным - но имеет тенденцию делать документ не ремонтопригодным.
Прослеживаемый - часто это не важно в неполитизированной среде. Однако в большинстве организаций иногда бывает полезно связать требования СГД с документом более высокого уровня. Зачем нам это требование?
В чем разница между системной спецификацией и спецификацией программного обеспечения?
Очень часто мы обнаруживаем, что компании не понимают разницы между спецификацией системы и спецификацией программного обеспечения. Важные вопросы не определены заранее, и разработчики механических, электронных и программных продуктов на самом деле не знают, каковы их требования.
Ниже приведен высокоуровневый список требований, которые должны быть учтены в спецификации системы:
Определите функции системы
Определите функциональное разделение аппаратного и программного обеспечения
Определить технические характеристики
Определите разделение производительности аппаратного и программного обеспечения
Определение Требований Безопасности
Определите пользовательский интерфейс (хорошее руководство пользователя часто является упущенной частью спецификации системы. Многие из наших клиентов даже не задумывались о том, что сейчас самое подходящее время для написания руководства пользователя.)
Предоставьте Монтажные Чертежи/Инструкции.
Обеспечьте чертежи управления интерфейсом (МКБ, внешний ввод-вывод)
Одной из задач спецификации системы является определение полной функциональности системы. Во многих системах, над которыми мы работаем, некоторые функции выполняются аппаратно, а некоторые - программно. Задача спецификации системы состоит в том, чтобы определить полную функциональность и, как и требования к производительности, привести в действие компромиссы и предварительные проектные исследования, чтобы распределить эти функции по различным дисциплинам (механическим, электрическим, программным).
Another function of the System specification is to specify performance. For example, if the System is required to move a mechanism to a particular position accurate to a repeatability of ± 1 millimeter, that is a System’s requirement. Some portion of that repeatability specification will belong to the mechanical hardware, some to the servo amplifier and electronics and some to the software. It is the job of the System specification to provide that requirement and to set in motion the partitioning between mechanical hardware, electronics, and software. Very often the System specification will leave this partitioning until later when you learn more about the system and certain factors are traded off (For example, if we do this in software we would need to run the processor clock at 4