Шутка юмора

Отличную мысль подсмотрел на http://it-boost.com/dreamteam

Почти всем не важно быть на первом месте, и почти всем – очень важно не быть на последнем или предпоследнем


Какой вывод можно из этого сделать - в более менее большой команде необходим 

• штатный "задрот"
• задротная позиция
• задротные обязанности 

То о чем так много говорили, на моей памяти уже 3-и года как минимум, случилось
Вышел СервисДеск от Майкрософта.

Цен еще не знаю, но судя по тех возможностям - прямой "убывец" HP Service Manager и BMC Remedy ITSM Suite.

Хотя конечно Axapta не убила SAP.

Зачем ограничивать себя границами? Маркерная стена это круто

Искал маркерную пленку, а нашел вот это. Маркерная краска.

Рекомендую всем в офисе. если АХО уломаете.

Вот теперь у меня мысли покрасить в коридоре стену. Для рисования.

Что должно входить в документацию на АС. Часть 2.

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

Итак - а кому нужна вообще документация? Ведь первый повод отказа от документирования - звучит именно так: "Ее все равно никто не будет читать кроме автора!"

Пишем ТЗ: Требования по сохранности информации

Простой и понятный раздел если не понимать его буквально

---

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

---

Если вам не требуется сохранять информацию с  нулевой потерей, то чтобы не напрягаться, следует написать что-то подобного вида:

Каталог публичных "Каталогов ИТ услуг"

В блоге нашел список публичных Каталогов ИТ услуг.
Если вы занимаетесь ITILом то очень рекомендую, по крайней мере как образец демонстрации  ихнего подхода вашему "тупому" заказчику. Особенно когда он играет в "микроменеджмент" и "полное покрытие"

Пишем ТЗ: Требования к надежности

Этот раздел на вой взгляд самый не нужный в современных АС общего назначения, то есть 90-а% всех АС разрабатываемых сейчас.

Что должно входить в документацию на АС?

Интересный вопрос.
Сколько людей, столько мнений. В ГОСТ34 этих документов 2-е страницы -).
И хотя у меня 4-е выделенных человека описывают проектные решения я его, ГОСТ, не поддерживаю.

По моему мнению документация на АС должна содержать только документы востребованные для:
1. обязательно - Эксплуатации
2. необязательно - Сопровождения

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

Пишем документацию: Функциональная схема

Описание функциональности АС (П2, ПД и тп) неплохо будет проиллюстрировать картинкой - Схемой функциональной структуры.

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

• описать состав функциональных подсистем
• описать состав входящей информации
• описать состав исходящей информации
• описать схему информационных потоков

Схема достаточно просто делается и для меня в том числе является реальным инструментом проектирования. Схемка включает следующие элементы:

• квадратики изображающие функциональные подсистемы (например для сервисдеск системы: подсистема управления инцидентами; подсистема справочников, подсистема КБД, подсистема SLA).
• стрелочки входящие в квадратик подсистемы извне (от других АС или людей)
• стрелочки исходящие из квадратика подсистемы вовне (к другим АС или людям)
• стрелочки между квадратиками подсистем

Все достаточно просто и легко реализуемо. Главное искусство не мельчить и сохранять требуемую детализацию.
Опыт показывает, что схема читаема даже совсем тупыми заказчиками, раз; и если у вас красивой схемки не получается то либо вы хреново чертите, либо функциональный дизайн вашей АС полное говно и его надо менять -)