136

Системный Анализ и Требования / Требования на изменение

« : 11 Сентября 2008, 17:16:12 »

В конторе, где я работаю, потребовалось написать постановку задачи на изменение правил формирования и печати документов по биллингу.

Ранее используемый формат не устраивает. Решили работать по науке.

Аналитик пишет документ требований и передает его в отдел проектирования. Там требования изучаются и предлагаются проектные решения.

Сразу возникла проблема:
а/ формы представления требований
б/ способы добавления решений
с/ разделение труда

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

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

Почитав требования я тоже пришел к выводу что они не очень понятны, хотя и кажется содержат  необходимую для проектирования информацию. Кроме того в тексте требований много явных указаний на решения, типа
Система должна позволять выставлять параметр Скидка по предоплате в свойствах учета
В свойства учета необходимо предусмотреть checkbox и т.п.

Хотя может так можно? Ведь требование пишется в конечном счете для программистов?

Поскольку пока форма не принята, задался вопросом, а как корректно писать требования.

Предложил такой подход.

Анализируя задачу смотрим на что в конечном итоге это должно влиять:
1. на форму счетов и расходных документов
2. на порядок и сроки их создания

Потому я предложил двигаться от конечного результата, типа.
1. Скидка по предоплате
  система должна обеспечивать возможность указания режима использования скидки по предоплате
  1.1. Величина скидки по предоплате - целое не отрицательное число
  1.2  Скидка действует до даты Х
        1.2.1 Дата Х - целое не отрицательное число в диапазоне от 1 до 30
  1.3 Скидка является внесубъектным свойством, т.е. задается один раз и распростарняется на все субъекты учета
  1.4 При формировании счетов указывается цена со скидкой для всех клиентов
2. Формирование счет-фактур и актов
   2.1 Есть фиксированная цена
         Для клиента с фиксированной ценой скидка по предоплате не применяется
   2.2 Есть задолженность
         Для клиента с задолженность скидка не применяется
   2.3 Оплата в срок
        При оплате до указанного срока (1.2.1) документы формируются со скидкой
        2.3.1 Оплата не полная
                Если опалте сделано в срок но не полностью, скидка не применяется и указывается долг клиента
        2.3.2 Оплата не в срок
                Если оплате не выполнена или выполнена после срока, скидка не применяется и указывается долг клиента

Ну и так далее. Написано по памяти могут быть противоречия.

При этом данная структура загоняется в RaQuest или EA и формируется диаграмма для более наглядного представления и анализа согласованности...

Итак вопросы
1. Форма описания требований?
2. Следует ли разделять требования?
3. Что должен содержать документ, т.е. что понимать под спецификацией требований? (для заказчика документ не пишется и у заказчика соответственно не подписывается)
4.Не следует ли иметь то что есть и показать во что нужно изменить?
5. Как лучше группировать требования и выстраивать зависимости?
6. Следует ли предлагать ГУИ прототипы в качестве требований или их оставить для проектировщиков?
7. Что следует вносить в документ аналитику, а что проектировщику?

Может еще, что добавится после....

 

137

Поздравления / Поздравляем Юрия Булуй с Днем Рождения

« : 10 Сентября 2008, 08:46:17 »

От всей души, Юра, прими наши поздравления и пожелания в этот знаменательный для тебя день.
Отличного настроения, успехов и всего, что не пожелается...

138

Обучение / Дисциплина "Анализ требований"

« : 05 Сентября 2008, 22:31:32 »

По причине объявленной в теме Дисциплина "Управление данными" вынужден был в начале семестра получить дополнительный курс.

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

За основу взял курс Маглинеца с интуит.ру

За пример для практики и в качестве задания взял пример из книги Вигерса. Там рассмотрена только одна функция и 3 ВИ, потому распределил остатки между студентами.

Курс получается не маленький на практику часов 40 или больше. Помница, Gevorg обещал помочь с постановкой курса. Ау, Юра, я готов....

