best-practices

recent posts related to software development best practices

Designers design, programmers program

I'm sure this will sound strange to some people who know me, but I was happy to stumble on several Eclipse user interface design documents yesterday, including their UI Best Practices, User Interface Guidelines, and Top Ten Lists Working Page documents.

Business Analyst - If you can't count the Function Points, you're about to enter a world of hurt

One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you're doing as a business analyst. For example, here's one of the guidelines I came up with after I learned about FPA:

If you can't count the Function Points when you're about to start developing a software project, you're about to be in a world of hurt.

Software cost estimating with Function Point Analysis

Someone asked the other day if I've written any longer tutorials on software cost estimating and/or Function Point Analysis. Sometimes I forget that this site has grown pretty large, and things like this may not be easy to find with the current design.

To help solve that problem in the short term, here are links to two software cost estimating and Function Point Analysis (FPA) tutorials I've written:

Ways to improve your brain power

Recently I wrote an article about using meditation to improve your concentration and brain power. Today I'd like to briefly outline a few other ways you can help improve your brainpower.

Use your off hand

You've probably heard about this already, but if you're right-handed, learn to use your left hand. Brush your teeth with your other hand, write with your other hand, basically reverse everything in your life as your hands go. You'll be amazed at the difference.

Meditation leads to concentration

In other blog posts I've mentioned that I think meditation can be a great tool for improving your concentration, so I thought I'd take a few moments here to explain how to meditate. It comes very naturally to me these days, but if you've never meditated before you may not know how to get started, so I thought I'd share this very simple technique here.

Early software cost estimating using FPA (Part 2)

 

Using FPA, I quickly worked through several of our largest projects to determine our productivity rates, and also noted who worked on the projects, what technologies were used, along with a few other details. In short, in a few days I was able to create a database of our historical software development speed.

Early software cost estimating using FPA

A lot of times when a project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, Business Manager, etc.) want the best estimate they can get regarding the time and cost of a software development project. Again this may be very early in the project lifecycle, some time just after someone said, "That sounds like a good idea" and well before the project begins. In short, they want the best "back of the envelope" ("ballpark") cost estimate you can give them.

Software self healing pattern, part 3

Software healing component #3: The self healing program

In the first two parts of this tutorial I wrote about a worker program, and the functionality it needs to provide to support a self-healing architecture. In the second part I wrote about an open source program named Nagios, which can be used to monitor your worker programs. In this third part of the self-healing recipe, I will now write about what is necessary for the "healing" component.

Software self healing pattern, part 2

Component #2: The software monitoring program

The second piece of the self-healing architecture is to have a program that monitors your worker programs. You can write your own software monitoring program, as I did many years ago, but that's pretty old-school, and frankly, not a good idea any more.

Software requirements best practices - One question to ask yourself

As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I've seen some business analysts write some crazy things and call them requirements, but IMHO, if you can't test it, it's not a requirement.

(And quality software requirements helps lead to quality software applications.)

Syndicate content