Этапы разработки ПО

[>TEHb<]

Господа, а не кажется ли вам, что раздел предполагает специфику ПО конкретно для микроконтроллеров? Там всё довольно сильно отличается от программ для больших ЭВМ. Что такое агиле вообще? Звучит плохо.

[Муркиз]

Понятно. Как тут выражается молодежь - явный слив.

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

[LastHopeMan]

>TEHb<, вполне вероятно, но автор умолчал подробности, да и "язык Си" - его родина ПК и вопросы по Си воспринимаются с этой стороны. Вот если бы он про ассмеблер спросил, скорее бы все начали про МК сразу советы раздавать.
По поводу процесса, мне кажется для МК не должны сильно отличаться. Разве что тестировать сложнее, потому что в памяти обычно бесконечное число попыток, а вот в случае МК может быть слишком дорога цена тестирования. Например, операционка дрона, который должен висеть над водой и ловить рыбу. Представляете, как будет обидно его утопить Одного большого дрона уже потеряли на другой планете недавно во время бета теста.
Хотя если конечно Вы имеете ввиду еще и разработку схемы (т.е. МК лежит в виде QFN чипа еще), разводку платы, ну и т.д., тогда да, сильно отличается и я тут даже фантазировать не стану. А если нет, то ну в упор не вижу разницы. Ну вот разве что тестирование можно было бы разбить на этапы отдельные типа до подключения, при неполном подключении и уже в полноценном устройстве. Что касается софта, который подразумевает взаимодействия МК и ПК, то опыт работы с клиент-серверными решениями подсказывает, что ничего хитрого на пути быть не должно, кроме опять же тестирования аппаратной части. Предположим, делаем управление дроном с ПК. Уже на этапе написания ТЗ мы договаривались, какие процессы будут на стороне дрона (летать, рассчитывать влияние внешних факторов и компенсировать их аппаратно, передавать изображение, записывать изображение), а какие на стороне проги (передавать команды, выводить показания окружающей среды, выводить изображение, рассчитывать оптимальные пути). Вот здесь разве что самым особенным вижу необходимость прогу на ПК привести в наиболее актуальное состояние до всех тестов дрона. Но это ж не нужно под каждый проект индивидуально расписывать все равно, потому что вводные разные. Или я что-то упускаю?

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

Простой план разработки, положенный на диаграмму Ганта и расписанный по исполнителям, куда более полезен на практике для отдельно взятого проекта. Айтишный лагерь всегда делился на 2 группы: тех, кто много говорит. И тех, кто много делает. Поэтому и инструменты выбираются в зависимости от принадлежности айтишного руководства к одной из них.


Муркиз, так не сливайся, ответь на мои вопросы объективно. Раз перешел на личности - будь добр оформить свой "профиль". А пока что я потерял интерес к этой высоко интеллектуальной беседе на тему ниочем и непонятно с кем. Тем более вижу практически полное отсутствие понимания реальности в данной области.

Добавлено after 27 minutes 21 second:
>TEHb<, ну и конечно же я пишу про тот случай, когда не требуется реверс-инженеринг типа "вот инструкция от прибора, вот прибор, хочу такой же". Для таких случаев проще обратиться к друзьям китайцам.. главное иметь хорошего переводчика

[OKF]

У меня был проектик, начал с 1990-го. На ассемблере. В трёх модификациях железа. Думал до 2000-го дотянет. Дотянул до 2012-го. 36000+ строк. Порядка сотни изделий, активная эксплуатация, люди, деньги... Правда, софт апгрейдился постоянно. То одно надо, то другое...