139

Обучение / Дисциплина "Управление данными"

« : 05 Сентября 2008, 18:13:24 »

Так случилось, что в этом году мне придется читать данный предмет и лекции, и практику.

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

Дисциплина оказалась бесхозной. Читать кроме меня некому. Я вел лабораторный практикум. Он был направлен на освоение FoxPro. На мой взгляд он не отвечает цели и назначению курса.

Материалы лекционного курса отсуствуют. Есть только программа

Привожу выдержку и ГОС:
Основные понятия банков данных и знаний; информация и данные; предметная область банка данных; роль и место банков данных в информационных системах; пользователи банков данных; преимущества централизованного управления данными; база данных как информационная модель предметной области; система управления базой данных (СУБД); администратор базы данных; архитектура банка данных; инфологическое проектирование базы данных; выбор модели данных; иерархическая, сетевая и реляционная модели данных, их типы структур, основные операции и ограничения; представление структур данных в памяти ЭВМ; современные тенденции построения файловых систем; обзор промышленных СУБД; тенденции развития банков данных.

Поскольку курс будет читаться в следующем семестре, то у меня примерно 5 месяцев на подготовку лекций и возможно нового практикума.

Если внимательно посмотреть на программу курса и то, что сказано в ГОСе, то можно увидеть явное рассхождение.
Мне не нравится ни ГОС, ни программа.

Но ГОС "что дышло, куда повернул туда и вышло"

Программа же, как мне кажется, не отвечает заявленным целям и при этом базируется на не существующих знаниях

на знании принципов ООП, методов визуального программиро-вания в средах Visual FoxPro и Delphi, навыков программирования в среде ОС Windows 9X\NT\XP

Правда параллельно курсу идет курс по ООП. Но реально там далеко не ООП, а скорее как работать в Дельфи, что конечно не одно и тоже.

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

Сам практикум тоже в большей степени ориентирован на овладение работой в среде FoxPro, а не принципы работы с данными как таковыми. Кроме того, как я полагаю, изучая параллельно Delphi, тогда уж лучше сделать курс по использованию Delphi для создани приложений баз данных.

На мой взгляд очень мало уделяется внимание работы с языком SQL. Хотя я пытался самолично внедрять задачи, связанные с приобретением навыков использования SQL, это не очень приветствовалось вторым преподавателем - лектором. Потому пришлось отказаться...

Совершенно не уделялось внимание проектированию БД, созданию схем БД и использованию языка манипуляций DDL.

Потому обращаюсь к аудитории за помощью. Поскольку есть возможность сделать сбалансированный крус, соответствующий современному понимаю управления данными.

Нужно - темы и краткое содержание для лекций, темы темы по лабораторным работам и возможно советы по инструментарию.

Курс рассчитан на 15 лекций (пара) и 15 лабораторных (пара) + курсовая работа по проектированию БД и приложения.

Предложения по лабораторным работам:
1. Оставить FoxPro, на лекциях рассматривать примеры управления данными на базе FoxPro. Включить работу по использованию DDL и SQL - опыт есть на базе упражнений с сайта sql-ex.ru

2. Создать практикум на базе Delphi (источник Фаронов Программирование баз данных в Delphi 7). Использовать InterBase или FireBird. Включить такие элементы как триггеры, хранимые процедуры, UDF

Жду предложений...

140

Системный Анализ и Требования / Книга Системный анализ, проектирование и разработка Чарльза Вассона

« : 22 Августа 2008, 23:39:37 »

В файловом архиве добавил книгу, заявленную в теме.
Ссылка: http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=137

Читаем, переводим, критикуем, дополняем?

141

Тестирование / Автоматизированное тестирование + и -

« : 23 Июля 2008, 23:20:24 »

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

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

Однако оказалось не все так просто. Для начала с некоторыми элементами тестирования (зная, что мне это предстоит) я начал знакомиться еще на TrainingLabs. Правда сразу попал на тренинг управление рисками тестирования.

