Практика формирования требований в ИТ проектах от А до Я. Часть 7. Передача требований в производство. Заключение

С частью 6 можно ознакомиться, перейдя по ссылке

XI Специфицируем требования


Требование — всего лишь временный посредник для решения проблемы реального мира.
«Фабрики разработки программ» [8]



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

Цель данной группы работ: на основании собранной информации о целевом продукте подготовить качественные спецификации требований, позволяющие максимально эффективно организовать процесс их реализации.
Читать дальше →

Практика формирования требований в ИТ проектах от А до Я. Часть 6. Поведение системы. Совершенстваоние требований

С частью 5 можно ознакомиться, перейдя по ссылке

IX Определение поведения системы.


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



После того как мы определились с перечнем основных сценариев и сущностей предметной области, необходимо сопоставить их друг с другом.

Цель данной группы работ: на основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам.
Читать дальше →

[recovery mode] Microservice Architecture — сдвиг мотива на цель

В статье Мартина Фаулера и Джеймса Льюиса, в которой описываются достоинства «Microservice Architecture», написано:

Enterprise приложение — приложение, построенное как единое целое. ЛЮБОЕ изменение в системе приводит к пересборке и равертыванию новой версии серверной части приложения.

Понятно стремление авторов быть пропагандистами «Microservice Architecture», однако использование таких определений как ЛЮБОЕ, ВСЕГДА, НИКОГДА говорит о слишком эмоциональном отношении к предмету. Налицо попытка увлечь читателя эмоциями, отключить его мозг. Когда авторы используют такие преувеличения, где-то тут должен скрываться чорт. Так где же он, рогатый? Читать дальше →

О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему
Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.

Готовим читателей к знакомству со спецификациями

Итак, с чего может начинаться знакомство команды разработки, с представленными требованиями? Непременно с презентации аналитиком своего творения, будущим исполнителям. Для обоих сторон очень важно, насколько успешно будет установлен первый контакт и преодолен барьер вхождения в новый процесс. Но часто, по ряду причин очно это сделать невозможно или проблематично. Поэтому хорошим тоном будет включение в начало документа раздела, с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать. Пример обзора документа: Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы». ...Далее...

Обобщённое копирование связных графов объектов в C# и нюансы их сериализации

Задачи по копированию отдельных объектов и связных графов часто встречаются в программировании. Методов их решения существует несколько в зависимости от исходных условий и требований. Цель статьи — рассмотреть ключевые разновидности решений, обозначить область применения, выделить преимущества и недостатки.

image
Читать дальше →

GoTo Data Science Challenge 2: гранты на летнюю школу

Мы анонсируем конкурс для получения грантов в рамках направления по анализу данных и машинному обучению летних школ GoTo. К участию приглашаем школьников и младшекурсников. В качестве задания предлагается kaggle-соревнование от Quora, в котором необходимо построить модель для определения вопросов-дубликатов.


image


Под катом описание условий задачи, ссылки на полезные материалы и пример простого решения.


Читать дальше →


Последние посты