Добавлено after 50 minutes 38 seconds:
Относительно этапов. От многого зависит. Когда у тебя есть время и возможности, можно, конечно, всё расписать от и до. Но, зачастую, ничего этого нет. Нет ни денег, ни времени. И вот от всего этого начинаешь плясать. Запустил пилотный, заказчику понравилось, появились средства, а затем уже начинаешь раскручивать. Конечно, если бы бабки и время были изначально, тогда да, всё было бы иначе. И тогда не пришлось бы всё переделывать.( А это лишня трата средств. И для себя, и для заказчика.

[Муркиз]

Хороший учитель развивает возможности ученика до возможного предела.
А великий учитель сразу видит этот предел.

[jcxz]

VladislavS писал(а):

Всё гораздо проще в жизни:
1. Запустить IDE
2. Создать проект
3. Написать код
4. Скомпилировать
5. Исправить ошибки
6. Скомпилировать
7. Протестировать результат
8. Вернуться к 3
9. Прочитать ТЗ

Это когда "программируют" не приходя в сознание.
PS: Не вижу пункта "придумывание алгоритма" в вашем flow chart.

Добавлено after 4 minutes 42 seconds:

OKF писал(а):

У меня был проектик, начал с 1990-го. На ассемблере. В трёх модификациях железа. Думал до 2000-го дотянет. Дотянул до 2012-го. 36000+ строк. Порядка сотни изделий, активная эксплуатация, люди, деньги... Правда, софт апгрейдился постоянно. То одно надо, то другое...

Надо же - самые турбулёнтные времена пережил. Слом парадигмы.
Перерос из перфокарт во флешь.

PS: Это-ж сколько перфокарт он занимал? Слыхал, что ёмкость одной перфокарты была == 1 строке текста (80 символов). Получается = 36тыс. перфокарт???

[linkov1959]

Программировал еще в двоичном коде, сын программировал раньше, чем стал говорить, а в 10 лет сказал - папа, ты дурак! И оказался прав!... он не программирует, а торгует ПО.

[DX168B]

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

[LastHopeMan]

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

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

Добавлено after 4 minutes 50 seconds:
А если делать иначе, то возникает следующая вилка.
1. Клиент не в состоянии подписать документ, потому что написанное его не устраивает, т.к. он ничего не понимает (какие нафиг таблицы, регистры, формы, типы данных, циклы...)
2. С клиентом подписали бумагу, даем программистам-кодерам, а они на свое усмотрение все, что не формализовано програют и тем самым запарывают замысел технологов-аналитиков, которые работали с клиентом и где-то у себя в голове наравне с клиентом представили совсем иную картину.

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

Добавлено after 3 minutes 58 seconds:
Кстати сполна поработав и с внутренними клиентами и с внешними: на процесс разработки очень влияет необходимость подписания договора. Очень сильное удорожание, при оценке сроков и согласованиях всех мелочей до написания ТЗ. Потому решил на франчей больше не работать, т.к. просто обидно смотреть, как куча человеко-часов тратится на то, что даже в самой суровой внутренней бюрократии можно было обойти.

[>TEHb<]

скорее бы все начали про МК сразу советы раздавать.

Так тема и находится в разделе "микроконтроллеры и ПЛИС". Именно из-за этого я и считаю, что вопрос не про большие машины.

Разница между ПК и микроконтроллером на мой взгляд в том, насколько программист оторван от аппарата, на котором выполняется программа. Под ОС как? Нужен ввод-вывод? Дёрнул соответствующий системный вызов и готово. Операционка и драйверы там сами как-нибудь разберутся. Отрисовка интерфейса всякого тоже лежит вне прикладной программы. А микроконтроллерами всё соооовсем не так. HAL или ардуину не берём в расчёт, потому что это всё равно далеко от больших и даже не ОС вовсе. По сути, программируя под голое железо программист 1) может 2) вынужден создавать некий аналог операционной системы, заточенной под конкретную задачу. И вот тут прозвучали очень правильные по-моему слова про архитектуру. Её необходимо совершенно иначе продумывать. Вместо stdio конкретная периферия , вместо окошка рисуй сам на экране! Ну и всё в таком духе. И, что самое главное, взаимодействие всех этих процессов.

[LastHopeMan]

>TEHb<, давным давно я учился на системного программиста. Это как раз тот, который должен писать биосы, операционки и драйверы для нулячего железа. Если посмотреть в прошлое, то будто как раз на МК учился кодить, хотя это не так, конечно же я тогда кодил только на ПК и для ПК. Но если бы тогда знал про существование МК, то точно бы перешел на эту сторону. Работа системного программиста мало чем отличается от работы на МК, как по мне. Я бы поставил два равенства
1. Системный программист ПК = Программист МК
2. Программист ПК = Программист МК, пишущий на IDE с библиотеками.
Плюс на МК тоже какие-то операционки есть, насколько мне известно. Под ту же ардуину есть лоадер, который помогает шиться с нее по USB, а не писать напрямую во флеш. А для ESP серии предустановлена FreeRTOS, которая неплохо так исполняет многозадачность, хоть и кушает ресурс. Да наверняка есть платные операционки. Просто мы привыкли ПК рассматривать как очень узко специализированное устройство, поэтому написать свою ОС для домашнего ПК - это можно только под ковидом с 40 градусами такую идею поймать =) Тем более уже гигагерцы и террабайты... кому сейчас вообще суровая оптимизация нужна. Кому нужно поближе к железу, ставят линукс и на этом всё. А с контроллерами попроще в этом плане: мы точно знаем, что в этом кастрированном устройстве нам крайне желательно быть ближе к железу, иметь меньше накладных расходов (например, не использовать многозадачность если не требуется, или загружать по несколько пинов за раз и так далее). Ну и написание операционки под хорошо документированный в даташите МК, имея фирменную IDE... не сравнится с написанием ОС для ПК, где даташитов в свободном полёте ноль, стандарты по большей части "засекречены", еще куча устройств всяких разных, обязательных в поддержке операционкой (да даже один конкретный набор стандартного ПК запрогать это АДъ). Короче для МК писать низкий код сам бог велел, все условия созданы для этого на сегодняшний момент. Потому и пишут под задачу. Ну и еще потому что софт для ПК сериализуется при помощи пользователей и от него требуют универсальности, а софт для МК при помощи прошивки и от него требуют чтобы просто идеально работал на отдельно взятом проекте устройства - это даже момент поважнее.

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


