The Ideal Testing Mindset

I was working with a company a while back when one of the execs asked about softening test results so they didn't sound so bad. It made me realize that this exec, who was fantastic at marketing and selling, didn't fully understand the point of testing.

We get used to presenting things in the best light possible without lying, but with testing that mindset is counter-productive. Not that you want to blow anything out of proportion, but it’s important to be objective about testing.

First, how bad is this defect? This is where defined severity criteria work well – is data lost or corrupt? is the user unable to perform a critical function? is there a workaround? – all important questions when objectively evaluating defect severity.

Second, if there are areas that may not work as designed, wouldn’t you want to find out before your product gets into a customer’s hands? Yes it may take some work to fix it, but it’s going to need to be fixed either way. It’s better for your reputation and bottom line to fix it sooner rather than later.

Finally, it’s okay to have bugs early on in the software development process. That’s why we test. It is not a reflection on your product, it’s just part of the process. Just like all of us humans are flawed, so is our software. Fortunately (or maybe unfortunately) it’s much easier to fix our software bugs!

-Judi

Planning Your Next Embedded System

Since my philosophy on product development is so closely aligned with requirements definition, I don’t know how you can begin a new product development without creating a team first.

The team should not be composed of only technical contributors, but also domain experts (internal or external), stakeholders from various company departments, and finally the user community.

Once the team is assembled, you can begin to define product offerings, value, cost, etc. With timely marketing input up-front, coupled with manufacturing and service personnel voicing their inputs from the beginning, you can see a product concept emerge.

My advice is to keep the team involved all the way through development and deployment gaining feedback as you go.

So if it’s a question of technology or team, I always choose team first. What do you say?

-Gary

Smartphones and Service Technicians

Smartphones will soon replace laptops as the primary tool for service technicians.

Companies are realizing that laptops are expensive to maintain in the field, and no longer present a clear-cut alternative to a smartphone. In addition, many service personnel already have a smartphone with them at all times for communication needs.

Advances in core technologies have made smartphones quite capable for the diagnostic tests and troubleshooting of field service personnel. And new smartphones will still support legacy systems via USB adapters just as laptops do.

The main thing lacking is apps that integrate information for service technicians, which is no easy feat. The apps must be smart and collect data from various sources, including diagnostic test information, part procurement, customer and warranty information, and incident and problem reports to name a few. It is this total integration in a simple package that will be a game changer.

Please share with me your experience with moving your service personnel to a mobile platform.

-Gary

Process vs. People

Can a solid process support an inferior team? Yes.

Can a capable team overcome an insufficient (or inappropriate) process? Yes.

So which situation is more likely to be successful? In my opinion, it's the team every time. People trump everything.

Even though a good process makes a good team even more productive, a small team of high performers can do amazing things. The key here being a “small” team. Once you get past a certain size--I’d say 4 - 6--even the brightest superstars can become bogged down by poor communications and an inefficient working environment.

So if I had to pick, I’d pick the people. But of course, both is nice.

-Judi

Embedded System User-Interface Tips

I have often written about the need for requirements definition at the beginning of any embedded system design. However, I believe user-interface (UI) requirements are in a class by themselves, and thus deserve special attention.

During the conceptualization of the user experience I recommend focusing more on identifying user roles, workflow and informational content than on detailed screen design. Far too often I see a lot of effort devoted to specific graphics, color, font and button alignment before basic questions are even asked. I suggest starting with a representative selection of the embedded system's user community and the development team to address the following types of questions:

-Who are the target user(s)?
-What are their roles?
-What specific information is critical and actionable to each role?
-What information is simply helpful?
-What data is nice to have but does not need to be normally displayed?

Once the above questions are answered then the development team should rapidly create multiple versions of simple user interface experiences for the user community to evaluate. (Sometimes it may take the physical form of a software simulation when it is impractical to develop on the target hardware.)

User feedback gained from interacting with examples of possible user interface screens can provide invaluable feedback that will focus the development team on a specific implementation path. Once the path is set, then it is time to choose the right icons, fonts and colors.

