Focus Applications

[alukindo]

Hi:

I am finding that its is hard to develop really useful applications when doing one-off projects where a customer writes a one or two page requirements document and wants an application to meet those requirements. Hence, my focus these days is doing specific applications targeted to a given field or clientele. Currently these fields are Geotechnical Materials Testing Informatyion System (MTIS) also known as LIMS (Laboratory Information Systems) and Measurement While Drilling Applications & Logging While Drilling Applications (MWD/LWD). A link of GUI for these is available here.

. . . if anyone is in the same field for these applications we can communicate further.

Thanks

Anthony L.

[PaulG.]

QUOTE (alukindo @ Jul 5 2008, 07:39 PM)

I am finding that its is hard to develop really useful applications when doing one-off projects where a customer writes a one or two page requirements document and wants an application to meet those requirements.

Danger! Danger! Danger! Danger Will Robinson!! You are not making any sense. How can an on-off project be a single one or two page requirement? I know nothing of your specific application, but I can tell you that "on-off" projects are diametrically opposed to one requirement. "Scope creep" will kill you. Professionally and financially. Do the absolute best you can with the current requirement you have. If the functionality is not on the requirement, you don't do it. Period. If the customer wants more, you draft a new requirement. I'm just looking out for your sanity ... speaking from experience.

[alukindo]

Hi Paul:

Just to clarify, here I am talking about a rather comprehensive project. Not a simple setup application that controls say a motor or heater.

Otherwise, I understand that the general requirements statement in my posting is subject to varied comments. However, perhaps the broader question is why do companies buy-out other software companies to get their products while they have a large team of internal developers who can gather requirements and supposedly build the same piece of software? For example why did Oracle buy Peoplesoft and Siebel ---Buying market share could be a big reason but Oracle was in the same field earlier than these other companies. Infact Siebel was started by a former sales employee of Oracle (Tom Siebel) who turned into a developer.

After ~10 years doing software development, with 5 of those years doing consulting projects for other clients, I've come to a point where I feel that to build a really successful comprehensive product where a majority of stake holder users readily accept and find indispensable, one needs to be close to the field of application and understand the users very intimately. One needs focus, specialization, and numerous field trials over an extended period of time. Transferring requirements from paper to software say in six months rarely results in a really good comprehensive product.

As I write this I continue to do what I call 'one-off projects' and I try to get requirements fleshed out in detail. However, the time alloted to complete the project allows a so-and-so piece of work to be delivered and there is always a shortlisting of requirments to balance-out the cost.

. . . But thanks for looking out for me. I think I understand the comments you posted.

Anthony L.

[crelf]

QUOTE (alukindo @ Jul 5 2008, 07:39 PM)

I am finding that it is hard to develop really useful applications when doing one-off projects where a customer writes a one or two page requirements document and wants an application to meet those requirements.

That statement confuses me - you write an application to fulfill the requirements of the customer, and you don't think the application's useful? That just doesn't make sense - you're fulfilling thier requirements, so how can it not be useful? Or do you mean useful to you as a developer? My industry (test) is all about value - if you're providing value to the customers (both external and internal) then all is well, and the external part of that equation is balanced when well-written requirements are prooved but the execution of a well-written acceptance test plan. There are, of course, plenty of steps between the two, and that's where you satisfy your internal customers (through process definition, architecture creation, scientific exploration, reuse leverage, etc).

QUOTE (PaulG. @ Jul 5 2008, 09:44 PM)

Danger! Danger! Danger! Danger Will Robinson!! You are not making any sense. How can an on-off project be a single one or two page requirement?

Of couse that reminds me of Lost in Space, but also the Chewbacca defense I have worked projects with one or two page requirements before (many years ago), but only on a time and materials basis with a very clear contract that includes the term "all care, no responsibility". These contracts are typically short and the customer really has little idea of what they really want. They're good for some short-term cash flow, but maybe they're the type of project you're talking about: they usually end in more of a fizzle and the customer ends up with something that's only partially helpful, so yes, I 'd agree that those sort of apps aren't as "useful" or fulfilling.

[alukindo]

Hi Crelf:

You are right that how can you deliver a project against requirements and yet find that it does not meet those requirements.

