Софт не пишется параллельно к харду

Обсуждение программ, пользовательского обеспечения, операционных систем
Ответить
Аватара пользователя
Eugen Graf

Activity Professionalism Silver Black
guru
guru
Сообщения: 6502
Зарегистрирован: 13 ноя 2007, 02:20
Награды: 4
Версия LabVIEW: 2009
Откуда: Saarbrücken
Контактная информация:

Софт не пишется параллельно к харду

Сообщение Eugen Graf »

Такое заключение мне приходится делать почти в каждом проекте. Почему то планировщики и ведущие проектов считают что это вполне возможно.
Вчера мы первый раз собрали всю систему, состоящую из нескольких составляющих подсистем и удостовелирись в том, что прога (написаная мной) не работает, хотя прекрасно работала с симулятором. Планировалось как раз, что софт будет разрабатываться параллельно к разработке железа(сложной системы). Как всегда проблемы с поставщиками составляющих и т.д. и т.п.
Получилось что в последний день было наконец то всё собрано(не без багов) и наконец то мне выделили время потестить прогу с реальной системой. Было 9 часов вечера!!! Утром приезжает заказчик!!! Просидел до двух часов ночи в конвульсиях, но в итоге почти всё получилось.
Вопрос - как переубедить людей в надобности разработки и проверки программ с реальным, готовым железом?
Аватара пользователя
mzu2006

Professionalism Tutorials Black
doctor
doctor
Сообщения: 2456
Зарегистрирован: 16 авг 2008, 02:12
Награды: 3
Версия LabVIEW: 7.1 10 11 12
Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение mzu2006 »

Тема философская... После пары случаев, похожих на описанное тобой, я:
1. понял всю пользу формальных спецификаций
2. понял, что не только железячник должен помочь мне написать эмулятор, но и я должен написать эмулятор будущего софта + набор тестов для железячника.

всё-равно идёт какие-то притирки, изменения спецификаций, сбойное железо, но жить в целом стало много проще.
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение Pavel Krivozubov »

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

Activity Bronze
leader
leader
Сообщения: 548
Зарегистрирован: 20 авг 2009, 17:58
Награды: 2
Версия LabVIEW: 2011
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение Eugene »

в принципе железо само по себе не обязательно на начальных стадиях. но знать c чем придется работать надо в начале
все свои проекты я начинаю только после получения SOW (statement of work) от заказчика, в котором описывается все железо и задачи поставленные перед приложением. И не только я - это позволяет избежать лишних споров в конце.
Ну и конечно, нужен хотя бы день в конце для интеграции системы
We live in a graphical world.
Why not program in one?
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1327
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение AndreyDmitriev »

Вполне нормальная и знакомая ситуация, характерная для относительно небольших фирм.
В больших компаниях львиная доля времени уделяется планированию, спецификациям и тестированию. Соответственно на собственно кодирование уходит процентов двадцать-тридцать времени. Продукт создаётся долго, но и накладки редки.
Обычно более-менее большой проект проходит через серию спецификаций. Вначале пишется функциональная спецификация (так называемая MFS - Marketing Functional Specification). В ней общее описание проекта. Затем пишутся требования к программному обеспечению (SRS или Software Requirements Specification). В этой спецификации описывается поведение программы (пользователь должен иметь возможность сделать то-то и то-то). В случае взаимодействия с железом описывается реакция программы на внешние раздражители плюс общая архитектура. Наброски интерфейса также описываются в SRS. Затем пишется документ, описывающий дизайн программы (DRS - Design Requirements Spec). В этой спецификации описывается внутренняя архитектура программного продукта (где будет многопоточность, как взаимодействуют потоки, детально описываются протоколы, и т.д.). В процессе создания проверяется покрытие SRS - насколько все требования удовлетворены. Лишь затем начинается собственно кодинг. После написания каждой спецификации проводится ревью. К следующему шагу переходим только если нет никаких открытых вопросов по предыдущему шагу (это называется толлгейтс (Tollgates) митинги). После кодирования начинается тестирование и тоже не абы как, а по STS (Software Test Spec). Вот в идеале где-то так. Далее документация и запуск. Разработка софта вполне может идти параллельно железу, просто планировать надо хорошо.

Андрей.
ЗЫ
Женя, кстати, в Германии больше десяти часов в день работать запрещено, ты в курсе? :))))
Pavel

Activity
developer
developer
Сообщения: 271
Зарегистрирован: 31 июл 2009, 08:07
Награды: 1
Версия LabVIEW: 8.5

Re: Софт не пишется параллельно к харду

Сообщение Pavel »

Это наверно делается в забугорных компаниях типа Motorola, Alcatel и т.п.работающих в России В отечественных компаниях все гораздо скромнее. На предыдущем месте работы мы, к примеру, все делали сами. И из-за этого нас было сложно уволить.
Eugene

Activity Bronze
leader
leader
Сообщения: 548
Зарегистрирован: 20 авг 2009, 17:58
Награды: 2
Версия LabVIEW: 2011
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение Eugene »

и в больших фирмах тоже хватает балагана несмотря на SOW, SRS, PDR, CDR и т.п.
в start-up компаниях тоже - проекты очень динамические, в начале не знают что хотят изменения превышают 20%
We live in a graphical world.
Why not program in one?
Pavel