jcxz, насчет перфокарт, это Вы потроллили конечно, но Вы наверное не застали те времена. Дело в том, что еще в середине девяностых у меня был старенький компик на 80286 процессоре с 640кб оперативки и 40мб жестким диском. Аж целых 12 мегагерц! И я тогда на бейсике уже проги писал. Перфокарт в нем не было, это совершенно точно. Только дискеты по 1.4мб. Думаю, что у организаций такого добра было пораньше, чем у меня появился.

[jcxz]

LastHopeMan писал(а):

jcxz, насчет перфокарт, это Вы потроллили конечно, но Вы наверное не застали те времена. Дело в том, что еще в середине девяностых у меня был старенький компик на 80286 процессоре с 640кб оперативки и 40мб жестким диском. Аж целых 12 мегагерц! И я тогда на бейсике уже проги писал. Перфокарт в нем не было, это совершенно точно. Только дискеты по 1.4мб. Думаю, что у организаций такого добра было пораньше, чем у меня появился.

Вообще-то "середина 90-хх" и "1990-й" - далеко не одно и то же. Не путайте. 1990-й - это самый расцвет Спектрумов. И о домашних персоналках тогда можно было только мечтать. Большинству населения 1/6 части суши. И вообще - это домашние и офисные погремушки. А вот в промышленности тогда как я понимаю - ещё вовсю пользовали перфокарты. В управлении тех.процессами изменения происходят гораздо медленнее.
И на бейсике к середине 90-хх писать я уже бросил. Уже перешёл на ассемблер.

[LastHopeMan]

jcxz, я невнимательно прочитал тот пост. Да, конечно же конкретно 1990й был явно отстойный в плане ПК.

[Муркиз]

Это как посмотреть. На ПК я уже в 86 году вовсю работал, а в 89 году уже учебный класс запустил в работу на Искрах 1033, а в институте уже более полусотни 286 работало.

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

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

И причем - попытки в 10х годах заменить программу организации занятий , переписать ее под выеду, успеха не имели . Возможностей старой версии начала 90 Деканата так и не смогли реализовать. По простой причине - программисты 10хх годов уже не владели аппаратом сетевых расчетов, да ещё с вероятностным составом событий.

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

Если задача сложная, то результат будет аналогичен исходу басни Крылова...

А иначе... Ещё в 80 году мы с коллегой строили модель работы лифтовой группы с зонной организацией работы. Это для небоскребов такие требуются.
Первая версия программы, написанная по классике, что нам преподавали, заткнулась после 10 часов счета по лимиту времени - я тогда ее на все МГУ считал, на комплексе Эльбрус, а там время кваетовалось на пользователя.
Когда же я прикинул , сколько ещё нужно машинного счета, то мы тихо сползли... От 300 до 500 часов счета !
Ну об этом и мечтать было невозможно, там был предел - 10 часов на кафедру в неделю и 50 метров распечатки - так что пришлось сесть и хорошо подумать над программой.

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

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

[LastHopeMan]

Муркиз писал(а):

По поводу ТЗ - и начинаете с катастрофической ошибки - прикладной заказчик пишет ТЗ программисту, а не программист заказчику.

Кто написал, что программист заказчику пишет ТЗ?
ТЗ пишет технолог-аналитик, запомните это раз и навсегда!
Он же пишет "ТЗ" для договора с внешним заказчиком, только уже на родном языке заказчика, он же участвовал в переговорах с заказчиком.

Я не беру в расчет шаражкины конторы, в которых принято производить софт "как бог пошлёт". Такие организации есть в любой индустрии, в семье не без урода. Да, такой софт может работать. Да, бывает он даже работает как надо и пожизненно до потери актуальности. Но увы, процент брака (лишнее откидывание на предыдущий этап при тестировании, уход с бета теста на доработку, баги в процессе рабочей эксплуатации) по таким разработкам выше в разы. Так в основном free-to-play игры разрабатывают из-за урезанного штата, коробочки с багами.

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

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