?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Среда, еще не вечер [18 Jun 2008|12:44pm]
Требования для информационных единиц (information items, документации) суммированы в ISO/IEC 15289 Systems and software engineering — Content of systems and software life cycle process information products (Documentation). Там же приведено руководство по их разработке. Увы, в версии ISO 15289:2006 адресуется версия ISO 15288:2002, поэтому требуется довольно много работы по пониманию. Чтобы вы знали, information items бывают следующих типов:
a) record,
b) description,
c) plan,
d) procedure,
e) report,
f) request,
g) specification.

Для примера, план предназначен для определения того, когда, как и кем должны быть предприняты специфические действиядействия -- это составная часть процесса, в свою очередь действия состоят из задач). План включает:
a) Date of issue and status
b) Scope
c) Issuing organization
d) References (applicable policies, laws, standards, contracts, and other plans and references)
e) Approval authority
f) Approach for technical and management review
g) Other plans (plans or task descriptions that expand on the details of a plan)
h) Planned activities and tasks
i) Identification of tools, methods, and techniques
j) Schedules
k) Budgets and cost estimates
l) Resources and their allocation
m) Responsibilities and authority
n) Interfaces among parties involved
o) Risks and risk assessment and mitigation measures
p) Quality assurance and control measures
q) Environment, infrastructure, security, and safety
r) Training
s) Glossary
t) Change procedures and history
u) Termination process

Рекомендованные к выпуску в ходе жизненного цикла системной инженерии планы:
Acceptance plan
Acquisition plan
Asset management plan
Configuration management plan
Development plan
Documentation plan
Domain engineering plan
Infrastructure plan
Installation plan
Maintenance plan
Migration plan
Operations plan
Production plan
Project management plan
Quality assurance plan
Retirement plan
Reuse plan
Risk management plan
Software integration test plan
Software unit test plan
Strategic plan
Training plan
Validation plan
Verification plan

Существенным дополнением к этому стандарту могло бы быть понимание "учета вообще". Кажись, этот "учет вообще" неявно прописан в серии ISO 9000, но с этим нужно еще подробно разбираться -- учетность размазана по всем этим стандартам.

На закупке стандартов можно разориться, в Сети есть только "попса" типа ISO 9000. Но овчинка, похоже, стоит выделки.
* * *
Конечно, FoxIt Editor не позволяет сохранять изменения в закопирайченных защищенных .pdf. Но вы можете экспортировать страницы из таких файлов -- например, с первой по последнюю. И затем править и сохранять уже новый файл, безо всяких защит.
* * *
Если Карту практик (вариант Карты действий и результатов, в котором прописаны практики, а не работы) снизу снабдить бородой из нормативных актов, то будет план выпуска нормативных актов. Очень интересная форма работы оказалась.
post comment

Практики и нормы: проповедизация. [18 Jun 2008|02:46pm]
Я тут буду использовать терминологию из Карт действий и результатов (http://praxos.ru/index.php/Карта_действий_и_результатов).

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

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

При внедрении нормативных актов в жизнь любой нормальный человек интересуется не только тем, Когда делать и Что делать, но и Зачем делать (какой будет Результат и каковы Обстоятельства -- зачем нам вдруг понадобился именно этот Результат?), Почему именно так делать (Аргументы, связывающие Результат и Действия) и Как именно нужно делать (ибо на каждую норму нужно иметь еще десять советов, как ее выполнить, чтобы достичь ожидаемых результатов). Но этого вычитать в самом нормативном акте обычно нельзя (туманные призывы к всеобщему счастью из преамбулы не в счет).

Это означает, что при внедрении технологий, зафиксированных в стандартах ISO приходится восстанавливать полный формат для каждой прописанной там нормы-практики. Или не удивляться, если люди а) не будут следовать этим нормам, ибо не будут понимать, и б) при административном нажиме выполнят эти нормы таким образом, что ожидаемые Результаты не будут достигнуты.

Но это адова работа -- восстанавливать логику разработчиков, обеспечивать евангелиста материалом для его проповедей. Скажем, вам встретилась норма "если жив, то не убий" -- ну, и какие тут Обстоятельства, Результаты, Аргументы и Контраргументы?

Интересно также подумать и над технологиями этой работы -- содержательной проповедизации, привнесения в нормы материала, обеспечивающего их принятие критически мыслящими людьми.
2 comments|post comment

Московский инвестфорум [18 Jun 2008|11:11pm]
Общее ощущение -- пафоса на порядок меньше, иностранцев на порядок меньше, деловых переговоров на порядок больше. Если на прошлом форуме были представители инвесторов, то на этом форуме были уже инвесторы -- почувствуйте разницу. Разговор был короткий: есть команда и идея, будем немедленно переговоры переговаривать, а нету -- приходите завтра.

Вот парочка соображений из моего выступления:

1. Никто не знает, как масштабировать знаниевые сервисы. Все понимают, что софт -- это топор, а продать можно только суп из топора, но SaaS хорошо не работает, потому как так продается только простейший софт. Если софт становится чуть сложнее, то его и развернуть как SaaS сложно, и основная прибыль получается от настройки-внедрения. Собственно, "настройка" становится суровой задачей прикладного заказного программирования, но непонятно, как масштабировать такой сервис -- нет технологии быстрого масштабирования знаниевых сервисов.

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

3. Не нужно кидаться на очерденую "модную" волну параллельного программирования и многоядерных процессоров. Не в них дело: ватный код и внутри суперкомпьютера -- ватный код. Компьютерная революция еще не началась, но не в тотальной параллельности ее суть. Впрочем, инвестиции будут не в технологии компьютерной революции, а в уникальные железные системы, полученные с помощью этих технологий, спрятанных в embedded софте.

4. Удивительно слышать от инвестфондов любовь к потребительским рынкам, и примеры инвестиций в технологии, которым до потребительских рынков, как до луны.

5. Я бы оценил перспективы проектов, которые уже сегодня пытаются поиграться в жестовые/мультитач многопользовательские интерфейсы на мониторах с 4К и более пикселей, как огромные. В этой области пока практически никто не работал, ибо в природе не было таких дисплеев. Но эти технологии стремительно выходят на массовый рынок -- и на нем будет много-много новых игроков. Это хороший инвестиционный шанс для новых софтовых команд.
22 comments|post comment

navigation
[ viewing | June 18th, 2008 ]
[ go | previous day|next day ]