В целом мой сегодняшний опыт - 2,5 недели. Получилось так, что сразу начал изучения с инструмента по созданию тестов TestComplete. Обложился кучей книг: Тамре, Канер, Бейзер, Рэшка и т.п. Всего аж 5 книг + статьи, презентации, хелп TestCompleta.

Не знаю много или мало это 2,5 недели, чтобы получить определенные знания и начать работать. Возможно и достаточно для определенных целей.
По крайней мере, имею такой навык:
1. создание довольно гибких скриптов по тестовым сценариям на TestComplete
2. запуск тестовых заданий по расписанию в автоматическом режиме с аккуратной в нужное место записью логов прохождения тестов, посылкой сообщения и даже самого лога по почте
3. понял и настроил тестовый стенд
4. приступил к разработке набора шаблонов документов по тестированию
5. немного разобрался какие тесты бывают, каково назначение тестирование, каково его место в общей системе качества проектных решений, каково место его в процессе разработки
6. понял также, что у большинства окружающих очень скептическое мнение по поводу автоматизированного тетстирования и вообще тестирования в целом
7. понял, что в реальной практике работ часто требуется объем работы, а не его качество. И если ты бьешься целый день над возможностью получить результаты из прохождения теста сразу на почту в аккуратно расфасованном виде и с предварительым интеллектуаьным парсингом, но при этом сделан только один два простеньких теста, то тобою будут не очень довольны
8. понял, что тестирования штука столь же сложная как и любой другой этап или дисциплина проектирования
9. услышал множество строго диаметральных мнений: одна группа утверждает, что автоматизированное тестирование лажа, но при этом по сути не имеют сами никакого положительного или отрицательного опыта его использования, другая (это в основном авторы книг) очень положительно отзываются о таком подходе. Бейзер вообще утверждает (у него 40 летний опыт работы в ИТ), что ручное тестирование похоже на всадника бегущего перед мчашимся локомотивом - выглядет смешно и неудобно. Мол тестирование следует сводить у автоматизированному однозначно, все остальное ересь и глупость.

Что же я все-таки понял?
Для начала нужно ясно понять что и зачем мы собираемся тестировать. Если до этого момента тестирование проводилось, а бы как. Не было выделено в отдельную дисциплину, то трудно сразу построить сколь-нибудь серьезную систему тестирования, даже при хорошем понимании того, как это делается. Приходится понимать, что если практически использовался подход случайного тестирования, то скорее всего при начале систематического тестирования приходится выделить некоторое важное направление и двигаться в его направлении. Однако нужно точно задать цель, что мы хотим получить от этого процесса.
Если целью будет (как в нашем случае) потребность выяснить не приводит ли добавленная новая функциональность  к нарушению работы определенной части старой функциональности, то нужно понимать, что отсутствие ошибок в тестах не будет означать реальное их отсутствие.
С другой стороны нужно также понимать, что построение всеобъемливаеющей системы тестирования можно осуществить только очень активной работой, бросанием практически всех ресурсов на эту задачу. Постепенное выстраивания в ходе живого, постоянно обновляющегося проекта и изменяющегося приложения на мой взгляд практически не возможно. Если правда на каждого разработчика не будет по одному, а то и двух тестировщиков. Или элементы тетсирования будут встраиваться в саму проектную разработку.
Пока я не могу быть оптимистичным, потому остаюсь пессимистом, по крайней мере, это позволяет не разочароваться в себе.

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

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