Please share your tips for really good UI design.

-Gary

Questions That Provoke Innovation

One of my LinkedIn contacts posted an interesting article about innovation recently. It got me thinking about how this might be used in process improvement.

While there are well known practices to address many of the common issues with poor quality software development, sometimes there are challenges implementing them in specific environments. For example, while it is ideal to develop tests and test products as they’re being built, sometimes we find that doesn’t happen and testing needs to be done after the fact.

Sure, you could just start writing all the test cases from the requirements docs, but that’s a long road. And what if there are no requirement documents? The product still needs to be tested, and in a reasonable timeframe with a reasonable set of resources.

Asking “How might we…” can unlock all sorts of creative options.  One company I work with is using Google Voice accounts to fill in as “people” when testing their software. Sure they don’t all respond, but it’s a great start to put a little more load on the system.

How might you come up with a solution for some of your more intractable problems?

-Judi

Doodle -- A Cool Application

Every so often a web-based application really catches my attention. This time it is Doodle, a simple and innovative scheduling application. It is ideally suited for coordinating a meeting or event when more than just a couple of people are involved. No more back and forth emails due to Doodle's voting mechanism. Very cool.

I often wonder what makes a particular application so attractive while similar ones are not. Of course there is no easy answer and it is very subjective.

For me the application needs to:

-Do one thing and do it well
-Be easy to use
-Be accessible from anywhere at any time
-Be offered at a "reasonable price" (not necessarily free)
Companies often cast a wide net when designing new products. The thinking is to add as many features as possible to make the product desirable to a large audience. But I prefer to narrow the focus and go deep in implementing the core functionality. I believe if you focus on end user interaction and then make the product easy to use you will have a winner.

Please share your favorite application with me.

-Gary

October Is Manufacturing Month

Here in Connecticut, October has been designated as Manufacturing Month. And since Advanced Decisions helps companies develop new products, many of our clients are manufacturers, giving me the opportunity to observe many of their operations firsthand.

And don't be fooled--manufacturing is not the dirty, dark and dangerous industry that it used to be. It's very high tech.

Manufacturing supports the economy in ways that other fields can't come near. Did you know that for every manufacturing job created, an average of 2.91 jobs in other sectors are created?

So during October, take a moment to learn more about 21st century manufacturing. It provides great jobs, with great pay, that require skilled workers. Groups like CONNSTEP, CBIA and NHMA are all sources of information that provide various programs to educate the general public about modern manufacturing.

-Judi

Are Code Reviews Still In Vogue?

I have seen a significant drop off of companies conducting code reviews, which is unsettling because code reviews are still extremely valuable.

The code review process is challenging, and real-time embedded systems have the additional challenge of software and hardware interfaces. That is why I recommend adding a hardware designer to participate in the code review. It can really help to solve problems quickly that may arise during the review.

I have heard Management's reasons to forgo code reviews:
1. It ties up precious resources
2. Not sure how to conduct one properly
3. Might upset a few of our developers
4. The meeting becomes an excuse to attack someone
5. Not on the schedule

But I feel that in spite of all the trouble it may entail,  the goal of creating high-quality, sustainable, maintainable code in a timely manner is well worth the effort. I have found design reviews and code reviews to be invaluable tools to improve the actual quality of the software, stimulate growth, enforce coding standards and find bugs early.

In my experience, having led code reviews and having been a member of peer teams reviewing code, I always felt that it was a positive learning experience. Oftentimes simply asking the developer basic questions and allowing them to explain their thinking leads to amazing results.

Are you using code reviews as an integral part of your embedded development experience? What challenges are you having?

-Gary

Changing to a New Embedded Development Platform

I imagine that for you, as for me, changing to a new firmware development platform is a serious undertaking.

We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.

Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)

But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).

In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.

I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.

What tips or process do you suggest when transitioning to a new embedded development platform?

-Gary

Why Products Fail

It’s heartbreaking to see a product fail, especially when it could have been prevented.