Activity
developer
developer
Сообщения: 271
Зарегистрирован: 31 июл 2009, 08:07
Награды: 1
Версия LabVIEW: 8.5

Re: Софт не пишется параллельно к харду

Сообщение Pavel »

Балагана хватает везде как в start-up (по нашенски в начинающих) компаниях так и в больших. В больших, ко всему прочему, добавляется еще маразм.
Аватара пользователя
Eugen Graf

Activity Professionalism Silver Black
guru
guru
Сообщения: 6502
Зарегистрирован: 13 ноя 2007, 02:20
Награды: 4
Версия LabVIEW: 2009
Откуда: Saarbrücken
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение Eugen Graf »

Да я бы не сказал что у нас балаган. Все стадии развития проекта спланированы и хорошо документированы. Но к сожалению во время выполнения проекта сроки milestones не выдерживаются, и в конце концов я остаюсь крайним, т.к. софт по идее это самая высшая ступень проекта.
Кстати у нас широко применяется так называемая V-Model организации проектов.
toto

Activity Gold Black
professional
professional
Сообщения: 390
Зарегистрирован: 07 мар 2008, 09:26
Награды: 3
Версия LabVIEW: 6i-16
Откуда: Санкт-Петербург
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение toto »

Точно, программист верхнего уровня - интерфейса системы всегда крайний...
CrazyFizik
beginner
beginner
Сообщения: 22
Зарегистрирован: 22 май 2012, 19:06
Версия LabVIEW: 2010
Откуда: Саратов
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение CrazyFizik »

Должна быть максимальная абстракция.
По-хорошему, программиста вообще не должно интересовать что за устройство будет использоваться, а конструктора, что за программное обеспечение будет использоваться.
Это все независимые процессы.
Должны быть спецефикации и прочий набор документов, руководствуясь которыми инженеры и делают свою задачу. Иначе вся эта унификация, использование абстрактных моделей нафиг никому не нужно, а без этого, себистоимость продукта возрастает, а возможности поддержки становятся скудными.
А уж, собрать все и запустить - это уже дело сервис-инженера, а по-хорошему, так вообще рабочих на линии.
А если параллельные разработки идут из рук вон плохо, значит, где-то серьезный косяк в организации работы или кто-то явно халтурит.
Лично, не раз писал ПО для работы с устройствами, которых в глаза не видел и уж точно, никогда не занимался вопросами согласования и все отлично работало. Или же варианты написания части ПО - на чем, как и кем пишутся остальные части - тоже вопрос 10й.
Также и писал документацию для программистов, которых никогда не видел и которые писали свои программы для систем, которые я никогда вживую не щупал, и в таком случае как правило проблем не возникало.
Также и железки конструировал не особо задаваясь где и как они будут работать - у меня есть документ где написано что должно быть на входе, а что на выходе, требования по массо-габаритным параметрам, контрольные сроки, спецификации по интерфейсам, да набор гостов и стандартов (по большей части, из разряда MIL-STD) - если вся документация написана правильно, проект-менеджер умеет грамотно формулировать и ставить задачи и главным элементом разработок являются регулярные совещания с протоколированием, то проблем никаких не будет.
Если уж где-то, что-то не так в итоге заработало, то это уж точно не моя вина, это уже проблема более высокого порядка - организационного.
Единственное, когда я от такого правила отступался - это когда короткое время был главным технологом темы, а потом стал главным конструктором темы - тогда да - приходилось ходить и щупать все самому. Но тут и другое положение, уже ты руководитель и должен все понять, переварить и во внятном виде представить остальным исполнителям. Но собственно это и есть главная обязанность главного конструктора.

Друге дело, то что макетные работы должны быть всегда, как минимум на завершающем этапе поискового НИР. Ну и самое главное, любой механизм принятия решения по разработкам должен быть совещательным.

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

Если, у Вас, не производят прецезионную аппаратуру, требующей, тонкой подгонки, то как раз таки параллельный подход самый верный, а сеил с ним возникают проблемы, значит, как минимум проблемы в документации, нет достаточной взаимосвязи между участниками рабочей группы и кто-то халтурит, а технологи явно зря кушают свой хлеб, раз не могут организовать техпроцесс.
CrazyFizik
beginner
beginner
Сообщения: 22
Зарегистрирован: 22 май 2012, 19:06
Версия LabVIEW: 2010
Откуда: Саратов
Контактная информация:

Re: Софт не пишется параллельно к харду

Сообщение CrazyFizik »

Eugen Graf писал(а):Да я бы не сказал что у нас балаган. Все стадии развития проекта спланированы и хорошо документированы. Но к сожалению во время выполнения проекта сроки milestones не выдерживаются, и в конце концов я остаюсь крайним, т.к. софт по идее это самая высшая ступень проекта.
Кстати у нас широко применяется так называемая V-Model организации проектов.
Ну вот собственно, получается Вы и сами ответили на частично на вопрос, V-модель не пне предусматривает работу с параллельными событиям, так что если де-юре, у Вас используется именно V-модель, а де-факто пытаются за уши притянуть параллельную разработку, то на выходе и получаем такие вот неприятные моменты - собственно симптом плохой организации производства.
Хотя лично я был всегда сторонником исключительно параллельных разработок. Что-нибудь, типа спиральной модели ну или прочие вариации итеративной модели, но это уже на вкус и цвет...
Ответить

Вернуться в «Софт»