Category Archives for : Development

I was the 2nd presenter in line to have a go on the Tech Talk session series at Cinergix. I decided to make the focus of the presentation to center on a QA Quality Factor which is known as “Reliability”. Generally, if something or someone is described as being “reliable” it gives an idea of being trustworthy and dependable. Reliability which is a time-bound component implies successful operation over a certain period of time.

Reliability in software can be defined as “the probability of a computer program performing its intended functions, without any failures for a specified time under a specified environment”. For web applications such as Creately, reliability is an important Quality Factor that needs to be considered. Achieving reliability will give you benefits in the areas of:

Customer Satisfaction – unreliable product will negatively affect customer satisfaction severely. Thus high reliability is a mandatory requirement for customer satisfaction.

Repeat Business – Customers will return to a website that is reliable & has a positive impact on future business

Reputation – When a product is reliable the company will have a favorable reputation

Competitive Advantage – Companies can publish their predicted reliability numbers to help gain an advantage over their competition who either does not publish their numbers or has lower numbers

Warranty Costs – Reliable products will fail less frequently during the warranty period. This will lower the repair & replacements costs & refunds

Cost Analysis – Reliability data can be used for cost analysis. Reliable products will show that although the initial cost of their product might be higher, the overall lifetime cost is lower than a competitor’s because their product requires fewer repairs or less maintenance

To achieve reliability in software, activities can be followed in the areas of:

1. Error prevention

2. Fault detection and removal

3. Measurements to maximize reliability, specifically measures that support the first two activities

1. Error prevention activities

When it comes to error prevention activities, there are many things that need to be undertaken in order for you to achieve reliability. While it would be impossible to delve into the whole spectrum of these activities in this post alone, I will mention a few so that you get the gist of what  these activities entail. Ideally, you need to have requirements that should clearly & accurately specify the functionality of the final product. Moreover, you have to follow proper coding standards, perform regular code reviews for correctness & safety and perform unit testing to independently test the modules. Other activities that need to be considered would be load testing to determine the system’s behavior under both normal and anticipated peak load conditions and to also perform regression testing after additions or modifications are done to ensure that the existing functionality remains the same.

2. Fault detection and removal activities

There are two aspects that need to be considered here – Software Testing & Software Inspection.

3. Measurements

Reliability metrics are units of measure for system reliability. System reliability is measured by counting the number of operational failures and relating these to demands made on the system at the time of failure. As far as this topic is concerned you need to take into consideration Static Code Metrics (which gives information at the code level) and Dynamic Metrics (which provides information on the actual runtime). Examples for Static Code Metrics would be Source Lines of Code (SLOC) of the program, Number of Modules & Go To Statements & Number of Classes & Weighted Methods per Class (WMC). One of the Dynamic Metric examples would be Failure Rate Data such as:

Problem Reports

When talking about problem reports, it is imperative that you use error logs & access logs to determine the following:

– Date of occurrence, nature of failures, consequences

– Type of faults, fault location

So there you have it. I hope this rather techy blog post acts as a good focal point when it comes to assessing your site or app with regard to reliability. I cannot but drive home the fact that this is certainly an aspect that can be regarded as being one of the best cornerstones when it comes to building a great site or app. Got any queries, comments or complaints, please do go ahead and let us know.

References: Software Metrics and Reliability by Linda Rosenberg, Ted Hammer, and Jack Shaw.  IEEE International Symposium on Software Reliability Engineering. 1998., http://swreflections.blogspot.com/2009/08/lessons-in-software-reliability.html, http://www.tectrends.com/tectrends/article/00172844.html, http://www.eweek.com/c/a/Enterprise-Applications/Measuring-SAAS-Reliability/

Creately was always about intuitive diagramming that was fast and smart. We’ve always made it a point to keep upgrading our systems to ensure that you face no delay at all when it comes to creating those all-important diagrams. So as tweeted by Nick yesterday, you should notice an increase is speed when it comes to certain functions.

A faster app means a happier diagrammer

Some of the improvements also includes a faster response time when it comes to functions such as Create, Save, Open, Rename, Copy, and Delete diagrams, amongst many others. Other improvements include a quick response to opening the document manager and selecting as much as five diagrams at once! It’s a no brainer as to how this could translate to real-world benefits.

We reckon our performance upgrade would save you a whole lotta time, thanks to time being reduced when it comes to the usual diagramming functions such as opening documents, creating diagrams, saving and publishing them.  But there’s more reason to cheer, our performance upgrade has inherently improved the response time for Central Desktop as well. Read on to see how.

Central Desktop is fast, real fast

