Сообщений в теме: 14

[Фрося]

Пятничный плач.
Уже полгода я делаю документацию ЖЦ ПО для сертификации.
УЖЕ сделанного ПО….
Я написала (задним числом) План Гарантии Качества, План Управления Качеством, План верификации……..
Нет-нет….У нас есть VSS. И ей пользуются программисты….
Но там – только код…. А под управлением конфигурации – сами знаете – что должно находиться…
Я написала кучу протоколов УК, ГК, верификации.
Я написала Требования к ПО (по готовому УЖЕ проекту – ха! )…
И протокол верификации требований (даже с какими-то сценариями..)
Я даже сделала Описание Проекта ПО (ну хорошо – что программисты чуткие ребята, и хотя бы нарисовали картинки с иерархией классов…..)
О! Это описание… Что-то из комментариев, что-то слов , что-то по исходному коду…
Вы пытались когда-нибудь делать описание проекта по исходному коду? А?
Где файлов немеряно… где комментов – мало…почти нет… при том, что авторы УЖЕ начали подзабывать – зачем они этот класс заводили…….
Я написала задним числом - как мы вносили изменения. Как проверяли, что изменения отслежены…
Я дошла до документирования процесса верификации готового продукта…..
Уу….
От инженера, занимающегося тестированием, я получила общую тетрадь с замечаниями…
Тесты? Какие-такие тесты? Какие сьюты… какие прогоны… Все – в голове…..
Т.е. – садится и проверяет… на соответствие представлению – КАК софт должен работать… Хорошо – что грамотный специалист. Действительно – проверял.
Я уговорила Начальника – что нужно ПИСАТЬ тесты. Я уговорила – выделить хоть кого-то под эту работу… Что-то пошло…. Что-то написали…
Сегодня я сломалась. Пятница. Что ж хотеть от меня?
Сегодня я планировала (опять же – задним числом!!!) сделать трассировку тестов на Требования…
Тестов – мало.. Требований – гораздо больше…
Тесты – писались из «головы».. Тесты писались «железячниками», в режиме «когда я свободен»…. в стиле «как я себе это представляю»

Все. Кончилось мое терпение… Спеклась старушка.
Уважаемые дамы и господа!!!!
Пригласите меня поработать куда-нибудь на месячишко. Можно – почти бесплатно. За обеды и транспортные расходы….
Я возьму отпуск на своем месте работы…
Просто – мне необходимо хоть одним глазком посмотреть – как это бывает:
Когда – сначала Требования к ПО, а потом – Проект, а потом код.
И при этом – кто-то уже готовит тесты… До того – как проект завершается…
И пишутся протоколы тестирования… и фиксируются все вносимые изменения…
В общем – дайте мне возможность хоть одним глазком поглядеть – как это – когда ПО делается как положено……

P.S. Готова поклясться на Конституции (или – на чем хотите) – что ничего из увиденного я не буду использовать. Никогда. Просто потому – что моему Начальнику совершенно все это не надо. А место работы я не поменяю (в силу возраста…. )

[Natalya Rukol]

Супер сообщение, Вам надо срочно написать книжку, это будет фурор :)

Просто – мне необходимо хоть одним глазком посмотреть – как это бывает:
Когда – сначала Требования к ПО, а потом – Проект, а потом код.
И при этом – кто-то уже готовит тесты… До того – как проект завершается…
И пишутся протоколы тестирования… и фиксируются все вносимые изменения…
В общем – дайте мне возможность хоть одним глазком поглядеть – как это – когда ПО делается как положено……

Думаю, здесь много желающих попасть на этот чудный остров Утопию :)

А место работы я не поменяю (в силу возраста…. )

А вот это скорее всего зря ;)

[barancev]

Думаю, здесь много желающих попасть на этот чудный остров Утопию :)

Я видел такие острова и я не желающий. По факту это превращается в антиутопию, тоталитаризм, где главным является слово "надо". Надо писать требования, надо делать проект, надо писать протоколы, надо всё фиксировать, надо, надо, надо. И кругом слежка -- метрики, отчёты, KPI...

[rps5]

Я видел такие острова и я не желающий. По факту это превращается в антиутопию, тоталитаризм, где главным является слово "надо". Надо писать требования, надо делать проект, надо писать протоколы, надо всё фиксировать, надо, надо, надо. И кругом слежка -- метрики, отчёты, KPI...

Алексей, а где антиутопия? Разве всё, что Вы перечислили, — это плохо?

[chezar]

Я видел такие острова и я не желающий. По факту это превращается в антиутопию, тоталитаризм, где главным является слово "надо". Надо писать требования, надо делать проект, надо писать протоколы, надо всё фиксировать, надо, надо, надо. И кругом слежка -- метрики, отчёты, KPI...

