16

Методологии / Положение о контроле соответствия требованиям

« : 29 Ноября 2013, 11:25:26 »

Есть организация, которая обслуживает интернет-сайт электронных торгов.
Как к самому сайту, так и к деятельности организации в целом установлены определенные требования.
Для этой организации надо написать организационный документ, который примерно можно назвать "Положение о контроле соответствия требованиям...".
То есть нужно построить систему контроля, которая отслеживает как бизнес-показатели так и ряд технических показателей, и в случае выхода их за определенные критические рамки предпринимает необходимые действия.

Помогите разобраться с написанием этого документа.

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

Может быть у кого-нибудь образец есть?

Поиском в интернете нашел много информации по внутреннему контролю.
Но он касается только финансовой деятельности организации.

В общем подскажите, пожалуйста, направление - куда двигаться, что искать, о чем писать?

17

Системный Анализ и Требования / Пользовательские истории и ГОСТ 34

« : 19 Ноября 2013, 19:23:23 »

Здравствуйте!

Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 34.
Недавно руководство проекта решило доработать ТЗ и добавить в него ... "пользовательские истории", и поручили мне сделать это.
До этого я, конечно, про пользовательские истории слышал, однако сам никогда их не писал и в ТЗ не использовал.
Приходится самому кое-что додумывать.

У меня созрели некоторые тезисы по решению поставленной мне задачи, но есть некоторая доля неуверенности в правильности.
В связи с этим прошу обсудить сложившееся у меня решение, и поправить меня в чем я не прав.

Вот что я надумал.
1) Самый важный вопрос. Правильно ли я понимаю суть пользовательских историй?
Пользовательские истории - это способ представления пользовательских требований (один из способов, есть и другие способы их представления, например сценарии использования).
Отличаются они тем, что написаны просто и кратко наиболее понятным для пользователей языком, без лишней детализации.
2) Вопрос о месте пользовательских историй в структуре ТЗ:
    2.1) Вообще пользовательские требования формируются еще до формирования ТЗ. И вообще говоря в ТЗ им не место.
    2.2) Ну раз уж их нужно добавить в ТЗ, то я думаю, что лучше это сделать в разделе "Характеристика объекта автоматизации". Для этого планирую сделать в этом разделе подраздел - так и назову его - "Пользовательские истории".
3) Вообще у нас не одно ТЗ, а целый комплект. Основное ТЗ - это ТЗ на систему в целом, и есть еще несколько ТЗ по подсистемам. Одна из подсистем - это программная часть системы. И руководство предлагает включить пользовательские истории не в ТЗ на систему, а в ТЗ на программный продукт, который реализует основную функциональность всей системы. Я с этим не согласен, но как переубедить руководство? Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.

Что скажете, что посоветуете?

18

Системный Анализ и Требования / ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 11 Июля 2013, 20:43:01 »

Как известно, один из самых важных разделов ТЗ - это "Назначение и цели создания системы".
Предлагаю обсудить разницу между этими двумя понятиями: "назначение" и "цели".
На интуитивном уровне мне кажется, что это разные уровни абстракции задач, решаемых системой.
То есть , все задачи можно "собрать вместе" в некие группы и назвать их целями, а цели в свою очередь - в назначение.
Может быть я не прав?
Помогите осознать истинное значение этих понятий в ТЗ.

19

Системный Анализ и Требования / Применяются ли методы Goal modeling при разработке требований?

« : 02 Июля 2013, 15:34:13 »