Usually what I find is that the written-down requirement statements may be met but what lacks is useability or lack of small user-features that look insignifucant but prove to be critical in getting the larger task accomplished. The commissioning test will even pass with good reviews. But after three to six months of use, user complaints creep in based on scenarios of use that make the application look cumbersome or even a show stopper.

QUOTE (crelf @ Jul 6 2008, 09:34 AM)

. . . I have worked projects with one or two page requirements before (many years ago)

Crelf, it is interesting that you mention doing those types of projects 'many years ago'. So could it be that your latest projects are larger projects where you have a long term working relationship with your clients? I am interested and would appreciate clarification on the nature of the newer projects and your general client profile? E.g: Are the customers aware of the software development process? Do they do many software projects? etc, etc. The interesting part is how did you transition and stay focused on these other projects?

Thanks

Anthony

[crelf]

Aw bugger - I just wrote a long answer, but lost it all due to one erroneous keystroke I'll try to summarize what I'd already typed:

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

You are right that how can you deliver a project against requirements and yet find that it does not meet those requirements.

That's not what I was trying to say at all, in fact: it's the complete opposite If you have an appropriate acceptance test plan (ATP), then you can't not meet the requirements. I think what you're trying to say is that, although you might deliver something that meets all the baselined requirements, it might not actually be appropriate for the job it was intended. In other words, it does what they asked for, not what they wanted. That's the difference between verificaiton and validation

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

Usually what I find is that the written-down requirement statements may be met but what lacks is useability or lack of small user-features that look insignifucant but prove to be critical in getting the larger task accomplished. The commissioning test will even pass with good reviews. But after three to six months of use, user complaints creep in based on scenarios of use that make the application look cumbersome or even a show stopper.

Then you were working with poor requirements. If the user complains that something is wrong (or even a shopstopper) then that requirement wasn't captured during the requirements gathering phase. That's an area where, as engineerings, we can all really value-add: spend time with your customer and try to really understand what they want. PaulG's right: a one or two page requirement spec is a reason to be wary on anything bigger than the smallest of code components - it usually means that the customer hasn't really thought through their requirements, and are probably making assumptions that your product will contain certain features, act in a certain way, without that being defined in the requirements. If they're not in the requirements, then they don't need to be tested. Hint: it's vital that you write (and accept only) requirements that are written in an industry-standard format (we use IEEE 1233 1998) - words like "shall", "may", "will" must be defined, and make sure that all of your requirement statement ("shall") are noted in a way that they are traceable in design and ATP documents (have a traceability matrix that keeps track of all these things).