Алексей, а где антиутопия? Разве всё, что Вы перечислили, — это плохо?

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

[Фрося]

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

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

[chezar]

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

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

Вероятно я Вас не совсем понимаю, вы с самого начала своего повествования отметили - "УЖЕ сделанного ПО….", т.е. вы постфактум разрабатывается документацию для обеспечения технологического процесса того, что уже разработано. Я не понимаю для чего? Неужели вы думаете, что конечный потребитель будет читать эту кипу документации. Подозреваю, что скорее заказчик захочет убедиться в качестве полученного продукта, а не в том, что его производили по качественному процессу

[Фрося]

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

Ну, во - первых -- то, что я сейчас проделываю - это в корне НЕПРАВИЛЬНО. Создаваться все должно однновременно с разработкой ПО.
Во-вторых. Насчет конечного потребителя. Он - в общем, и не подозревает об этой кипе.
Насчет - качества - совершенно верно . Заказчик хочет убедится.
Смотрим ГОСТ. Р 51904. П. 12 "Документы, создаваемые в процессах жизненного цикла ПО".
Там и находим - список всх тех документов, которые необходимо создать.
Зачем? Оттуда же из ГОСТа : "Эти документы позволяют реализовывать процессы ЖЦ ПО, сертификацию системы и постсертификационную модификацию программы"
Ключевые слова - "сертификация системы"

Да.
Сразу же.
Все это эфемерное здание ЖизненногоЦикла ПО вкупе с документацией - я выстраивала ну... скажем так .... несколько теоретически.
Т.е. перелопатила ГОСТы, массу литературы., набрала знаний.
Но. Стройка моя велась - практически без внешней критики. И мало коррелируется с той реальной практикой, через которую я проходила.

[greesha]

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

Фрося, а как называется ваша должность и какова роль в этом проекте?
Вы работаете в гос. организации, или проект делается для гос. заказчика?

Спрашиваю из чистого любопытства. Судя по описанию, ваша роль - аналитик?

[barancev]

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

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

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

[Фрося]

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

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

Про мою роль.
Ну вот по осени - оказался провал по этому направлению. Я и взялась (в общем -интересно!).
Ну а поскольку провал был совсем - пришлось и Требования писать, и верификацией заниматся....
Как роль называется ? Думаю так "ААА!!!! Фрося! Постарайся!"
(ПС..... ну по весне "Ааа!! " другое было. )

[barancev]

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

Ну вот я про это и писал -- ключевое слово "надо". Надо сделать для того, чтобы пройти сертификацию. Никого не волнует, насколько это полезно для проекта. Цель совершенно иная, внешняя, никак не связанная с внутренними потребностями.

[Фрося]

Ну вот я про это и писал -- ключевое слово "надо". Надо сделать для того, чтобы пройти сертификацию. Никого не волнует, насколько это полезно для проекта. Цель совершенно иная, внешняя, никак не связанная с внутренними потребностями.

Ну что ж.. вполне допустимый подход.
Не совсем понятно, что Вы называете "внутренними потребностями"?

Полезно для проекта? А что - значит "полезно"?
Сделать софт, гарантируя опреленный уровень качества. Это - полезно для проекта?
Это - внутренняя потребность проекта?

Только вот - соблюдение ГОСТов при производстве колбасы дает хоть какие-то гарантии качества колбасы....
Как сертификация колбасного цеха...
Как и сертификация колбасы, как конечного продукта?
Так что -можно считать - что цель внешняя, ежели - колбасу-то не есть!

[barancev]

Ну что ж.. вполне допустимый подход.
Не совсем понятно, что Вы называете "внутренними потребностями"?

Полезно для проекта? А что - значит "полезно"?
Сделать софт, гарантируя опреленный уровень качества. Это - полезно для проекта?
Это - внутренняя потребность проекта?

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

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

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

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

Если кабан знает, что на короткой дороге к водопою его может подстерегать опасность (хищники, охотники), ходить более длинной дорогой "полезнее". Но если он уверен, что там никакой опасности нет, тогда "полезнее" идти короткой дорогой, потому что пить хочется, однако!

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

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

Только вот - соблюдение ГОСТов при производстве колбасы дает хоть какие-то гарантии качества колбасы....
Как сертификация колбасного цеха...
Как и сертификация колбасы, как конечного продукта?
Так что -можно считать - что цель внешняя, ежели - колбасу-то не есть!

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

[Фрося]

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

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

Но.... по предыдущему посту - "Цель совершенно иная, внешняя, никак не связанная с внутренними потребностями. "
=====================
Очень философски...
Т.е. производство качественного софта - это цель, чтобы удовлетворить потребность получении денег? Так?

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

В общем ..... пока четко сформулировать не могу.