В принципе, если удасться сделать один единый скрипт, а только менять входные параметры и сопоставлять выходные результаты с известными и достоверными, то можно все 2000 клиентов прогнать. Правда тут есть трудность: сравнение результатов будет осуществляться сравнением скриншотов или регионов. Т.е. по каждой компании делает снимок счета (из формы перваритьельного просмотра) и при прогонке теста такие скриншоты сравниваются. Тут как вы понимаете трудность именно в получении всех этих 2000 скриншотов. Даже если тратить на сохранение такого скриншота примерно 2 минуты (найти нужного клиента, вызвать его форму его счета, вызвать форму предварительного просмотра, сделать чек-поинт региона, задать имя для региона, сохранить), то очевидно для охвата всех 2000 компаний нужно 4000 минут или 67 часов или примерно 9 рабочих дней, а реально в два раза больше, т.е. три недели как минимум.

Правда можно все-таки надеяться, что таких сочетаний все-таки меньше в реальной практике и их можно всести к 100 или меньше. Тогда работу можно сделать примерно за день, без учета разработки и отладки самого скрипта. Возможно на всю эту работу нужно отвести минимум неделю.

Зато, конечно, появляется выгода, если в последствии такой скрипт запустят как минимум раз 10. Он гораздо быстрее просканирует задачу, чем бы это делал человек. Это можно выполнить ночью, к примеру. Правда все-таки остаются но.

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

Ясно, что устремленность  на автотестирование только малоперспективна и вряд ли возможна. Кроме того если сейчас я начелен на ГУИ тесты, то ясно, что следует вовлекать более устойчивые к изменению тесты, например сделав некоторые манипуляции в ГУИ, осуществить выборку требуемых данных из БД и сравнить из с контрольными.

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

142

UML SysML и пр. / Что это за отношение?

« : 23 Июля 2008, 21:57:24 »

Коллеги, столкнулся тут с ситуацией, решение по которой точного не смог получить.

В чем суть?

Пусть есть некоторый класс МойКласс и еще один ДругойМойКласс.

При этом в пределах метода класса МойКласс идет создание экземпляра ДругойМойКласс

Примером такой ситуации может служить такой вот код:

public class МойКласс
{
  public static void main(String[] args)
  {
       ДругойМойКласс обДругойМойКласс = new ДругойМойКласс();
       обДругойМойКласс.Writeln("Hello World");
  }
}

import javax.swing.JOptionPane;

public class ДругойМойКласс
{
  private Какие-тоАтрибуты;

  public void Writeln(String messageString)
  {
   /*Это функция вывода строки messageString в
    * наш импровизированный терминал.
    * */
  }

}

В каком отношении будут находится эти два класса? В отношении ассоциации, или же в отношении зависимости?
Я склоняюсь ко второму типу, хотя у Рамбо зависимость обычно используется в том случае, когда в методе класса А в качестве параметра используется класс Б...

143

Системный Анализ и Требования / Практические вопросы разработки требований

« : 21 Июля 2008, 23:51:08 »

Коллеги, у меня, так сказать, чисто практический вопрос. Хотя, можно подумать, что тут задают вопросы не чисто практические:) Конечно, все задают вопросы своей практики.

Однако я отвлекся. Здравствуйте.

Тут как-то раз greesha высказал мысль, что в теории оно может и бывает, но на практике совсем иной получается компот. Компот, естественно, получается в том случае, когда компот в голове, компот в практике, компот в управлении. Но что забавно, даже при таком вот компоте порой дело движется и довольно уверенно.

К чему это я. Да все о требованиях родимых. Пишем требования по ТЗ, пишем списками, пишем фичами, пишем вариантами использования, пишем как придется.

А когда нужно их писать, стоит ли формулировать требования, если заказчик не интересуется ими, он смотрит результат. Цена проекта оговаривается иными путями, чем через требования.

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

Такой вопрос. Скажите у Вас такая же практика? Вы примерно также устраиваете свой процесс разработки? Это вполне нормально? Если ненормально, то как лучше строить процесс?

Читаешь книги, статьи, слушаешь гуру - как много всего придумано и предложено. Однако на практике видишь совершенно собственные изобретения, которые совершенно противоречат написанному. Может дело в том, что идет это с Запада, а наша азеоповская душа устроена иначе?

144