There are typically two types of product failure. The first I call Field of Dreams -- “if we build it, they will come.” I’ve seen plenty of cool products built without a marketing, sales or distribution plan, usually by techies with a great idea and impressive skills, but not much business sense.

The second scenario might be harder to see. This is when there’s a real business need and a real market, but for whatever reason the company can’t satisfy it. Whether it's the inability to get the product out the door (scope creep), or a released yet inferior product, it’s painful to see a real opportunity missed. Especially when you know it could have been prevented.

When I talk with entrepreneurs, the questions that I ask typically go in one of two directions. For the techies, the questions are about business plans and sales and marketing strategies. The business folks seem to have all of that figured out, so I usually just talk about the testing and support of their product.  It’s important to know what you don’t know, and some gentle questions can get you there.

-Judi

The Value of a Startup Mentality in Large SW Companies

Many of the large companies I work with, and have worked for, are trying to figure out how to create an entrepreneurial culture in the fashion of today's successful startups. I think this is a fine idea, especially the modeling of two particularly attractive traits of startups.

1. Speed: They just get things done! There’s no long approval process, and sometimes there’s no approval at all. "Just do it" is the mantra. Of course, speed should never turn into carelessness, which can then turn into chaos.

2. Budget: I know one firm that has built one of the most innovative and technically challenging products I’ve seen in a long time using various open source products. In a big company, there’s often money to spend, and it gets spent, and often with much less successful results.

I’ve worked in both big and small companies, and there are advantages to each. The resources of a big company are nice, but for me, nothing beats the passion and resourcefulness of a startup.

-Judi

Designing a Robust Communication Protocol

In today's world of designing distributed embedded systems, it is imperative to design, document and test the communication protocol early on.

I recommend building upon the layers of protocol provided by the underlying architecture you have chosen, for example, TCP/IP, Bluetooth, USB, etc. If the underlying communication layer provides data integrity and delivery then it should not be duplicated in the application portion of the communication protocol. At a minimum, you are looking to have a low-level handshake between subsystems with assured delivery. Consider the following questions:

• Does the packet need to be routed?


• Does the sender need to know that the recipient received the communication packet?


• Is the data intact?

Now you can move to the business logic portion of the packet--the data payload definition--and begin to address these questions:

• Is there a command/response requirement?


• What is the general packet definition?


• Are there different types of packets?


• Is the packet size variable- or fixed-length?


• What are the physical units of the data transmitted?


• Was the packet understood by the receiving subsystem?

In addition to these questions, it's imperative that you list all of the possible error conditions. Ask yourself how you will be able to make them happen so you can test for robustness, which sometimes requires writing test applications to intentionally insert error conditions. Sometimes an external communication test device is the best choice.

There are many factors to consider, and this brief writeup is simply a starting point. What issues do you think are most important in building a robust communication mechanism?

-Gary

How Managers and Engineers Tackle Projects Differently

They say you can’t understand someone’s perspective until you’ve walked a mile in their shoes. Having been both a developer and a manager it’s interesting how the goals, desires and pressures on each differ. Ideally this wouldn’t be the case, but reality doesn’t always match up.

As a developer I always wanted to create the best work possible. If I could use cool new technologies and learn something in the process, even better. I took pride in the products we created, but was more focused on improving my skills and growing as a developer.

As a manager (and I noticed this more as I advanced more) I was focused on balancing competing priorities from customers (internal and external), delivering results as cheaply and quickly as possible, without sacrificing quality, of course, and shielding my development team from all the stuff that makes them less productive.

At times these differences caused conflict. Maybe trying a cool new untested technology is not the best business decision when you need to get something out quickly. Sometimes there was an opportunity to stretch one of your teams with an assignment, sometimes not.

Differing pressures are always going to cause conflict, but with a good dose of mutual trust and understanding they don’t have to be disruptive. As a manager I always tried to do my best to make sure my developers knew that I knew where they were coming from, and then tried to explain where I was coming from--and mostly it seemed to work.

What experiences have you had in this area?  I’d love to hear.

Judi

Curiosity Rover -- A Technology Powerhouse

