Software Development Life Cycles in the FileMaker Development Arena

/4 Comments/in , /by

Software development life cycles are well understood in the industry. However, most of our clients are from fields completely unrelated to software production. With this article I aim to give the prospective client a little insight into how the process works and why we charge for creating an estimate.

I have some friends who are architects. We talk shop sometimes and the more I talk to them the more I realize our industries are actually very similar, I just don’t have to get the large liability insurance. The process of building a house is very similar to the process of building a database: you have phases in which you accomplish different tasks, with each phase building upon the one that preceded it. The end product should be the result of specifications established throughout the planning and design phases.

Custom development generally has the following phases:

  1. Analysis
  2. Specification Building
  3. Design and Development
  4. Testing and bug fixes
  5. User Acceptance Testing
  6. Maintenance

Most clients are happy to pay for step 3. The other 5 steps are the ugly stepchildren. They are, however also an integral part of software development.

Let’s go back to the house for a second. Has anyone contracted an architect to build something for them or just remodel the kitchen? In this country not a lot of people build from scratch, but where I come from that was a more common way of acquiring a new home. So, think about it, can you realistically approach an architect and say: “I’d like a house to be built, but I’m not willing to pay for the quote, the blueprint, and I shouldn’t even have to come and visit, because you’re the architect, you know what I need, so just build my house.” How many buildings do you think would be built like this? When you are building a house, you have to be part of the process, because it will be YOUR house, not the architect’s. It is your influence that will make that a comfortable home for you. Architects will know the material specifications and how to design and build in general but every building is different, therefore the whole process is different. The same applies to custom software development; it will be YOUR product.

Analysis

When it comes to custom software development, prospective clients who basically just tell me the big picture of their idea and tell me to give them a quote and want to get it built yesterday are more the rule than the exception. Well, guess what? I have no idea how you want your database to function! In the same way, an architect would have no idea how many bedrooms you want, how much storage space you need, or what color you’d like your bathroom to be. Now, these might be minor details, but they surely are important details. Analysis is very important. That is the stage where the clients shows how they work, what problems arise in their daily workflow, and we all work together to tackle those.

Why we charge for analysis?
Because it’s one of the most important stages of your development. Again, back to the architect example: would you want an architect to build your house without a blueprint? No, you don’t (or, at least, you shouldn’t!). Does an architect charge for creation of the blueprint? Yes, they do. And they do because it is a lot of work. You have to gather enough details to be able to draft documents, go over them again and again to be able to come up with a set of requirements to build from.

How much do we charge for analysis?
That depends on the scope of the project. Generally we start with 10 hours, but for larger systems it could easily take 20-30 hours. And yes, the client has to participate. We have meetings (generally held remotely) during which we do some research on your existing tools and process, and learn about the details of your requirements. The end result will be an estimate with low and high numbers of hours for the job along with a plan and schedule for deploying it.

Specifications

This document is the result of the step above. Yes, it takes time (and thus money) to prepare, but in the end it’s to everyone’s benefit that it exists. This is the blueprint that all following phases will adhere to. It defines the scope of the project, clearly lists out requirements that need to be met by the system being built, and lays out how the system will meet each of those requirements. Perhaps more importantly than its technical function, it also serves as a standard both parties review and agree to, so everyone has a clear understanding of what deliverables to expect.

Design and Development

This is the phase in which we build and test all of the code and processes required to satisfy the architecture and design specifications. We build according to the specifications document that we prepared. At this stage deviating from the plan can slow the development down and/or can make it more costly. So by the time we get to building, we should have all screens, processes and reporting needs established.

Testing and Bug Fixes

Once the application has been built, it is time to perform the following tests:

  • System testing (to make sure your server environment is sufficient);
  • Integration testing (if there’s any);
  • Performance testing; and
  • Data load testing.

User Acceptance Testing

This is the stage where the client reviews the delivery to be sure all agreed-upon requirements are met. Think of it as taking a new car out for a test-drive. It’s helpful to write out test cases to plan out how you’ll approach your review and ensure that you have proper tests to match against every requirement in the Specification document. But whether you have a test plan or not, make sure it meets your needs by running it through all the same scenarios that you’d expect it to be able to handle during day-to-day, real world usage. Its performance during your review will give you a clear picture of how it will work once deployed. Once you’re satisfied, acceptance is given, and the product is considered officially delivered.

