Jump to content

    

Книги по управлению проектами разработки РЭА

Порекомендуйте книги, наилучшим образом подходящие для специфики отрасли.

Можно и на английском.

Share this post


Link to post
Share on other sites

Нифига не теоретическая книга и не учебник. Акио Морита "Сделано в Японии". Воспоминания одного из основателей фирмы Sony

Share this post


Link to post
Share on other sites
2 hours ago, V_G said:

Нифига не теоретическая книга и не учебник. Акио Морита "Сделано в Японии". Воспоминания одного из основателей фирмы Sony

Слащавая книга ничего не объясняющая, без описаий коллизий, нахождения решений и выходов, и пр. Чтобы все поцокали языком - как все было славно и хорошо.

Пожалел, что потратил время на ее прочтение.

Share this post


Link to post
Share on other sites

Западный опыт в области организации разработки и производства опытных образцов к России применим лишь частично.

Основная наша особенность, адская логистика внутри страны. Из Москвы в заграницу грузы улетают нормально, а по России адский ад.

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

Другая наша особенность, отсутствие свободных кадров в областях, требующих высокой квалификации.

Это не говорит о том, что специалистов нет. Специалисты есть, но при высоком статусе своей должности не поедут и на в 2 раза большую з/п на позицию рядового инженера.

Share this post


Link to post
Share on other sites
23 minutes ago, baumanets said:

придётся держать больший складской запас компонентов.

Какая связь между складом и разработкой? 

РЭА слишком большая область.
Лучше сузить охват. Вот например как делать встраиваемые системы -   Jack Ganssle , The Art of Designing Embedded Systems.

Share this post


Link to post
Share on other sites

Согласен со вторым абзацем AlexandrY.

Автору темы могу посоветовать книгу "Мифический человеко-месяц". Ф.Брукс

Share this post


Link to post
Share on other sites
On 6/2/2019 at 3:30 PM, Juzujka said:

Порекомендуйте книги, наилучшим образом подходящие для специфики отрасли.

а чем писание встраиваемого кода (HDL / рисование топологии / и прочая CAD ориентированная деятельность) отличается от писания программ?

по-моему, этим и имеет смысл заниматься, по крайней мере, для таких занятий имеет смысл читать подобные книги.

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

Share this post


Link to post
Share on other sites
3 hours ago, baumanets said:

Автору темы могу посоветовать книгу "Мифический человеко-месяц". Ф.Брукс

Великолепная книга, немного устарела, да и направленность на программные системы.

Как говорил Королев - "Когда у меня было 7 работников, я знал, кто, что, и как делает. Когда 70 - знал только что и как. Когда 700 -знал только что делают".

И это только одна из проблем.

 

Share this post


Link to post
Share on other sites

Я бы добавил ещё одну книгу:

Том Демарко Тимоти Листер Человеческий фактор: успешные проекты и команды

Share this post


Link to post
Share on other sites

Спасибо!

А книги

Управление проектами. Клиффорд

Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд

Кто-нибудь читал?

Насколько это применимо к реальной жизни?

( и написания курсовой работы )

Share this post


Link to post
Share on other sites
On 6/3/2019 at 11:57 AM, AlexandrY said:

Какая связь между складом и разработкой? 

РЭА слишком большая область.
Лучше сузить охват. Вот например как делать встраиваемые системы -   Jack Ganssle , The Art of Designing Embedded Systems.

Начал читать. Прям с первых строк в точку и любителям RTOS.. KLOC - kilo lines of code.
 

Quote

 

One way to keep productivity levels high—at, say, the 20-KLOC/program number—is to break the program up into a number of discrete entities, each no more than 20 KLOC long. Encapsulate each piece of the program into its own processor. 

That ’ s right: add CPUs merely for the sake of accelerating the schedule and reducing engineering costs.

Sadly, most 21st century embedded systems look an awful lot like mainframe computers of yore. A single CPU manages a disparate array of sensors, switches, communications links, PWMs, and more. Dozens of tasks handle many sorts of mostly unrelated activities. A hundred thousand lines of code all linked into a single executable enslaves dozens of programmers all making changes throughout a byzantine structure no one completely comprehends. Of course development slows to a crawl.

Transistors are cheap. Developers expensive.

Break the system into small parts, allocate one partition per CPU, and then use a small team to build each subsystem. Minimize interactions and communications between components and between the engineers.

Suppose the monolithic, single-CPU version of the product requires 100 K lines of code. The COCOMO calculation gives a 1403–man-month development schedule. Segment the same project into four processors, assuming one has 50 KLOC and the others 20 KLOC each. Communications overhead requires a bit more code so we ’ ve added 10% to the 100-KLOC base fi gure. The schedule collapses to 909 man-months, or 65% of that required by the monolithic version.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now