Research&Development Engineering Management

Biography has not been added


's contributions
    • I agree that short names are okay. But make sure the abbreviations are spelled out where their declarations are defined or some other convenient and maintained database.

    • Jack, interesting how almost all of the comments are anecdotal about their past schooling experience. But I going to buck the trend. The truth as I see it is that you can only pack in so much learning in four years of school. People you solve cookbook problems come a dime a dozen, people who solve new problems are worth their weight in gold. People who solve new problems do it because they know the theory behind the operation. That is why theory is taught first and foremost. So you go to college to learn theory, then in real life you apply it and pick up some practical skills along the way.

    • Your article has three bullets: (1) unambiguous (2) binding, (3)testable. I will assert that after my 18 years DOA-178 experience that it is impossible to express in words a requirment meeting criteria (1) and (3). I can and have taken textually worded requirements to several different engineers for their interpretaton. No two engineers will interpret any typically complex requirement the same. Textually worded requirements are the worst possible way to express complex time-dependent, logically intricate, mathematically involved requirements. We must learn to abandon textually expessed requiremets. They were borne in the legacy era of the 60's and 70's when there was no other choice (I was there). Instead, requirements should be expressed as logic diagrams (e.g. MathWorks/Simulink) or in terms of a formally provable logic language. We would have done this in the beginning if computers and software apps would have been available. The FAA, the auto, and the medical device certification authorities need to learn to develop a requirement mechanism which is free from interpretation and release the hapless engineer from the subjective interpretation of the certification oversight individual. You only need to ask one question, is DO-178C written at the same level of rigor that it purports to enforce?

    • The author made an excellent well thought out example. But unless there is some further discussion that had been left out (since this was an excerpt), the predictive aspect of applying the scientific method is not shown. This is truly the hard part of the probem. The root cause in this example is very restricted to this particular code example and I could see not a means to formulate a broader programming principle that would avoid it happening again in a different code application.

    • For us oldtimers, I can remember when long resumes were the standard. In those days, HR did not filter resumes, instead they were passed through directy to the hiring manager. Not until the 80s did the 1 page resume come into vogue when HR took over and started filtering.

    • Unfortunately, I would probably have to wait until 2030 before the FAA decides to evolve from their current 1970's software paradigm.

    • Having read about 30 or more of the comments, they obviously run the gamut. I have heard all the arguments this way and that way. DOxygen is okay but just not enough. Editors/IDEs which preprocess to remove rich text are just not enough. I am definitely with Jack all the way. I want a compiler that can take in rich text word processing like documents. I want my code and documentation integrated.

    • The fact that consultants are paid by the either defendant or plaintiff should make the jury very wary of their testimony, at least if it were me on the jury. But engineers (or any college graduate) are rarely chosen for jury duty.

    • In the DO-178 world, #ifdef macros are not considered dead code. Since the the code is not compiled it is meaningless to consider the question "will not be executed" which presumes some non-zero probability of being executed.

    • Another language extension should be created to specify bit packing as in bit assigning lsb to msb or vica versa. Historically, all of these extensions were motivated by hardware architectural differences. Are new extensions needed for multicore?

    • Precisely, the open, close, read, write are meaningful methods for the derived classes of serial port and LCD. But if someone were to use the interface for an input only discrete interface, they would be misusing the interface.

    • My comment has nothing to do with mechanics of pure virtual functions. I just want to get my two cent opinion in so other developers are aware. IMHO, the use of pure virtual functions to define a method which has no meaningufl implementation in a subclass is a red flag that your design is wrong. The base shape class should have been designed based on geometry, ie, number of sides, number of dimensions, closed or open. That way your inheritance tree won't and doesn't need pure virtual methods.

    • I would agree with CDHM. Any software development project prior to the 90s should be discounted. We just didn't have the tools and experience we have now at our disposal. In regards to higher levels of CMMI reducing cost and schedule, one must be extremely careful whether we are distinguishing between development projcts run from scratch versus incremental enhancements to existing projects. The latter will bias the results to make CMMI look good to productivity.

    • The people who write the standards actually perform their writing at CMMI level 1 and DO-178B/C level D. In other words, to write the standard they simply begin writing. They have no theoretical basis that the document they write will meet the requirements or design goal intended, i.e., their work is based on intuition. They have no stated requirements nor tests to satisfy. Yet at the same time, they are telling others they must be rigorous!

    • Level 4: "the fundamental practices of software performance engineering". Okay, we generally know what you mean because they are implied by your descriptions of levels 1, 2, & 3. But they are only implied, thus leaving the interpretation up to whomever wields the signature authority. You need to explicitly define these standards such that there is no room for personal interpretation. Do not allow the ambiguity of existing CMMI, DO-178, and similar genre to propagate into your standard. These standards do not pass the test of there own professed standard of rigor.

    • Nice ideal but nowhere does it state how much more effort level 2 takes than level 1, level 3 vs level 2. Without this assesment, a customer is implicitly free to impose any level without regard to schedule or cost cnsideration. Thus the customer make any changes they want to project requirements and still demand the same schedule thus forcing the contractor to absorb the cost and effort.

    • The fundamental weakness of CMMI and all such genre industry standards is that they place no constraint on the prime contractor/customer. The prime does not have to follow CMMI themselves. They are therefore at total liberty to change requirements without penalty to their schedule and yet ask the subcontractor to perform CMMI level 3 or better as if there is no extra effort. CMMI does not state how much increase in effort a level 3 takes over level2 when in fact there is a substantial amount of work effort. The quality and schedule problems start with the prime, not the subcontractor underperforming.

    • The ambiguity of C/C99 is the principal reason why any sane coding standard prohibits c = a++ + b++; enough said.

    • Yes, when I attended ESC I went to classes where there was something new to be learned, not where I already knew it.

    • Logic is logic and is a conceptualization that transcends whatever language paradigm one chooses to use. So to say that the success of the project depends upon the choice of programming language is an oxymoron.

    • Okay Michael, now what about documentation guidelines for include files. I vote zero. Documentation in .h files is a legacy concept based upon the dissemination of the interface to other parties. I prefer all documentation in the .c file. Keep it where you need it. You don't need it in .h files, you can always write a script to extract documentation from the .c file. Engineers picking up someone else's code, don't want to open two files and have to hop back and forth.

    • For writing software based upon requirements, the English language (for that matter, any conventional language) is the worst possible means for writing requirements. The English language was never designed to express precision, exhaustic logic, or sequential timing related requirements. I can write a requirement and have 5 engineers interpret it in 5 differing ways (extreme but you get the point). We need a language specifically designed to be expressive for precision, logic, and sequential timing. I like using Simulink models to express requirements. A model is logically complete, there are no loose ends. All if-then-elses are completely specified. I honestly believe that writing requirements in C, C++, Java, Ada, etc. is better than the English language. Heretical, I know and it is sure hard trying to convince the traditionalist.

    • Sorry Jack, but it is not because of our poor requirement gathering, but rather, the customer really does change requirements. It is the customer's poor requirements gathering that are the cause. My second point is this, written language is ill suited to stating requirements. The proper way to state a mathematical, logic, or engineering related algorithm is to use a logic diagram, eg, Simulink, SciLab. We should view logic diagrams as a language in their own right. After all, it was scientists and engineers who invented logic diagrams and the motivation was to express their ideas in a more precise form than written language ever could.

    • When my place of business brings in junior and senior high school students, I am usually asked to speak to them. I tell them that engineering is very good field to get into. It is rewarding, challenging, and you can see the fruits of your labor. I also firmly believe that the US is shooting itself in the foot by the current off shoring of engineering labor. I believe the US people (who elect the government) will realize this in the next generation such that those who are engineering will be in high demand and become as well respected as they were in the post war years of WW II.

    • Just why is there so much offshore engineering? With age comes salary. It is a no-brainer. So is it illegal to discriminate based on salary?