Кажется, методы "моделирования целей" (http://en.wikipedia.org/wiki/Goal_modeling) для разработки требований мало используются.
Например: http://en.wikipedia.org/wiki/KAOS_(software_development).
Интересно, почему?
Из участников форума кто-нибудь ими пользуется или чем-то подобным?

20

Теория моделирования и нотации / Декомпозиция в Flying Logic при моделировании причинно-следственных связей

« : 21 Марта 2013, 17:36:44 »

Этот вопрос навеян по результатам общения в теме: http://www.uml2.ru/forum/index.php?topic=5307.0

Вопрос такой.

При построении диаграммы ДТР в Flying Logic мне не хватало декомпозиции: количество элементов на диаграмме получилось очень большим.
Было бы удобно, если бы можно было построить ДТР в виде нескольких взаимосвязанных диаграмм, соответствующих разным уровням абстракции рассматриваемой проблемы.

Может быть это можно как-то сделать в Flying Logic?
Или какой-нибудь способ разрешения сложности ДТР посоветуете?

21

Управление Проектом / Как правильно доработать СДР? Какой применить способ декомпозиции к новой СДР?

« : 21 Марта 2013, 10:56:37 »

Суть проблемы в том, что мне не совсем понятно как внести изменения в существующую структуру декомпозиции работ (составлена в MS Project 2010), и передать смысл этих изменений.
При добавление новых работ для реализации новой функциональности ПО в существующую СДР не отражается общее назначение этих работ.

Подробности:
Выполняется проект по разработке ПО.
Проект, вернее СДР, составлен по принципу "конечного продукта" и его составных частей, т. е. разрабатываемое ПО разделено на "подсистемы". Эти подсистемы в совокупности выполняют требуемые функции.
В общем СДР выглядит так:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.

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

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
    1.4. Элемент 1.4.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3. (изменение)
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
    3.4. Элемент 3.4.

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

Можно доработать СДР так: создать новый пункт (4) и собрать работы для реализации новой функциональности в этот пункт:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
4. Новая функциональность
    1.4. Элемент 1.4.
    2.3. Элемент 2.3. (изменение)
    3.4. Элемент 3.4.
Но так я считаю тоже будет неправильно. Так как теперь СДР составлена путем смешения разных подходов.

Как же правильно построить СДР, чтобы совместить и подход по результату и функциональный подход?
Для поиска ответа я даже для себя перевел документ PMI Practice Standard for WBS. 2nd edition. Однако четкого ответа так и не нашел. Там сказано, что можно строить и так, и так. Но как это совместить - не ясно.

Дайте пожалуйста какие-нибудь советы.

22

Управление Проектом / Что такое план? Академическое определение

« : 17 Марта 2013, 02:14:25 »

Наткнулся на тему, в которой было такое сообщение:

План не может содержать действий и/или исполнителей и/или трудоемкостей.

Если хотите академическое определение то:
Если более простыми словами, то:
План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.
Как только вы написали действие вместо результата, все - это более не план. И эта диаграмма перестала быть актуальной, как только вы закончили ее рисовать.

В своем время я сам долго искал определение плана для диплома, но так и не нашел определения, с которым был бы согласен на 100%.
Скажите пожалуйста:
1) источник, откуда вы взяли это определение
2) как по-вашему будет называться последовательность действий для достижения результата?

23

Теория моделирования и нотации / Моделирование связей между сущностями "цель - задача - средство решения"

« : 12 Февраля 2013, 12:37:47 »

Подскажите пожалуйста,
существуют ли языки и средства моделирования для изображения в виде диаграммы упомянутых в теме сущностей и связей между ними: "цель - задача - средство решения".
С учетом их иерархии.
Это не связано с программным обеспечением, возможно это больше имеет отношение к бизнес-анализу?

Не могу пока четко сформулировать свой вопрос, попробую объяснить на примере.
Допустим, я вчера прилетел в незнакомый мне город и мне нужно сегодня в 15-00 быть в точке Б этого города, а сейчас я нахожусь в гостинице в точке А.
Для этого я должен выполнить следующие задачи:
1) одеться (так как меня разбудили звонком в кровати)
2) собрать информацию о транспорте, которым я могу добраться в точку Б, и выбрать наиболее подходящий транспорт
3) каким-то образом попасть на этот транспорт
4) на транспорте добраться до точки Б

Каждая из перечисленных 4-х задач является "задачей" по отношению к вышестоящей цели.
Однако, на уровне рассмотрения самой задачи, ее тоже нужно решить какими-то средствами, то есть на этом уровне задача делится на подзадачи, то есть она является "целью" для "нижележащих" подзадач.

Например.

Пункт (2) можно разделить на:
2.1. узнать телефоны головных организаций доступных видов транспорта в этом городе (такси, маршрутка, электричка)
2.2. позвонить по каждому из этих телефонов и узнать расписание движения, стоимость и прочее
Далее, чтобы узнать телефоны транспорта нужно:
2.1.1. позвонить в ресепшин гостиницы и узнать у них телефоны
и т.д.

Если я решил добираться на мартшрутке, то одна из подзадач пункта (4) будет выглядеть:
4.х.1. достать 30 руб. из кошелька
4.х.2. передать 30 руб. кондуктору (или водителю) маршрутки

И так далее, думаю идея понятна.

Так вот существуют ли программные средства моделирования таких зависимостей между отдельными действиями\операциями, чтобы из этой модели было ясно какой уровень иерархии рассматривается, что есть цель на этом уровне, какие задачи и (желательно) в какой последовательности должны быть выполнены и при помощи каких средств?

24

ПО Аналитика / Как в объектно-ориентированной модели (PowerDesigner) создать подсистему?

« : 05 Февраля 2013, 16:51:07 »

Создаю модель в PowerDesigner (object-oriented model).
На диаграмме верхнего уровня (Class Diagram) хочу нарисовать, что вся система состоит из нескольких подсистем.
Вроде бы все просто. В спецификации языка UML есть подсистемы.

Но в PowerDesigner-е значка для подсистемы не нашел

Помогите разобраться в чем дело?

25

Теория моделирования и нотации / Какую диаграмму и нотацию использовать для моделирования вызовов процедур?

« : 16 Ноября 2012, 10:24:59 »

Здравствуйте!

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

Чтобы учесть все на что может повлиять изменение этой процедуры, я бы хотел составить схему вызовов: методы изобразить квадратиками, и линия со стрелкой показывала бы кто кого вызывает. Но хотелось бы все это сделать в рамках стандарта UML.

Вопрос в том, какая диаграмма в UML больше всего подходит для отображения связей между методами программы, между методами объектов программы?