As most users may already know, Central Desktop offers a complete Software-as-a-Service (SaaS) collaboration platform, which allows business teams to communicate and collaborate online. This collaborative workspace gets more powerful now with Creately’s integration into Central Desktop’s platform that offers customers the ability to translate their ideas graphically.

The new online diagramming feature makes it extremely easy for users to create a visual diagram and embed that into online documents, wikis and discussions with just a few clicks. The good news is that this process has got quicker compared to what it was.

Access our Public Diagrams faster!

A real testament as to how versatile and easy-to-use Creately is would be the vast amount of diagrams drawn by our users. Currently we have in excess of 100,000 diagrams that encompass everything from Block Diagrams to UML Diagrams. This page has been a constant source of inspiration for new diagrammers and there are many diagrams that could be graded as Novice at one end to Professional at the other end. Despite having thousands of diagrams, the time taken to load a page is now quicker than what it was. You can click a diagram to view it on the Creately Diagram Viewer, which is also fairly fast now.

There are more improvements along the way (very soon!) in the form of bug fixes. We appreciate all the bug reports you guys have sent us and we’re hard at work to make sure Creately is that much smarter to work on. We’re all for constant improvement; if there are certain things you want improved, you’re more than welcome to pop us a tweet or send us an email.  It’s true what they say, sometimes it’s those small details that can make a world of difference.

Diagram references: http://www.psdgraphics.com/icons/psd-red-speedometer-icon/

After a recent comment on the original Creately Diagram Viewer post I thought it would be a good idea to follow up with a full post to help all the other Creately users who also use Google Code and Google Project Hosting.

Google Code projects allow you to add Google Gadgets to the Wiki for the project. This means that you can add your Creately diagrams of the design, features and UI mockups for your project to the Wiki for all the project members to see and work with.

Creately Diagram Embed Code Google Code Projects

Due to the way that gadgets work in the Google Code Wiki there is an intermediary handler which means that the document ID that you want to display gets lost during the rendering if you use the regular variable names. In order to fix this it is possible to use the wiki markup similar to this:

<wiki:gadget url="https://creately.com/player/gadget/createlyplayer.xml" height="500" width="500" border="0" up_did="gcqjqs762" up_dlogo="true" up_dtitle="Embedding in Google Code" up_bgcolor="#EEEEEE" />

The variables of interest are:

• up_did – The Creately diagram ID that you would like to see rendered in the wiki page.
• up_dlogo – Display the Creately logo, either “true” or “false” – leaving it true gives us some promotion 😉
• up_dtitle – Sets the title for the diagram – you don’t need to worry about this for the Google Code wiki as it won’t be seen.
• up_bgcolor – The background colour behind the diagram being shown in the player. The default is: “#EEEEEE” and looks pretty good.

The size of the player in the wiki can be changed using the “width” and “height” variables – they set the size in pixels.

You can see a working example of the viewer in a project wiki here.

Thanks to Niels for posting the original comment which led to this post – you can see his Google Code project here.

@nick_foster

When you are building a software solution to solve a particular problem, you would be very focused on solving the problem and solving it well. However, from time to time you need supporting components in your solution that are not directly related to the problem you are solving. These are components that are required to complete your solution.

Maybe its a payment system for your online greeting card service, or a spell checker component for your realtime note editor, you would rather look for something that’s already built and working well rather than building it yourself from scratch. This way you can focus on your “core competency”.

This is generally how everyone thinks. So did we. Here at Creately, we chose to use a third party solution to complete a product that we were working on. In the rush and excitement of getting the product out we signed up with the 3rd party service not considering some important factors that we should have. Even though the intention was to avoid reinventing the wheel and save time and effort, the out come was us spending double the time and effort to get the solution to work. Lesson learnt the hard way.

A. Picking the most suitable solution

• How well is my requirement met? Does the solution meet all the feature and functionality requirements I have? Does the solution meet the integration requirements I have?
• Is the component build for me? Even if the solution meets all my functionality and feature requirements, one thing I have to watch out for is, if it does more than what I need. Will it complicate my product? or my users experience? or my integration process?
• Is the integration and setup process straight forward? Time and effort required to setup and integrate?
• What is the financial commitment?
• Considering all factors above, compare the time, effort and cost involved in building the ideal solution against using the selected solution.

B. Assessing if the solution can be used to solve the problem

• Can I use the existing features in the solution to make it do what I want it to do?
• Can the solution be customized to fit my requirements?
• What is the time and effort involved in customizing the solution for my need?
• What is the financial cost involved in customizing the solution for my need?
• Considering all factors above in A and B, compare the time, effort and cost involved in building the ideal solution against using the selected solution.

@Hiraash