I would be remiss if I failed to mention the biggest technology achievement of this year, the perfect landing and immediate operation of NASA's Mars rover Curiosity. In this stunning achievement of application of modern technologies, I want to point out this fine example of an embedded system.

Spaceflight Now has an excellent article on how the computer system was selected and built to work in the harsh Martian environment. Engineers at BAE Systems chose redundant and radiation-hardened PowerPC electronics to survive the thin Martian atmosphere. With 20% the CPU power of a modern smartphone, this device needs to be able to autonomously roam the surface for extended periods and be capable of sophisticated scientific experimentation.

It is interesting to note that there was not enough memory to store the landing software and the navigation software in the computer's memory. For the trip from Earth to Mars it had one mission, a perfect landing. Once the rover successfully landed and performed basic diagnostics the program memory was wiped and is currently being updated with navigation-oriented software. The new software needs to work flawlessly for a 2-year mission. There will undoubtedly be more updates but not a complete change of function.

For those interested in following its journey, visit NASA's official Curiosity website.

-Gary

How Process Improvement is Like Golf

Every time I’ve taken group golf lessons, the pro has started from the grip and gone through stance, swing and the whole works, laying out his best generic way to hit the ball. I recently learned of a golf school that prides themselves on the fact that they start where you are and help you improve the game you’ve already got. I love this!

This is the same approach I find most successful in process improvement work.  Every developer, engineer and organization has things they do well--and, as I firmly believe, if it ain’t broke, don’t fix it. Every organization has pieces of a process, which may not be ideal, but usually suffice for the time-being.

The key to keeping focus and gaining momentum in process improvement initiatives is finding those key leverage points that can make the biggest difference and leaving the rest for later. A golfer can only keep so many tips in their head, and a development organization can only change so many things at once without destroying their productivity.

Thanks for continuing to read. I love getting your comments back. If you have any suggestions for future topics, send them along, and I’ll do my best to cover them.

-Judi

Selecting an RTOS

Users searching for a real-time operating system (RTOS) for their project often get overwhelmed by the variety of commercial RTOSs available today. This variety nearly guarantees that an ideal system exists for you, but you finding it is a different question.

Embedded Computing Design published a helpful article about selecting an RTOS (this article was published a couple of years ago but the information is still relevant). An important note is that the article is written for selecting an RTOS for medical equipment requiring a high degree of safety and reliability. However, these are factors that should be considered for all embedded design applications, not just medical equipment.

One very important factor that the article does not discuss is RTOS cost. It becomes a complex decision when overall cost to develop the application is balanced against the direct cost of purchasing an RTOS. One needs to consider the initial cost to purchase the RTOS, per CPU license cost, associated third-party library cost with potential to save by reducing development and maintenance costs.

Check out the article and tell me what you think. I'll include your thoughts in a future newsletter.

-Gary

Do Business and Engineering Get Along?

A comment from David B on our recent blogpost on process fanatics got me thinking. He points out that there is often a “dichotomy in point of view and approach between technically focused people and business solutions folk. The more effectively you can get them to ‘walk a mile in each other's shoes’, so to speak, the better the odds of developing technical software solutions that meet--or even exceed--the needs of the end user.” So true!

I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.

Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?

On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.

Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?

-Judi

The Power of Negative Requirements

A requirement gathering typically focuses exclusively on what the product will do, how fast it will do it and the parameters in which it will operate. This is all important, but also, in my opinion, incomplete.

I like negative requirements because they stipulate specific features that a product or application will not provide. I find that by defining negative requirements a product development team and stakeholders can minimize confusion and the dreaded feature-creep. (There are enough stories of failed products and overwrought development teams to testify as to why it is not prudent to simply add a feature.)

When one puts a stake in the ground and states, the new product will not provide a specific feature and why, the conversation really gets interesting. From the development team's perspective, it helps to frame the product and handle change requests more effectively.

-Gary

Agile Myths

I ran across an article on Agile and loved it--not only because it mentions common myths about Agile methodologies, but also because it mentions common mistakes that aspiring Agile teams often make. I see too many individuals and teams using Agile as an excuse not to plan or document. That's not Agile--it's chaos.