Maintenance

If you have a car, the maintenance includes regular oil changes, a wash, more air in the tires, amongst other things. A database that is working does not require similar actions, but it’s worth checking the system on occasion: making sure your backups are running and they are not corrupted; creating healthy clones, making sure your server is chugging along nicely, etc. This can be performed by the developer or in some cases, the client themselves.

These are the main phases of development, and we hope you have a better understanding of how the process works. Custom development is just that—custom—and each phase is critical for the creation of a solid product catered specifically to your needs.

 

Top 10 Suggestions If You Want To Hack At A Database Yourself – For In-house FileMaker Developers

/0 Comments/in , , , /by

All FileMaker developers start somewhere, and that place is definitely not being a certified independent developer. I started by being an in-house developer. Working in a busy environment, all you have time for is cranking out the features that your boss needs, right away. Nobody has time to think about consequences. My job was to get that report done, no matter how many calculations I had to add so I can produce the results. Or getting that extra layout in so we can show the data on a different list. All of these things add up, and eventually they make your file larger and/or slow your database down.

As an independent developer, you start from a different perspective: data and system integrity are most important. Over the last 4 years since I’ve been developing independently I have learned a lot from fellow FileMaker developers. I had learn to to rethink how I develop and incorporate planning, design, testing and other steps to my routine. It wasn’t so much reinventing the wheel so much as making it better.

One great thing about FileMaker (aside from it being agile) is that anyone can become a developer. If you feel like you have enough skills to create what you need, feel free to get started. You can purchase volume licenses with great discounts even for a small office from us. And if you get in trouble, you can always consult with us during your project or even years later, when you realize that it’s actually far from where it could be.

Here are some conventions to follow if you start on your own. These will help you greatly down the line. Follow @zerobluetech on Twitter to ask questions.

  1. Be minimalistic:

    Create what’s needed, not more but not less. A lot of times we don’t think about the effects of what we do; what’s another calculation, right? Think again. The more calculation fields you have on a layout, the slower the layout loads. We’ve all seen layouts that said “summarizing” for over minutes. This is easily avoidable by storing data in indexed fields.

  2. Break your scripts into smaller chunks.

    Don’t write scripts that would print on several pages. By the time you write it you’ll forget what the beginning was all about.

  3. Follow a naming schema.

    There are a lot of them out there, but you can certainly invent your own. Stick to it.

  4. Comment your code.

    Comment calculations, scripts and even layouts if needed. You (and others) need to know what’s what at a later time, too.

  5. Implement strict security features.

    Steven Blackwell (@filemakersecure) cannot say this enough but people are still not listening. 🙂 If you have strict control over who can access your data, you have a much better chance of avoiding disasters.

  6. Use custom menus for controlling access.

    Take away “delete all records” from all users–then you won’t have to restore thousands of records (and lose the ones that weren’t captured in the last backup).

  7. Talking about backups:

    Back up, back up, back up.  Every 30 minutes or ever hour (depending on your storage space), but at least once a day, week and month. Save clones of your working database. In case database corruption, you can export the data and get it imported to an earlier clone and you’re back in business. Compact the clones to save disk space.

  8. Do not store images in FileMaker container fields.

    Contrary to popular belief, your database will get large and clumsy over time. Use SuperContainer and now DocuBin to manage files.

  9. Stay away from a lot of graphics.

    Do not paste large images on your layouts: they will just slow your database down. Create 75 dpi PNGs if you can. They will also preserve transparency. Or put them into container fields so the dataabse will have to load them once, as opposed to on any layout. Here I’m talking about your layout design (header, buttons), not your records!

  10. Use forums, mailing lists and friends.

    Don’t spend time reinventing the wheel. Someone already did it.

Hope this will save you guys a lot of time. Had anyone broken things down into digestible chunks I certainly would’ve not spent a lot of my evenings at work recovering data other people lost accidentally or rebuilding features because my database got corrupted. Glitches can still happen and they will happen. You can, however reduce the opportunity for things going bad.

You will run into walls, we all do. But don’t be afraid. Start working on something or modify any of the FileMaker starter files.

If you need help, feel free to contact us; we provide consulting services in the New York, New Jersey area, or to any region where screen sharing apps are accepted. First hour of consulting is free.

Also, check out our services, portfolio and products.