Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 2   >   >>
Bob Lacovara
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
Bob Lacovara   12/13/2010 2:48:54 PM
NO RATINGS
Agreed, Mr.Acharya, the com style depends on the organization. The bridge document between hardware and software for the Command and Control Processor on the "International" Space Station was written in PowerPoint. In a series of about 20 such documents, the chief engineer described how he expected the hardware and software to interact, subsystem by subsystem. We followed the document, and when questions arose, we could just ask for clarification. It worked. And it didn't involve mediation by the system engineering clergy, or $60K/seat "requirements" CAD tools.

Sanjib.A
User Rank
CEO
re: Software is from Mars, hardware is from Pluto
Sanjib.A   12/12/2010 12:12:03 PM
NO RATINGS
Another lesson learned (or addendum to #2 in the document) could be a well set-up communication process between the hardware and the software team. The communication style mostly depends on the organizational structure and in this case since the hardware & software teams do not share the same reporting authority, setting-up an inter-team communication process is essential. A hardware-software integration requirement document or something like that generated by the software team and then reviewed and approved by hardware team would have been helpful in catching the miss-outs.

Robert.Reavis
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
Robert.Reavis   11/26/2010 6:49:51 PM
NO RATINGS
My career centered around automatic test equipment for twenty years, one foot in hardware and one foot in software. I once asked a question in a meeting and heard a yes and no at the same time. I told them that it did not matter what the answer was, but that both of them had to say the same thing. He said, she said, and then I said. Regarding an unplugged device not giving any errors, even worse is when unplugging something causes a crash of the whold system and you are unable to report an unplugged device condition.

WKetel
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
WKetel   11/25/2010 2:33:46 AM
NO RATINGS
The reason for the divide between software and hardware is that the two are so very different. Those who are able to write good code based on a set of complete requirements have a quite different skill set from a design engineer who knows how much power each section of the circuit must deliver, and how much it will consume, and what signals must be protected from other signals. IN short, there are two completely different skill sets, and the few folks who are in possession of both are quite valuable, and therefore probably quite expensive, if they are any good. The higher price assures that many managers will seek to avoid having many with both skill sets around.

rpcy
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
rpcy   9/1/2010 6:03:43 PM
NO RATINGS
There's another lesson here. If your design has a means for detecting errors, then your design must also provide a means for generating those errors, so that you can tell if your detection scheme is working. It's amazing how few designers get this right, until after they've shipped a system that did not. (I'm not one of the few; I had to learn this the hard way.)

Bob Lacovara
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
Bob Lacovara   9/1/2010 2:23:16 PM
NO RATINGS
Even if you have decent requirements, there are other pitfalls. I worked for MITRE once upon a time, and was hired by NASA to review a contract for a very large software configuration management system. The aeorspace contractor wanted to build it themselves for $50K. We thought this was just the usual loss leader... I found out that one of the commercial CM systems had 250K lines of code: no one was going to duplicate that for $50K. Needless to say, with that little bit of research my popularity was rising on one side of the fence, falling on the other. Next, the contractor had a meeting with NASA with me present to explain just how wonderful their extras were going to be. After about the third time the contractor explained "we don't have that in the requirements" in response to a NASA question, the woman in charge for NASA leaned over to the contractor's requirements manual. She flipped about 4 or 5 pages, and announced: you only have the odd pages of the requirements document. It was hilarious... although I managed to keep a straight face. Make sure that you have decent requirements, and while you are copying them, do it both sides...

lifewingmate
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
lifewingmate   8/31/2010 6:41:45 AM
NO RATINGS
As daunting as this scenario may seem, I believe it is all too common in the hardware and IC design sphere. I am interested to hear what method was used during development? Instead of head down mode, I want to add another tip...which is to follow Agile development methods and for a program manager and project manager to require daily scrum meetings so that hardware and software work together to make decisions about what and how requirements can be met within the project scope. In addition, real-time communication should happen when both hardware and software teams analyze the requirements document. The marketing team should also be alerted about the outcomes of these team analyses to ensure clear communication on all fronts. Prototyping and modeling should also be evaluated. There should be multiple safeguards to this process (not Waterfall) to ensure that the team's excellent efforts are not wasted or held back because of either poor decisions or miscommunication.

Robotics Developer
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
Robotics Developer   8/30/2010 5:42:51 PM
NO RATINGS
I have witnessed the hardware / software divide my self over many years as a EE. I can't help but think part of the separation arises from there being both a hardware development group and a software development group as separate structures in most companies. This just reinforces the lines of separation. Perhaps, it would be best to develop products with an integrated team from the beginning as this would reinforce the team approach. I am also wondering why there was a “loss of optical signal” hardware alarm bit designed in if it was not in the requirements document for the product?

SkyhighSG
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
SkyhighSG   8/29/2010 11:05:11 AM
NO RATINGS
Strange this still happens today. It depends how the engineering team is composed and managed. Usually there is an embedded team engineer/manager who can manage software and hardware, or bridges both domains. A department without an embedded expert usually runs into problems. In fact, more companies today start to cut on pure software guys, and shift more effort on embedded (cos these are the best guys who can do RF, analog, digital, MCU and practically like a multi-purpose commandos)

jimcondon
User Rank
Rookie
re: Software is from Mars, hardware is from Pluto
jimcondon   8/29/2010 2:24:50 AM
NO RATINGS
I find it a little funny the hardware engineer calling out that the software engineer may not read a page in the functional specification, but never calls himself out for not reviewing the software requirements specification. By doing this, he could have discovered the oversight early and pushed for his feature to be covered. I also find the us vs. them tone of the whole article disconcerting. It's not hardware vs. software, it's a team putting together a product. By watching each others backs in a team effort, issues will be found earlier and fixed faster.

Page 1 / 2   >   >>


EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Aging Brass: Cow Poop vs. Horse Doo-Doo
Max Maxfield
40 comments
As you may recall, one of the things I want to do with the brass panels I'm using in my Inamorata Prognostication Engine is to make them look really old. Since everything is being mounted ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
11 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
11 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
45 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)