Here's the article link: http://people10.com/blog/2012/05/13/agile-myths-answered-here/?goback=.gde_81780_member_114980795

Take a look, and feel free to tell me what you think. Thanks.

-Judi

My New Favorite Product

Pebble Technology in California has developed a watch using the new Kickstarter funding platform to raise over $10 Million by 68,929 backers. KickStarter is a direct offshoot of the JOBS Act, which enables entrepreneurs access to money from non-accredited sources.

I find the Pebble watch fascinating because it is one of the first products to act as a portable display device enabling hands-free monitoring of information on your smartphone. It is an intelligent e-paper wristwatch that communicates via Bluetooth with Android and iPhone devices.

And beside the fact that it’s just a cool product, what’s also interesting is that the company is planning an SDK to further customize the product to meet user needs.

Just thought I'd share my latest gadget-lust. Let me know what yours is.

-Gary

Software Design Considerations

In continuation of my content series on software development process I’ve added a video on software design. It talks about important aspects to consider and also issues about designing in an agile methodology.

You can watch it at http://www.youtube.com/watch?v=z5Xf3EO02E0

Also, I'll be recording some new videos soon. Feel free to suggest a topic you're interested in. Thanks!

Thanks For Chiming In!

We’ve received a ton of great comments on previous blogs, and I wanted to highlight a few of the best.
On My Cure for Overambitious Projects, Mark W. writes:

Most people realize “Rome wasn’t built in a day.” As long as individuals feel that their input, requests, and concerns are receiving attention and are being listened to – and not just being brushed aside, ignored, or pushed off ad infinitum; if they know that what they want is in fact for the most part possible and doable – just not right now:

So true!  One of the benefits of some of the Agile methodologies is that not only do the users see functionality being added on a regular basis, but they also play a key role in sequencing new development.

In response to Are Your Error Messages Understandable? Doug Q writes:

It would be wonderful if error messages could go a step further (for those who are interested and click on “advanced details” or some such option.)

He goes on to suggest error messages could identify what’s wrong with the data entered to help the user solve their problem, and get information back to developers when necessary.  I think this is a great idea.

On Risk Management in Software Development, Bob K. suggests using Swim Lanes to identify risks in cross-functional communication/data flow.  He goes on to describe swim lanes:

The swim lane concept is one where each swim lane represents a function or department or division of a company. The lanes can also represent different companies. When information is transferred from one lane to another there is inevitably information that has to be re-transferred because it was not in the receiver’s required format, the initial content request was incomplete, the transfer schedule was incorrectly specified, etc.

