Tools and Teams

I recently saw a post on Twitter from the Great John Cutler on allow the team to pick the tools that they use to do the work.  Generally, this is not a bad idea, but not necessarily a great idea either.  It sort of depends.



My experience in companies that also have hardware parts associated with the software, each group selecting their tools comes at a great disadvantage when it comes to understanding the various work products as it moves through the organization.  It is not possible for one team to see what the other team has done, when the tools are not connected, or each group selects what that individual group needs without consideration of the departments that are depending or associated with the work.  In these cases, a product life cycle management tool that connects the various work departments and work packages can help tie all of these together. Consider a vehicle manufacturer that develops … Continue reading

Missing Requirements

Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  In … Continue reading

Testing – End-To-End

There have been some twitter discussions going on about the validity of the term end-to-end (E2E) testing. I have been around this concept for many years and still see the validity in the term and the approach. To that end, I will describe as quick and briefly as I can since this is a blog post and not a book.

The various devices being developed (Device Under Test)

Vehicles are comprised of a myriad of subsystems. In this case we are going to look at the vehicle electrical / electronic architecture that consists of embedded electronic control units (ECU). These are component such as:

Instrument cluster Engine ECU Transmission ECU Antilocking Brakes System (ECU) Door control modules Telemetry systems

Each of these consists of many analog and digital inputs and outputs, along with data link communications. Each have specific expectations under certain conditions and the developers will work to deliver these algorithms and software that will ensure the system works … Continue reading

Requirements, Benchmarking and Teardowns

Requirements and Benchmarking

One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have met the specific challenge, or more importantly, how we can develop the product in an even better way.   Benchmarking can provide us with performance metrics for the product.  Knowing this, we can establish the performance expectations from our product which will show up in the requirements for the product.

Requirements and Teardowns

Teardowns are also useful when it comes to requirements generation.  We can learn what drives the cost in at least one incarnation of the product, which is how the competition has chosen to meet the customer demand.  We then are able to gain some measure of understanding of at least one possible incarnation … Continue reading

Assumptions and Models in Product Development

We have recently posted how assumptions, left unquestioned can damage a project. It is similarly true for the product when we use models and simulation to generate our product.  In the course of building these models, we will know some things for certain.  Some attributes of the model we may think we know for certain but may in fact not be valid.

That is why we couple testing with our simulation and models. We will confirm those things we believe to be true and the many things we hope to be true, and probably uncover things we did not even consider to be true through testing.  Those attributes that are connected to the desired outcome, we must understand so we can accurately predict the outcome.  Below find a graphic that shows the process for building and understanding the model[1]:



Assumptions are deadly when it comes to models.  If we believe our simulations and the many assumptions … Continue reading

Deviations versus Change Requests

The deviation does not originate from the supplier. The change to requirements is permanent. Continue reading

Material Handling Via Robotics Company

Material handling via robotics can Help you streamline your organization and optimize your Talent – @journik


Testing Need Not Be Elaborate and Sophisticated

The olden days…

A long time ago (seemingly) I graduated from university with my engineering degree.  I was lucky, my first job was with a small company and I performed many roles as it applied to developing their new product line.  The product was an embedded strand process control unit. This unit would control older electromechanical systems that were used in the managing of fibers like Kevlar, fiber optics, fiberglass, sutures and Lycra.  I set about understanding the requirements and designing the embedded system.  I picked the Intel 8051 controller, designed the reset circuitry, oscillator circuitry, and external memory, input / output  addressing mechanisms.  I had drawn the design up and a technician wire wrapped the first prototype part (that should give you an idea of how old I may be).

Development Testing

While the technician wire wrapped the prototype, I set about with my simulator to develop the first parts of the software.  Eventually I received the prototype part … Continue reading

Simulation and Models in Product Development

Models are not new, and neither models in the employ of product development. Product development has always had some basis in discovery and always will. If everything had such a high degree of certainty, likely the product or endeavor has already been done. Developing new things ceaselessly brings questions. To be effective, we want to answer these questions as quickly and as certainly as possible. Continue reading

APQP and International Material Data System

By Wally Stegall and Jon M Quigley

Collecting and Reporting Material

One approach to collecting and reporting material content is the International Material Data System (IMDS).  IMDS is a computer-based material data system used and funded primarily by automotive OEM’s (Original Equipment Manufacturer of cars, trucks, heavy vehicles, agricultural equipment, construction equipment, industrial equipment, military vehicles, and other apparatus) although other manufacturers use IMDS to manage environmental care aspects of products.

“The IMDS (International Material Data System) is the automobile industry’s material data system. Initially, it was a joint development of Audi, BMW, Daimler, HP, Ford, Opel, Porsche, VW and Volvo. Further manufacturers have meanwhile joined the community and IMDS has become a global standard used by almost all of the global OEMs. Talks are being held with further manufacturers regarding their participation in IMDS. In IMDS, all materials used for automobile manufacturing are collected, maintained, analyzed and archived. Using the IMDS, it is possible to meet the … Continue reading

Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO