Скажие, есть тут интересующиеся такими вещами, как PSP и/или формальные методы?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Personal Software Process? А Cleanroom? Или Z и другие формальные спецификации.

А то чувствую, что мало кому интересно, и не знаю, это потому что все эти методологии/принципы неправильные/устарели/никому не нужны, или просто по какой-то причине малоизвестны? Книжки-то, слава богу, в последние лет 5 программерам с Амазона легко покупать.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

2andy_iaa:, а вот бить себя пяткой в грудь необязательно. То что Software Engeneering намного шире чем верификация это более или менее очевидно;)

Жду более точных эстимейтов, и, конечно, уменьшения количества багов со временем. Также, есть такая мысль, что я могу что-то делать не очень правильно/эффективно, но не всегда очевидно, что именно. Мне нравится сама идея измерения и количественной оценки работы, может, объективно узнаю, что я законченный лентяй и не умею программить вообще... Я, в принципе, вполне доволен тем, как сейчас работаю, но всегода хочется большего;)

Насчет софта — я понимаю, что в CQG специальный дорогой софт, а ничего «наколенного» не существует? Вообще, имею надежду что-то склепать из Org-Mode Emacs’а, без всяких СУБД тупо в текстовом файлике вести всю эту бухгалтерию. Не знаю, может это наивная надежда, но по идее если это индивидуальная штука, то требования к тулзам можно порезать основательно, приспособить то, что есть. Плюс все формы на сайте SEI были вроде.

от TSP вообще не зависит, т.е. процесс индивидуальный.
во-первых решите что вы от него ждете.
вторая проблема — практическая: нужен заточеный софт. Без него будет нереально.

кроме как CQG наверно ни одна контора в СНГ не практикует.

andy_iaa, Вы часом не из CQG? А то там я уже порасспрашивал, я еще не переварил, то, что мне рассказали:) Так что вопросы обязательно будут по ходу. Самый главный вопрос по PSP — стоит ли им заморачиваться, если команда не работает по TSP, то есть просто индивидуально практиковать?

я в PSP силен, если конкретные вопросы српшивайте.

Руслан Шевченко

Ну есть довольно узкие области, где верификацией занимаются

вот уж точно рассмешили. Там где занимаются — там Software Engineering, в отличие от «наколбасим, а потом быстренько все баги пофиксим» — то что применяется в «довольно широких областях».

2 Дима Лапшин: в ваших методологиях есть что-то на тему процесса для индивидуального программиста, не команды в целом, а отдельного программера?

Я интересуюсь методологиями — правда, скорее не PSP, а больше Agile-толка. Но поскольку наша специфика работы — это regulated industries, то интересуюсь, в частности, адаптацией Agile-методологий к регуляторным требованиям, в частности — требованиям к формальной верификации и валидации.

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

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

пара бывших коллег в CQG работают, попробую спросить.

Ну с такими критериями все, что относится к Software Engineering друг с другом пересекается.
К формальным методам относятся не только спецификация требований и доказательства корректности (на практике применяются довольно редко), но и практически любой анализ семантики кода и его преобразлований (что применяется тоже редко, но чаще чем первой)

Но вобще из пояснени

Может даже есть у нас компании, в которых что-то такое применяется?

В CQG применяется, можете кинуть клич, чтобы пообщаться с ее сотрудниками

В википедии неплохие статьи:
PSP: Построение процесса разработки надо начинать с индивидуального разработчика
en.wikipedia.org/...oftware_Process
Формальные методы:
1. если использовать для спецификации — сильно помогают выразить требования однозначным недвусмысленным образом, например Z: en.wikipedia.org/...wiki/Z_notation
2. для кодирования полностью формальные методы наверное не используются (хотя www.theengineer.co.uk/...312631.article но это очень дорого), а вот полу-формальные, типа cleanroom, где вполне можно использовать естественный язык и специфицировать полу-формально, выглядит привлекательно en.wikipedia.org/...are_Engineering
PSP читал пару лет назад, потом как-то забросил. Хотя, немного начал делать self-review, и добиваться того, чтобы компилилось ну если не с первого, то второго-третьего раза, и вобщем стал более спокоен за свой код.
Более менее знаю Z, пытался писать спеки на нем, но честно говоря без особой пользы для проекта. Сейчас частично пытаюсь юзать cleanroom для написания нового кода, хотя когда спешишь или ковыряешься в старом и/или чужом коде, то как-то не до него.

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

2 Руслан Шевченко:
Общее:
1. Цели сильно пересекаются
2. В PSP опционально можно формальные методы применять, по крайней мере в курсе есть верификация по trace tables и пр. немного cleanroom-style.

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

Хм..., а ты расскажи в двух словах о чем это вообще, может кого и заинтересуеш

Хмм, вобще-то это очень разные вещи, друг к другу отношения вобще не имеющие.

Підписатись на коментарі