Пример Юзкейсов (UseCases)

Принципы XP

Основными принципами являются:

• Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.
• Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.

(Если не понятно, на каждой итерации в программу добавляются наипростейшие функции из тех, которые можно добавить на данный момент для того, чтобы не париться, если придётся что то менять)

• Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.
• Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
• Достаточная степень смелости и желание идти на риск.

20

…

Источник:

http://ksfei.blogspot.ru/2010/01/20.html

…

Структура постановки задачи. (структуру решения не нашёл)

 

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

 

2. Описание входной информации:
- перечень входной информации, - формы представления информации, структура входного документа, - количество документов,- способы контроля входных данных,- контроль интервала значений реквизита.

 

3. описание выходных документов:
-состав,- структура,- формы представления, - периодичность представления, - количество документов,- перечень пользователей,- способы контроля результатной информации,- контроль соответствия списку значений.

 

4. описание нормативно- справочной (условно- постоянной) информации:- перечень документов,- формы представления,- описание структурных единиц информации,- способы взаимодействия с переменной информацией.

 

21

- 1)      UMLдиаграммы (нигде нет конкретно про диаграммы, только про язык. Это из вики)-

UML (англ. UnifiedModelingLanguage — унифицированный язык моделирования) — языкграфического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображенияорганизационных структур.

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

 

- 2)      Диаграмма вариантов использования (USECASE)-

…

Отсюда:

https://software-testing.org/testing/chto-takoe-yuzkeys-use-case-ili-scenariy-ispolzovaniya-v-testirovanii-po.html

…

Юзкейс (UseCase) — это перечень действий, сценарий по которому пользователь взаимодействует с приложением, программой для выполнения какого-либо действия для достижения конкретной цели. Тестирование по юзкейсам проводится для того чтобы обнаружить дополнительные логические дыры и баги в приложении, которые сложно найти в тестировании индивидуальных модулей, частей приложения отдельно друг от друга. Юзкейс тестирование может проводится как часть Приемочного тестирования. Для удобства визуального восприятия UseCase часто рисуют в виде диаграмм с переходами.

Пример Юзкейсов (UseCases)

для разных типов пользователей онлайновой системы:

…

если необходимо знать всю структуру usecase здесь подробное описание есть:

http://michaelsmirnov.blogspot.ru/2011/03/uml.html

…

22

ER- диаграмма (вики)

ER-модель (от англ. entity-relationshipmodel, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемыпредметной области.

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (англ. entity-relationshipdiagram, ERD, ER-диаграмма).

Понятия «ER-модель» и «ER-диаграмма» часто не различают, хотя для визуализации ER-моделей могут быть использованы и другие графические нотации, либо визуализация может вообще не применяться (например, использоваться текстовое описание).

Модель была предложена в 1976 годуПитером Ченом^[1][2], им же предложена и самая популярная графическая нотация для модели.

…

если необходимо знать всю структуру ER- диаграмм здесь подробное описание:

http://www.mstu.edu.ru/study/materials/zelenkov/ch_2_1.html

…

 

Постановка задачи - описание задачи по определенным правилам, которые дают исчерпывающее представление о ее сущности, логике преобразования информации для получения результата. На основе постановки задач программист должен представить логику е решения и рекомендовать стандартные программные средства, пригодные для ее реализации.
Через постановку задачи, путем регламентации изложения ее содержания, устраняются трудности взаимодействия «пользователь- прикладной программист», что делает это взаимодействие более логичным и системным. Постановка задачи ведется на стадии проектирования компьютерных информационных систем. Для постановки задачи используется сведения, необходимые и достаточные для полного представления ее логической и информационной сущности. Такими сведениями располагает экономист, осуществляющий решение задачи в условиях ручной обработки или с использованием компьютерной техники. При постановке задач пользователь прежде всего должен описать информационное обеспечение, алгоритмы их решения.
Постановка задачи требует от пользователя не только профессиональных знаний той предметной области, для которой делается постановка, но и знаний компьютерных информационных технологий. Ошибки пользователя на этапе постановки задачи увеличиваются в сотни и даже в тысячи раз по своим последствиям (в зависимости от масштаба системы), если их обнаружат на конечных фазах создания или использования прикладного программного продукта. Причина заключается в том, что каждый из последующих участников создания прикладных программ не располагает информацией, необходимой для исправления содержательных ошибок.
Структура постановки задачи.
1. организационно- экономическая сущность задачи:
-назначение задачи, - цель решения, - периодичность решения, - источники поступления данных, - потребители данных, - потребители информации, - для каких подразделений, -взаимосвязь с другими подразделениями, -какими средствами решается.
2. Описание входной информации:
- перечень входной информации, - формы представления информации, структура входного документа, - количество документов,- способы контроля входных данных,- контроль интервала значений реквизита.
3. описание выходных документов:
-состав,- структура,- формы представления, - периодичность представления, - количество документов,- перечень пользователей,- способы контроля результатной информации,- контроль соответствия списку значений.
4. описание нормативно- справочной (условно- постоянной) информации:- перечень документов,- формы представления,- описание структурных единиц информации,- способы взаимодействия с переменной информацией.