Every time, in a project, there is an anticipation of data or information transference (especially across a swim lane boundary, a document should specify what information/data is wanted, the format of the information/data, the schedule for the transfer, etc. In simpler terms, there should be “expectation connectivity” between the sending and receiving functions.

This concept has merit and value in SW design when one program, module, subroutine transfers information/data to another. An interface spec should define this stuff. This approach is generally helpful in those environments that try to create re-usable SW and develop SW libraries for future projects/applications. The swim lane concept has value for any type project but recognize it is but one tool at the project manager’s disposal to bring the project in on time, within budget, and meeting the technical performance requirements.
What a great tool.  I can’t wait to try it. I think it will work just as well in process improvement initiatives.
Thank you so much for all the responses.  I’m really enjoying the conversation, and more importantly – learning a lot!

-Judi

Are Your Error Messages Understandable?

Even though we like to picture ourselves as flawless developers, it’s important to address how our systems will behave when users encounter an error.

I usually break the possible system responses into 3 categories:

1. Bad: The system throws the user out, and potentially deletes the user’s unsaved work.

2. Slightly Better: The system doesn’t throw the user out or lose their work, but brings up a cryptic message in programmer-ese that just confuses the user.

3. Best: The system brings up an error message that’s understandable and informative, and also provides advice on how to avoid or fix the error.

If you hadn’t already guessed, I recommend the third option. However, this is also the most difficult to properly configure, because each system error must be linked to a plain-English explanation.

Emily Wilksa, a former technical writer for Microsoft, has written a helpful article on writing effective error messages. Click here to read it: http://www.writersua.com/articles/message/index.html

-Judi

 

My Cure for Overambitious Projects

You’ve probably encountered clients that request an unrealistic amount of features to be included in a product. They’ll start by listing a few features that the product “absolutely must have,” which suddenly reminds them of a few more features, which then brings up more that “we probably should include.”

Meanwhile, your headache is growing because you know that such lofty expectations always fail.

Well, it’s time like this, before any of the development begins, that you’d benefit from splitting up feature requirements into two categories: essential and supplementary.

This simple action will save you enormous stress later on in the development process, because it forces both you and the client to agree on what is most important, and what can wait.

After you make the list, give a copy to your client, and keep one for yourself. Whenever an issue about including more features comes up, refer to the list and ask, “Is this truly necessary?”

-Judi

Here's My Template for Subsystem Interactions

Subsystem interactions are a tricky part of embedded system development.

I’ve experienced many projects where team members are assigned to develop a specific subsystem, and though they succeed at their individual task, they overlook how their system will interact with the other subsystems, which can lead to a dysfunctional product.

This ignorance of subsystem interactions is usually found in a bottom-up design approach, but can sometimes be found in top-down designs, in which attention to detail for performance, error handling and test strategies are all lacking. (These are not the only important requirements but for whatever reason I find them most often overlooked.)

Anyway, to help you out, I compiled a simple Excel template that displays these categories for multiple subsystems. Click here to download it: http://advanceddecisions.com/excel-sheets/ADI-Subsystem-Test-Case-Template.xlsx

Some More Comments on Overambitious Projects

I previously asked readers to share their experiences with overambitious projects. Here were some of the replies:

Creative people always desire to create a perfect product. And it is very difficult to stop perfecting it… It’s not easy to differentiate between essential and supplementary features.

Also interesting fact from the “big science” molecular biology – the Human Genome project (that was also saturated with computation and programming). Finishing sequencing took as much time as the first 90% of sequencing work.

So true. There's an understandable amount of pride that creatives and entrepreneurs feel about their work--sometimes to their detriment.

And also this suggestion on how to handle feature-hungry clients

As a product manager, I have dealt with this issue many times.  It always helps to ask the client (internal or external) to estimate the additional sales that will occur if the new feature is added.  Invariably they either realize the answer is zero, or understand they have no way to credibly answer. No additional sales, no money for development. Simple but effective.

What a fantastic idea. It lets the client clearly see the value of each additional requirement.

-Judi

The Value of Defect Prevention

Steve McConnell reported in 1996 that "early upstream defects generally cost 10 to 100 times as much to remove late downstream as they do to remove close to the point where they are created.”

So why is it that we spend far more time, effort, and dollars on defect removal than defect prevention? Because, sadly, preventing problems is not sexy.

Many programmers and people in general, love to be the hero. Finding and fixing that critical error provides a great adrenalin rush. But when you consider time-to-market or cost issues, this model just doesn’t make sense.

A few of my go-to defect preventative tactics include:
• Requirements reviews
• Design and Code reviews
• Coding standards
• Writing test cases and plans early
• Automated build and smoke tests

-Judi

Embrace Change

I’m amazed how many developers and companies are reluctant to adopt modern technologies in their projects, especially when it could cut significant costs from the development process.

I even recently met a team who is still designing serial communication ports for their external interface. Ouch.

Thus, I'll focus my next few emails on development technology areas that have significantly benefited from recent innovations:
• Display technologies: highly integrated graphic chips and capacitive screens
• Wireless communications: near field communication, Bluetooth, WiFi
• Location-based systems: low-cost integrated GPS chips

-Gary

[Video] 4 Critical Pieces of Software Development Processes

I just finished up a video explaining the most critical aspects of software development processes.

It's an issue that I'm fanatical about, especially because it involves basic software development strategies that can save companies tons of money and time. (And who doesn't love extra money and time?)

Anyway, the video is 4:23 long, and introduces the below topics.

• Requirements


• Design


• Testing


• Source Control

-Judi

 

P.S. Let me know what you think of it!

Is Android Viable for Medical Devices?

I recently attended the RTECC Boston Conference and was not disappointed.

Of particular interest was the keynote address by Alan Cohen of LogicPD about the viability of using the Android operating system for medical devices.

I approached the conference with 3 key questions, which I've since answered below.

1. Why Android?

Android is a complete framework built on embedded Linux with a fully implemented GUI right out of the box. It can begin developing an application very quickly, is a terrific development environment to rapidly develop a proof of concept, and is highly customizable.

2. Is the Android operating system suitable for medical electronics?

Android is only suitable as an adjunct to time-critical or life-critical processing. It is not a Real-Time Kernel (RTOS) and therefore not suitable for hard real-time applications.

3. Will Android be relegated to display-only functionality?

Mostly, but relegated is too strong a word. It is ideal for user-interactive applications since, according to Alan Cohen, there is a convergence in the medical device world and the consumer world.

Some key Android points:

• Built on Linux

• Built-in power management module is non-trivial since it is geared to phone/data devices

• Application licensing can be tricky (the kernel is GPL license). Even though Android is free, some Android Device manufacturers nonetheless pay royalty fees to Microsoft?

• Android allows very easy creation of embedded Linux applications with GUIs

 

-Gary

Creating Software Requirements Processes

It's hard to perfect your software development process without a solid requirements process in place.

I just finished up this video about software requirements processes that covers

• How requirements are done in different software processes


• Proper requirements formats


• Who should be involved in the requirements writing

Enjoy!

The Popularity Contest

 

Having trouble viewing this email? View it in your browser.   The Popularity Contest In an effort to keep our subscribers happy we've decided to allow segmentation of newsletters.   This means you can now choose if you want to receive   Only Judi's newsletters, focusing on software process improvement   Only Gary's newsletters, focusing on emerging embedded technologies; or   Remain receiving newsletters from both Judi and Gary     Click one of the links above to segment yourself. (Note: the links will direct you to our website in addition to recording your newsletter preference.)   We'll provide this option in all newsletters from now on, so you can resubscribe or unsubscribe whenever you please. Thanks.   -Judi and Gary   Back To Top   Know someone who might be interested in this email? Click here to forward it.   Not interested anymore? Unsubscribe.              Located in Connecticut. Serving primarily CT, MA, NY, NJ, RI, NH, VT and ME Advanced Decisions | 4 Corporate Drive, Suite 485 | Shelton, CT 06484 TEL: 203.929.1400 FAX: 203.929.1470 Toll-Free: 888.795.1500

 

Process Fanatics are Necessary

Most development executives want to improve their product development processes and achieve

• Faster time to market


• Higher quality products


• Products that resonate better with users

And though all of these can be achieved with improvements to software development processes, they rarely seem to get done.

One recurring reason for not achieving these is the absence, in many software organizations, of a dedicated SQA (Software Quality Assurance) employee or department. Too often, management loosely assigns the responsibility to an already-overworked employee, which guarantees that SQA will crash and burn.

It's too bad that SQA is given such mediocre attention, because it's often the key factor in achieving better products that release faster.

Do you agree? Is SQA often the secret to better products?

-Judi

Who's Testing Your Code?

I often talk with software executives about the structure of their software development teams.

Some of their common questions are

• Should developers interact with users? (Yes)


• Can developers write their own requirements? (Sometimes)


• Can developers test their own code? (No!)

I believe strongly in the last question's answer. There needs to be someone else besides the developer to test the product.

Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.

Who tests your code? Are they doing a good job at it? Let me know.

-Judi

User Interfaces for Embedded Systems

I've always been interested in the user's interaction with embedded systems.

My primary embedded design goal is to make the man-machine interaction simple and intuitive. And today, more than ever, technologies are available that enable the creation of rich yet user-friendly experiences.

I recorded this video to introduce some topics I keep in mind when embarking on a new embedded design:

• Important factors to consider

• Technology alternatives

• User involvement

Let me know what you think. Thanks.

-Gary

Risk Management in Software Development

 

One of the tenets of many mainstream software development processes is proactively managing risk.

Of course this sounds like a good idea, but the question becomes: how do you do it?

I've learned that addressing the riskiest areas in a project first usually creates the biggest returns. This is difficult, however, because most people gravitate to the easy things first.

The problem with going with our natural tendencies is that we can tackle a lot of easy things without actually accomplishing anything of significance. And if the risky thing doesn’t work out as planned we may have to throw away some of the prior work, which is always a major frustration.

I'm curious how my readers manage risk in a software development process. Let me know!

-Judi

 

 

GPUs: The Unsung Hero of Embedded Displays

GPUs, also known as Graphics Processing Units, are the unsung hero of smartphones, tablets, and embedded displays.

The incredible throughput rates of GPUs allows for computation that standard multi-core Central Processing Units cannot provide. 

Companies are also beginning to add application processing to the GPU, known as GPGPU (General-Purpose Graphics Processing Unit). This is not a hardware device as such but is software and hardware working in concert on a GPU.

Since GPUs are not oriented to traditional application programming, various software platforms have evolved. OpenCL is supported by an industry consortium, KhronosGroup.org to promote platform independence.

The competing standard is CUDA which was created and is promoted by NVIDA, a leader in the GPU market.  Some say NVIDIA's  GeForce256 was the first GPU. (At least it was marketed that way.)

Anyway, I'm interested to hear what GPUs my readers are currently using, and if they have any comments on their usefulness or shortcomings. Let me know.

 

-Gary

Software Development Process Implementation: Things to Consider

 

I just finished this video explaining the most critical aspects of implementing a software development process.

It's an issue that I'm fanatical about, especially because it involves basic software development process strategies that can save companies tons of money and time. (And who doesn't love extra money and time?)

Anyway, the video is 4:23 long, and introduces the below topics.

• Requirements

• Design

• Testing

• Source Control

-Judi

 

 

Headless Embedded Systems

Something I have started to notice is the growing use of tablets to serve as the primary user interface for real-time embedded systems. This is in direct opposition to the long term tendency for embedded systems to sport integrated and increasingly sophisticated user interfaces.
At first glance this does not appear to be such a good idea due to the economics. The unit cost of a tablet is quite expensive. Only certain embedded systems could even consider the use of a tablet as the primary user interface due to the cost factor. However its use can make sense, in certain products, especially when considering the total cost of creating a custom graphical user interface.
Integrated graphical user interfaces require custom electronics and software. Much of the development is geared to integrate the user input and display devices with the rest of the system software. A great deal of software is often required to simply display data to a user or receive input from the user. This software device layer often takes a significant chunk of the development time and resources. And the application program that the user interacts with must still be written.
In the past year, several companies I have met with are considering the use of tablets or even smart phones for their user interface needs. They expect to reduce the complexity and the cost of developing the new product by essentially eliminating custom development of a graphical user interface. Leveraging an off-the-shelf solution enables the companies to get their product to the market sooner.
So I am curious, are you also seeing this as an emerging trend?

Testing Real Time Embedded Systems

 

Gary Felberbaum, the Principal of Advanced Decisions, talks about testing real time embedded systems.

How early should someone consider testing?

The earlier that someone gets involved in setting up the strategy and setting up the architecture to enable testing is really important. You should to start thinking about how you will test an embedded system as soon as you are conceiving a project or an embedded system.

What is needed to get started?

The same steps are needed when starting to test or develop an embedded system. The starting process refers back to the simplest thing which is requirements: sitting down, defining what it is that you want to build, and then thinking about how to test the system (adding special electronics, special software, etc.).

Why is embedded system testing different from other software application testing?

It is different because you are interacting with a lot more real-world, physical processes. You’re measuring things that you may not have control over, while in application testing you can set up a test database and test against the test database. In the real world, for applications you have to think about how you’re going to simulate processes that you can’t control and that may take designing certain types of computer model and simulations that you need to do to make embedding system testing actually work.