Sparx / Реплицирование в Enterprise Architect

« : 04 Июля 2008, 22:05:09 »

Существует такая проблема. Допустим нет возможности работать в единой базе данных над одним и тем же проектом. Возникает потребность в какие-то моменты объединять (а сначала разделять) модели, с которыми приходится работать параллельно.

Вопрос: А как это можно сделать? Как объединять - разделять, поддерживать общий проект в целостности и не противоречивости?

Насчет целостности и непротиворечивости вопрос особый, но вот что мы можем подчерпнуть из справки ЕА.

Указатель. Ключевые слова: replica, replication
Создание реплики
Чтобы создать точную копию, необходимо выполнить:
1. Сначала создайте основную реплику, затем выберите Tools | Manage .EAP File | Create New Replica  и следуют за экранными инструкциями.
2. Этот процесс создает точную копию текущего проекта, который может затем быть изменен независимо, и впоследствии повторно объединен с главным проектом.

Создание основной реплики
Для создания основной реплики необходимо:
1. сделайте копию требуемого ЕА проекта
2. Выберите проект в Project Browser.
3. Выберите Tools | Manage .EAP File | Make Design Master и следуют за экранными инструкциями.

Синхронизация реплик
Для синхронизации реплики с основной репликой необходимо:
1. открыть файл с основной репликой
2. Выбрать Tools | Manage .EAP File | Synchronize Replicas
3. Найти и выбрать требуемую реплику для слияния открытого проекта с данной репликой
После слияния оба проекта становятся идентичными

Отметим, что если два и более человек работают над одним и тем же элементом (пакетом или диаграммой) при слиянии возможны проблемы выбора того, какие изменения считать главными. Чтобы избежать этого, всегда работайте в раздельных областях модели, когда используете реплики.Можно также воспользоваться  Tools | Manage .EAP File | Resolve Replication Conflicts (см соотвествующий раздел справки)

Надеюсь, я немного прояснил ситуацию. Остальное можно прочитать в справке. Если у Вас будут возникать вопросы, не стесняйтесь обращаться

145

MDA / Работа с BoldTreeView

« : 01 Июля 2008, 14:37:33 »

Так обращаюсь с гуру по работе с BOLDом.

Задача: создать представление в виде иерахического дерева с изменяющимися иконками (в зависимости от тех или иных условий).

Условия для реализации. Модель: Факультет - Группа - Студент.

Что удалось сделать - удается сделать, если в качестве источника- дескриптора использую коллекцию Факультет - она отображается в гриде, а список групп и студентов уже отображается в дереве. А хочу чтобы все в дереве,

146

Тестирование / Организация и управление процессом тестирования

« : 30 Июня 2008, 21:51:15 »

Коллеги, нужна срочная квалифицированная помощь начального уровня по вопросам тестирования функциональности программных решений.

Мне поставлена задача организовать процесс тестирования, сделать его эффективным и еще разработать эти самые тесты.

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

Потребовалась система контроля выпускаемых патчей и проверки их на соответствие функциональным требованиям, правилам расчетов и т.п. С целью свести проблемы такого характера к минимуму, повысить качество и устойчивость ПО в целом.

Процесс тестирования, конечно, существует, но в свободной не системной форме. Существует потребность в создании такой системы, потому у меня большая просьба.

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

147

Системный Анализ и Требования / Перенесено: [Термин] trace

« : 26 Июня 2008, 23:17:43 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=798.0

148

MDA / Перенесено: [Термин] MDA

« : 26 Июня 2008, 23:17:08 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=805.0

149

Для всех / Перенесено: [Термин] Allocated requirements

« : 26 Июня 2008, 23:15:49 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=799.0

150

Системный Анализ и Требования / Перенесено: [Термин] IPD - Integrated Product Development

« : 26 Июня 2008, 23:15:10 »

Тема перенесена в Термины и Определения.

http://www.uml2.ru/forum/index.php?topic=803.0