We have a whole team of engineers that work primarily on maintaining the technical solution throughout a project (requirements gathering and analysis, design, acceptance test planning, etc) - the team may not necissarily complete all of these tasks, but they coordinate them and ensure that they are all completed satisfactorily. We do this is for a few reasons, but the most important one is to make sure that the customer gets what they signed up for. Delivering a system that doesn't meet the requirements is poor engineering, and if we started a project working from requirements that we knew wouldn't satisfy the customer, then that's of little value to anyone, and frankly something that we simply don't do. If, during the project, it becomes apparent that the requirements need to be changed, then that's absolutely fine too: that's why engineering change orders (ECOs) were invented Quick Note: ECOs need to cost the customer money if the requirement change means more work (don't forget project management, accounting, etc required to process the ECO). That said, if they need the same amount of work or less work, then there's nothing wrong with zero-cost or refund ECOs. Ultimately, your customer is paying you to meet a list of requirements, and should be costed that way.

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

I am interested and would appreciate clarification on the nature of the newer projects and your general client profile?

Sorry, but I don't comment on our business relationships or client-base. That said, if you told us more about the sort of projects that you're working on, it might add some context to your posts.

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

Are the customers aware of the software development process?

Generally, yes. If they aren't when the relationship first begins, then they are before a contract is drawn-up.

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

Do they do many software projects?

This isn't going to answer your question, but our services are much more than software alone. We build test systems, so while software is an important compnent of them, it's not the only component. So, your question needs to be more broad (although, you rewriting it doesn't gaurantee that I'll answer it )

QUOTE (alukindo @ Jul 6 2008, 12:05 PM)

The interesting part is how did you transition and stay focused on these other projects?

I don't understand your question.

PS: I'm not a systems engineer per se (we have a whole team for that), but our operations model requires everyone in to be knowledgeable about systems engineering. We follow an internally-modified version of the V-Model on our projects, and have had great sucess. Why? Because everything we do is traceable to the requirements. If we deliver what we the customer wants and add value to the development process, then the customer is happy and we're making a difference in the world - and that makes crelf happy

I don't think I've given away any trade secrets here - these processes have been used successfully for decades, and have (with a little modification here and there) proven themselves to work for the types of porjects we work on. That said, they are not the only method, and may not be appropriate for you. All I'm saying is that they work for us, and that you should do your own research into a model that is right for you.

:!: Absolutely shameless plug: In fact, it might be worth your while to contact someone to help you define your process.

[alukindo]

Hi Crelf:

Thanks for your explanation. I figured that we are working on different philosophies where you define software development as an 'engineering process' while I define it as a 'craft' aided by certain rules. Thus we will continue to have somewhat differing views on this subject which is OK.

BTW: The question on 'newer projects and clientele profile' was a general one intended to differentiate project types that you do now versus the older (smaller) projects that you noted you did in the past. In no way did I intend to divulge your business relationships or client-base. My apologies if it seemed that I was trying to spy on anything.

In any case, when I visited the VI Eng web site I got direct answers to that question.

Regards

Anthony L.

[crelf]

QUOTE (alukindo @ Jul 6 2008, 01:45 PM)

I figured that we are working on different philosophies where you define software development as an 'engineering process' while I define it as a 'craft' aided by certain rules. Thus we will continue to have somewhat differing views on this subject which is OK.

I don't think we do - I think of software development as craft that is aided and bound by certain rules - rules which I refer to as engineering processes. I honestly think that we're talking about exactly the same thing, just looking at it at different levels.

QUOTE (alukindo @ Jul 6 2008, 01:45 PM)

BTW: The question on 'newer projects and clientele profile' was a general one intended to differentiate project types that you do now versus the older (smaller) projects that you noted you did in the past. In no way did I intend to divulge your business relationships or client-base. My apologies if it seemed that I was trying to spy on anything.

No worries at all - I didn't think you were trying anything untoward at all, I just wanted to be clear on how much I can and cannot share.

QUOTE (alukindo @ Jul 6 2008, 01:45 PM)

In any case, when I visited the VI Eng web site I got direct answers to that question.

I figured that you would

Anyway, good luck - it sounds like you're at an exciting step along your path :thumbup: If you need any help or want someone to bounce ideas off, that's what LAVA's here for.

QUOTE (alukindo @ Jul 5 2008, 07:39 PM)

A link of GUI for these is available

here

.

PS: I like your GUIs - they seem to follow the standard principles of user interface design (see here and here), especially the preservation of precincts and vision flow.

[JiMM]

Interesting thread guys. I am trying to aim myself towards a future move into contract systems engineering, and it is very interesting to read about the process that this involves. It is very much different from an internal developement process. Mistakes in calculating the developement time and cost are not nearly as costly (personally) on an internal developement process (especially in a large corporation).

[crelf]

QUOTE (JiMM @ Jul 6 2008, 05:49 PM)

Interesting thread guys. I am trying to aim myself towards a future move into contract systems engineering, and it is very interesting to read about the process that this involves. It is very much different from an internal developement process. Mistakes in calculating the developement time and cost are not nearly as costly (personally) on an internal developement process (especially in a large corporation).

That is true, if you measure "costs" as purely financial

As an aside - the processes that I'm talking about don't necessarily come cheap - they do take time and expertise to scale them for your operation, and implemenation isn't immediate either. That said, it doesn't need to be a painful process: as long as the stakeholders (management, engineering, operations, etc) are all substaintially involved in the development of the processes, then it's difficult to fail.

As I said earlier, I'm no expert, so check out the Control System Integrators Association* (CSIA) for more info - they're the guys that really know how to do this sort of stuff well in the context of test. Check out their website - it's got some interesting stuff on it.

* V I Engineering, Inc. is both CSIA certified and has a CSIA Executive Board Member on staff, and National Instruments is a CSIA Partner.