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