Mastering Embedded Systems

Right before my holiday I have made a bad experience. Some meetings with a vendor have gone sub-optimal to say the least.

However it was a good opportunity to observe what could be done much more better when talking with vendors for technical problems. I have run a lot of such talks and I wanted to take this bad situation as trigger to collect my 5 hacks to get the most out of vendor discussions.

You should listen to this episode if you will sooner or later found yourself confronted with your boss’ request: “Hey man, let’s discuss with vendor #XYZ. They should support us here.” And with “let us” he of course means you. Or you’ve already talked with your vendor (or vendors) and you again and again observe some counterproductive situations, but you do not exactly know how to improve them.

This episode enhances you to finish vendor discussions better as average. Or if you’re the vendor, you know exactly whether your customer is well prepared and honest with you in his request for explicit support.

Stay with me and enjoy the chat.

After the last episodes about requirements engineering you might have thought: “What about the real thing? How will such a tool for requirements engineering look like? What’s in for me? And how can I get in touch with it?”

Right after episode 38 I got a message by Trevor Bradley from QRAcorp. Trevor wrote: “I really enjoyed your last podcast about Requirements! The episode was very relevant, as I’m with a research group in Canada creating tools for requirements engineering We just released our first beta tool called QVscribe.

You think that’s interesting? So did I! Today I have the pleasure to welcome the CEO of QRA-corp Jordan Kyriakidis and the marketing director Trevor Bradley. Moreover there is again Joachim Reinke with us.

You should listen to this episode if you’re considering to use a tool for requirements engineering. Of if you’re already in the selection or testing phase for a new tool. Or you’re part of this big group managing requirements with Microsoft Word and you wanted to improve your working process.

This episode supports a dedicated look into a distinct tool for requirements engineering. You receive insights how this tool was planned and what are the details behind of it. But you also get worthwhile ideas and thoughts about requirements in general. And in particular there is the new angle QRAcorp uses Natural Language Processing to actually analyze what makes a requirement unambiguous and high quality.

And last not least QRAcorp offers their tool for free during the beta-phase. If you’re interested to test a tool for your requirements engineering, you wanted to dive deeper into tools support or you’re simply curious what this is all about – do not hesitate and visit QRA-corps website and get your free account.

Stay with me and enjoy the chat.

In episode #38 I have already had the pleasure to welcome Joachim Reinke. Joachim is an expert in requirements engineering. In episode 38 he explained the reasons why we definitely need requirements engineering.

And today I’m happy that we managed to continue our talk. We’re discussing the big pain points in Requirements Engineering. And how it is possible to relief this pain. But we also needed to back up a little bit to grab the bigger picture.

First we identified the main points in Requirements Engineering. In a second step we jumped into the details how to select an appropriate tool to support you in maintaining requirements. It’s not that easy to find the right tool. Because there a several aspects you need to consider. For example you will regularly not establish such a tool on the greenfield. There will be environmental conditions, limitations and constraints which might bother you.And here Joachim’s list of 9 important bullets for selecting an RE-tool will become very helpful.

Stay with me and enjoy the chat.

And here we are with the third and last part of how to survive Death March Projects. In episode #37 we have talked about how to define and detect Death March projects. And about your decision whether to leave or stay.

In episode #39 we have tackled the kind of actions you will face if you want to bring such a project to a good end. We have talked about politics and negotiations. About rational negotiations and negotiation games you should know. And how to identify accetable trade-offs or what to do if all negotiations fail.

Episode #40 was about people. How to hire for Death March projects. How to achieve loyalty, commitment and accountability. And the major aspects of communication and team-building.

Finally in this episode I’ll present you some very important processes you should know if you find yourself in a Death March project. And I wanted to highlight tools and technologies which might become handsome for the success of your Death March project, too.

Stay tuned and be inspired.

In the last episode I have mentioned how important negotiations become in maintaining a Death March project. Today we’re focussing on another aspect: How to gather the right people in your project?

Especially in Death March projects your surrounding team mates might become the only persons you see for a very long time. Insist on having the right persons in your team. Expect overtime hours, but remember always that you’ve a long way to go. And at the very end you should have enough power to sprint for the last 100 meters.

Taking care for people is an essential part to be successful in running projects. For Death March projects however it is an absolute must to do it. Besides all technical knowledge, besides all negotiations, you need to have loyal, cohesive, and cooperative team with you.

In this episode I will highlight some essentials when working with people in critical projects.

Stay tuned and be inspired.

