Поиск:
Расширенный поиск

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

ZTM представляет собой единое структурированное хранилище информации связанной с ABAP-разработкой.

Основной концепцией является то что ВСЕ ИЗМЕНЕНИЯ В СИСТЕМЕ ДОЛЖНЫ ДЕЛАТЬСЯ НА ОСНОВАНИИ ДОКУМЕНТА.

Документом в ZTM является ЗАДАЧА, она же является контейнером хранения информации. К ней привязываются работы, объекты, файлы(тз, шаблоны документов, файлы запросов и т.д.), замечания, фактически измененные объекты.

 Для осуществления более полного контроля за разработкой необходимо в систему клиента импортировать запрос и настроить abap-соединение с системой ZTM.

В этом случае при изменении любого объекта ведения и переноса необходимо будет сначала привязать его к ЗАДАЧЕ, в противном случае система не даст изменить этот объект. Потом все измененные объекты можно просмотреть в ZTM c указанием даты/времени  и наименования рабочей станции с которой производились изменения. Это дает более полный контроль за разработкой и всегда сохраняется история разработки(какие объекты, когда и кем были изменены в процессе работы над задачей).

 Интерфейс ZTM основан на CxGrid for SAP и состоит  из нескольких слоев.

Основной слой

Основной слой

Основной слой содержит список задач с необходимыми атрибутами и действиями. Внешний вид является полностью настраиваемым для каждого конкретного пользователя(согласно технологии и концепции CxGrid).

При раскрытии задачи появляются дополнительные слои:

Работы

Обьекты

Файлы

Замечания

Консультант

Измененные обьекты

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

Задача

Задача является документом-основанием и контейнером хранения информации.

Добавление задачи осуществляется при сфокусированном основном слое. В этом случае на панели инструментов появляются соответствующие кнопки.

При добавлении задачи указываются основные параметры.

Все остальные атрибуты указываются в слое "Задачи". При добавлении так же возможно отправить уведомление исполнителю посредством email. Так же это можно сделать потом, из панели инструментов.

Адрес, тему и текст письма можно изменить в процессе отправки. Отправка писем осуществляется на внешний email прописанный в свойствах пользователя-исполнителя посредством модуля send_mail комплекса StS-connector.

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

При своевременном и аккуратном заполнении всех атрибутов задачи потом упрощается получение разнообразных отчетов.

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

 

При правильно заполненном типе задачи(атрибут "тип задачи" можно переименовать), при закрытии проекта облегчается написание сопроводительной документации клиенту. К примеру, задача подразумевает либо копирование стандартных отчетов в Z-отчет, либо использование каких-либо объектов стандарта(например программа содержит какие-нибудь J-include, которые SAP патчит регулярно), которые могут измениться в процессе установки патчей. В таком случае задаче выставляется тип-"Критично для сопровождения", и при написании документации, берутся задачи с таким типом, и из объектов привязанных к задаче создается список объектов системы за которыми клиенту необходимо следить при установке патчей.

 

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

Данный фильтр сохраняется путем сохранения варианта отображения слоя.

 При передачи задачи в проверку, необходимо заполнить список объектов и отправить уведомление консультанту. Для этого предназначена кнопка "Отправить уведомление консультанту". В этом случае консультанту будет отправлено письмо с указанием запросов и объектов из этих запросов привязанных к задаче.

Работы

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

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

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

Обьекты

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

При фокусировании слоя "Объекты" на панели инструментов появляются соответствующие кнопки.

Объекты берутся из запросов в системе клиента(в систему клиента ничего устанавливать не надо). Достаточно выбрать систему и ввести логин.

После этого необходимо выбрать запрос

После этого все объекты включенные в запрос будут присоединены к задаче.

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

После того как запросы будут деблокированы, можно(нужно) присоединить к задаче и файлы запросов. Делается это аналогично, за исключением того что запросы выбирать не надо, они берутся из присоединенных запросов. Если какая то часть запросов не деблокирована(соответственно нет файлов) будет написано: "Файлов:0", если все нормально то "Файлов:2".

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

А также существенно облегчается аудит разработки( на основании чего и когда был изменен тот или иной объект системы).

Файлы

Слой "Файлы" служит для отображения файлов привязанных к задаче. Это могут быть ТЗ, шаблоны отчетов, файлы запросов и т.д. и т.п. Т.е. любой файл, только необходимо чтобы расширение файла было зарегистрировано в системе. Транзакция SMW0->Ведение MIME-типов.

Замечания

Слой "Замечания" служит для отображения информации о замечаниях, предложениях ошибках и т.д. к задаче. Сюда консультант(или клиент) может вносить свои замечания, ошибки к задаче.

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

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

Консультант

Слой "Консультант" служит просто для отображения контактной информации о консультанте ведущем задачу

Измененные объекты

Слой "Измененные объекты" служит об информации о фактически измененных объектах в процессе работы над задачей.

Данные в этот слой попадают только при установленной клиентской части. Клиентская часть представляет из себя реализацию системного BADI, которое при любом изменении объекта ведения и переноса предлагает привязать этот объект к задаче в ZTM. Для этого в системе клиента также необходимо определить abap-соединение с системой ZTM. Это делается в SM59.

По окончании проекта данную реализацию можно просто деактивировать.

Данная информация служит для аудита изменений системы. Что, когда и кем было изменено.Если на слое "Объекты" все это лежит на совести того кто изменял этот объект(все надо делать ручками), то здесь все делает система, и в случае отказа от присоединения объекта к задаче, система не даст его изменить.

Данная информация может также служить в процессе претензий со стороны клиента. Если в ZTM стоит информация что последний раз объект изменялся 01.01.2010 в 13:40, а в системе клиента дата изменения - 01.03.2010, соответственно у клиента претензии к самому себе.

Здесь отображается только время последнего изменения объекта, в базе хранятся все изменения объекта. Т.е. если мы 1000 раз нажали кнопку edit, то в базе будет 1000 записей, а отображаться только последняя. Так что, что-то отследить - не проблема.

PS. После того как я все это сделал, и оно стало работать посетила меня идея. А неплохо было бы именть доступ к этой информации не имея под рукой сапа, с коммуникатора. Руки в ноги и вперед. Установил на сервер клиента Dropbox, синхронизировал данные сапа и папки DropBox и лафа: Сидишь в пивнушке, пьешь пиво. Тебе прилетает мыло что у тебя новое тз, ты его открываешь, смотришь что пару часиков оно может потерпеть, и продолжаешь наслаждаться жизнью. Или пишешь консультанту что ТЗ надо доработать, возникли такие-то вопросы.

 

 

 

Delicious Digg Facebook Fark MySpace