#спецификация_на_разработку — Public Fediverse posts

Начать за здравие: как оформить спецификацию на разработку и ускорить процесс создания ПО

Одним из самых важных инструментов, который помогает организовать процесс разработки программного обеспечения, является «Спецификация на разработку», или СНР. Этот документ служит своего рода дорожной картой для всей команды, от аналитиков до разработчиков, и позволяет четко определить требования к продукту. Но что делать, когда на проекте работают десятки аналитиков и каждый пишет спецификацию «в свободной форме»? Ответ прост: использовать шаблоны. Привет, Хабр! Меня зовут Анатолий Троян, я ведущий разработчик и технический архитектор IBS. В этой статье я хочу поделиться личным опытом применения шаблонов СНР на реальном проекте по разработке 1С-системы: как мы писали спецификации, какие у нас при этом возникали проблемы, почему вообще решили все стандартизировать и как отрабатывали изменения в документе.

https://habr.com/ru/companies/ibs/articles/988128/

#спецификация #спецификация_на_разработку #1c

Нужна ли документация на проекте?

Вопрос о необходимости документации при разработке вызывает много споров. В динамичном мире IT, где изменения стремительны, я часто слышал холиварные обсуждения: а так ли необходима документация? Кто-то считает, что программный код сам по себе уже исчерпывающая документация. В моей прошлой статье было несколько комментариев с утверждениями, что документацию вести необязательно, достаточно кодовой базы и условного OpenAPI. В прошлой статье я рассказывал, как работал в проектах без документации. В этот раз под катом опишу аргументы в пользу ведения документации и поддержания её в актуальном состоянии.

https://habr.com/ru/companies/alfa/articles/858942/

#документация #аналитика #управление_проектами #bus_factor #спецификация_на_разработку #сайзинг #описание_проекта #минимизация_рисков

Функциональная спецификация на разработку ERP-системы на примере ABAP-отчета

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1]. Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2]. Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

https://habr.com/ru/articles/854228/

#техническое_задание #тз #задание_на_разработку #erpсистемы #спецификация_на_разработку

Принципы проектирования программ и их отражение в спецификации на доработку ERP-системы

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы. Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2]. К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.

https://habr.com/ru/articles/832594/

#спецификация_на_разработку #тз #техническое_задание #техническое_задание_для_разработки #техническое_задание_образец #fs #functional_specification #srs #функциональная_спецификация