Hopefully you guys remember Episode 37 Hopefully you guys remember episode 37. We talked about Death March projects. How to identify them. What their characteristics are. The reasons they happen. And about your decision to stay for them.

Today’s episode emphasizes the four major aspects how to survive a Death March project. In this context surviving more means to stay psychologically unharmed than physically shattered. Regularly these four aspects appear in certain combinations. That’s the reason you need to know all four of them to get the whole picture.

Today I will present you the first of these aspects. We’re talking about negotiations in Death March projects. There are not only rational negotiations – the one you might know from your daily life. But there are also negotiation games and special trade-offs to put your free. In a first I will give you some additional support to make your decision whether to stay or leave a Death March project at all.

Stay tuned and be inspired.

Joachim is an elaborated specialist for such kind of hassle. He is an engineer who specialized in the area of Requirements Engineering. He’s a crack in this area of the development and production process. We both got acquainted at the systems camp 2016 in Berlin.

Requirements engineering refers to defining, documenting and maintaining requirements to the sub-fields of systems engineering and software engineering. But the major question is – why does it seem that neglected in real development life. We’re discussing a lot about these aspects. The benefits you get out of well done requirements engineering are tremendous.

Stay with me and enjoy the chat.

Everybody of us has some kind of understanding the term “Death March”. It’s from the military indicating a task you have a good chance to not stay alive. And the same could be, if you take projects in civil life in which the project members are working 13-14 hours each day, 6-7 days per week, for months. There is a good chance to lose people. But there’s also a good chance to fail the project itself.

I wanted to explain how exactly a “Death March” project looks like. How you can identify it. And what general decision you have to make if you face a Death March project.

Due to the bare amount of information I have to split this topic into two episodes. In the second one you will finally get a general guidance how to tackle “Death March” projects.

Stay tuned and be inspired.

Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note.

Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally!

[saf feature="itunes" cta="iTunes rating"][saf feature="stitcher" cta="Stitcher feedback"]

Lastly, please do not forget to subscribe to the podcast on iTunes or stitcher. A shortcut is available on the right side. You will get your updates automatically every time a new episode goes live!

[saf feature="email" cta="Send me feedback"][saf feature="twitter" cta="Reply on Twitter"]

You know such kind of story – everybody is talking about security, but not really everybody knows what it effectively means. Especially security in Embedded Systems has become a valid topic in the last years. My today’s guest has an intimate knowledge about all kind of aspects of security for Embedded Devices. I wanted to welcome Andrey Nikishin from Kaspersky Labs.

Many of you will remember Kaspersky Labs as one of the main competitors in providing anti-virus software. However they have become much more. Andrey describes himself as evangelist of new technologies and new business directions. As an expert for cyber security he is working very closely with Kaspersky OS – an operating system designed for security from scratch.

I got in touch with Andrey at the Embedded World in Nuremberg. I’ve seen their booth and initially thought: “What does the manufacturer of anti-virus software do at such exhibition?” I was so wrong! The threats towards security and integrity of embedded devices has grown heavily over the last decade. But that’s only one aspect. The other side of the medal are the ubiquitously available small embedded devices connected via the Internet. The bare amount of embedded systems in all parts of our life has dramatically increased during the last years. And they will still grow for the next decades.

Andrey thankfully provided me some documents and white-papers about the mentioned topics. Have a look at them in the links-section below.

Stay with me and enjoy the chat.

Summer has arrived in Germany and this is the best time to talk about Mind-Maps. Wait a minute. What do these two events have in common? Right! Nothing! But I needed a connection – and that’s what Mind-Maps will do for you – connect things. In this episode I will concentrate on using Mind-Maps for taking meeting minutes.

Taking minutes can be some real awkward story. But using Mind-Maps it gets more natural, more fluent, and more precise. But, doing it that way, I detected during running consecutive task-force meetings, that the Mind-Map approach is not that stringent. It needed some tweaks to get its real harmony and fluency. And this episode is about the five major tricks I have found during the last months when using Mind-Maps for taking meeting minutes.

In the very first part of the episode I provide you a short survey about the available Mind-Mapping software. It’s of course not complete, however will give you a very first step into the topic. In the links-section below you’ll find all the mentioned applications and programs.

If you do not have time to listen to the episode, then at least take my tweaks to use Mind-Maps for meeting minutes with you:

For all the other ones, take your time and listen to more details and examples to enhance your usage of Mind-Maps.

Stay tuned and be inspired.