Tech Talks - The Importance of Reliability

I was the 2nd presenter in line to have a go on the Tech Talk session series atCinergix. 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:

- Probability of Failure on Demand (POFOD)

POFOD = 0.001 (For one in every 1000 requests the service fails per time unit)

- Rate of Fault Occurrence (ROCOF)

ROCOF = 0.02 (Two failures for each 100 operational time units of operation)

- Mean Time to Failure (MTTF)

Average time between observed failures

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.htm…

Posted via email from Creately | Comment »

A new Creately Desktop Release amid Wesak

Today, we interrupt our usual slew of posts on diagramming and diagram types to make a new release announcement for Creately Desktop. Thanks to some really great customer feedback, we’ve been able to take all your concerns and include it into the latest Creately Desktop release. Some of the improvements include bug fixes, ensuring the process of syncing is smooth and trouble-free, while minute issues related to licensing have also been resolved. With this new release, you are sure to enjoy fast and easy diagramming par excellence.

Additionally, we got some great news for all our Creately for Fogbugz users. You can now renew your 1-year maintenance license by logging in with your existing account and extending your maintenance here. This license will allow you to enjoy a year’s worth of cool new upgrades for a nominal fee.

Indeed, things like bug fixes, new releases and updates may have kept the Creately team busy this past week but the truth is it has been a slow couple of days due to the celebration of Wesak in our R&D office in Sri Lanka. Taking some time off, the development boys and girls decked the office with colorful lanterns that are intrinsic to such an important religious festival.

Creately’s R&D center in Sri Lanka

As this week winds down, make sure that you stick to this space since the next few posts will focus on Sitemaps and some best practices related to it. Additionally, we just launched our Flowchart Minisite and Wireframe Ministe, so this is definitely a repository of valuable information that you should take a peek at. Stay tuned, more diagramming joy comes your way soon!

 

Posted via email from Creately | Comment »

Why you should annotate Wireframes

As we all know, clarity is the main goal of any wireframe or UI mockup. What we seek to elucidate via this post is that when structuring a wireframe you need to ensure that you

  • focus on the client requirements
  • ensure that the design is clear and uncomplicated
  • and you concentrate on annotating the design.

Simple points but certainly potent points to ponder.

If you have experienced rejection at the hands of your clients, one too many times, you must remember that it may not actually be a fault of your design. Rather it could be all to do with the way you present your design to your client. While most designers are adept enough to get 1 and 2 sorted, then usually forget to do 3. And this is where it all goes horribly wrong.

Looking at a design from a client’s perspective, he/she would need to understand it before taking a decision on it. This is what annotating does. Consider this task as a step-by-step guide to the functionality of explaining what a wireframe design is all about. So at this stage, a client would be able to understand the whole concept and then, after much reflection, pass judgement on it.

Find below 4 best practices when it comes to annotating wireframes.

1. Short, simple and sweet

Think about it. How many clients do you know have oodles of time for meetings? You get the point. When annotating, make sure that you are clear and succinct in what you state. Be convincing, state the usefulness of whatever you annotate and keep it really short.

2. Annotate for the sake of usefulness

Your wireframe design is meant to solve a problem. Your client is only concerned about how useful your wireframe design is, so make sure that you annotate with “usefulness” being the main priority.

3. Order, please!

So your client has little or no time to spend meandering around a document figuring out how the wireframe design he is looking at is going to help him out. If you got the first two best practices sorted out, then all you need to do is to ensure that you arrange everything in numerical order. From the client’s perspective, this will lead to a natural flow whereby all information can be easily assimilated.

4. Get some space

You already probably know how the natural progression is to read from left to right. So it’s natural to have your design on the left while your annotations are on the right. An example using all these 4 best practices are shown right below.

 

If you do find this post useful, please do make a comment below. We’d be more than happy to field in any questions that you may have. If you got any suggestions for topics that you would like us to cover, you are more than welcome to let us know.

Posted via email from Creately | Comment »

Part 1 : the ABCs of UML diagramming

Consider this the prequel to Part 1 and Part 2 of what I posted earlier on UML diagrams. I do believe that these posts are perfect in the sense that they would give you the “big picture” of the UML universe. I understand what was posted earlier on may have been complex to a certain degree, which is why this particular post is intended for those who are just getting their hands wet with UML diagramming. So to make it easy to “digest”, I will break this post up into two or possibly three easy-to-understand parts as well.

While earlier we spoke about the types of UML diagrams, let’s concentrate on the building blocks of UML in this post. These building blocks can be defined as (1) Things, (2) Relationships and (3) Diagrams.

(1) Things: These are known to be the most important when it comes to the building blocks of UML. They can be further divided into (a) Structural, (b) Behavioral, (c) Grouping and (d) Annotational.

STRUCTURAL

The static parts of a model are defined as structural things. The latter can be defined as conceptual and physical elements.  These structural things are defined below.

Class:

This defines an object set that possess responsibilities that are similiar.

Interface:


This indicates a set of operations that would detail the responsibility of a class.


Use case:

This is representative of a set of actions, which are performed by a system that is goal specific.

Component:

The physical part of a system is defined as this.

Node:

A node is indicated as a physical element, which usually is present during run time.

I hope this post clears up any doubts you may have had regarding the basic tools of UML diagrams. Having finished off the Structural part of UML building blocks in this post, please do stay tuned to Part 2 of this post where I will be detailing parts (b) to (d) of Things.

Posted via email from Creately | Comment »

Creately is now in Japanese & Chinese, plus we fixed some bugs!

I really hope you enjoyed the glut of posts we published, which covered UML diagrams and Org Charts, recently. You can bet we got more knowledge-based posts coming your way this week. But we just had to break up this exciting trend for some other exciting news. Remember how we told you about how Creately got faster with its response time earlier this month? Well, now we’re eager to let you know that we put in some hard work to sort out quite a few bugs, like those that are related to opening up diagrams and the behavior of connectors, for good. All this, just so you can enjoy uninterrupted, intuitive, and easy and fast diagramming with just a click or two.

And there’s more swell news. It’s just over a month since we got Creately and Creately Desktop up and running in German. Thanks to our Localization Program, we’ve got both Japanese and Chinese added onto our language portfolio as well. Of course, none of this would have been possible without the hard work put in by Tatsuya Aoyagi and Cai Ping. So, gentlemen, on behalf of the Creately team, here’s a massive THANK YOU for your support!

If you have used Creately in German, Japanese or Chinese, please do let us know your thoughts. We really would appreciate your feedback. While we’ve got Creately conversant with three global languages, we have started working on getting French, Russian and Spanish sorted as well. As a concluding note, if you know French, Russian and Spanish or any other global language and are happy to help us out, please do get in touch with us. As a token of all the support you give us with these translations, we’ll be glad to offer you some really cool freebies in return! =)

Posted via email from Creately | Comment »

Organizing for Success [3] : Map out your Organization Structure!

This is the third post in a series on organization structures. Here is a brief outline of what has been discussed so far: In the first post we discussed the simple, functional and the multidivisional organizational structures. The second post followed up with the Holding company structure, Matrix Structure & Team-based structures. Now with the final post in the series, let’s take a look at the Project-based and Network structures.

Project-based Structure

If you’re part of an organization that manages complex products; or deals with high-value industrial products and systems which support the production of goods and services, then this is the ideal structure for you.

A project-based structure is a temporary structure to which resources are assigned to work on a unique and often complex but short-term projects. You will see this type of structure commonly used in private manufacturing companies, it is also deployed in other organizations both public and private, like law firms, consultancy firms, marketing, and the film industry.

Within a project-based structure, the project is the primary business apparatus for conforming and amalgamating all the main business functions (Production, Engineering, Marketing, HR and Finance) of the organization. Because the main business processes are organized within projects rather than functional departments, this structure is an alternative to the matrix structure.

Coordination is an essential function in a project-based structure, as each worker is expected to coordinate and collaborate with other units. Also, the client plays an important role in this type of organization and is involved right throughout the project – from the project initiation to its completion.

Project_based_structure

Network Structure

This is a complicated structural type which includes the linking of many individual organizations to make their interaction effective in order to achieve a common goal. If you’re running a joint venture to build complex, technical systems like a space shuttle; or if you’re part of the network for a construction company, network structure is the best type.

These structures are more flexible and efficient because they use the best partners available that provide specific needs. However, this structure has some drawbacks as it forces you to rely overly on your partners, resulting in less managerial control.

Network_structure

Organizational structures are critical for a company and its employees. In the long run, organizational structure can spell the difference between success and failure for an organization.

If this series of posts have inspired you to re-design your organisation structure you can start right away with Creately. You don’t have to wait for your management team or HR department to re-arrange the organization structure, using Creately you can create your grand vision showing how to make your organization more streamlined and efficient and then easily share it with the management team and HR department. That’s being proactive!

If you have any comments or feedback on this series please let me know through the comments or email us.

Posted via email from Creately | Comment »

PART 1: What type of UML diagram should you be using? « Creately Blog

UML as a subject is extremely vast, which is why this particular post is divided into two different parts. While I won’t be getting into the very basic aspects of UML diagrams today, I thought it would be pertinent to elaborate on the different types of UML diagrams and what exactly they should be used for. As most diagrammers may be aware, UML diagrams are generally divided into two main categories, i.e. Structural Diagrams and Behavioural Diagrams. While this post will concentrate on the former, expect to read all about the latter tomorrow in Part 2 of this series. So if you’re a newbie when it comes to all things UML, this really is the perfect starting point for you.

All about Structural Diagrams

Basically, Structural Diagrams depict the structural elements composing a system or function. These diagrams reflect the static relationships of a structure. It is these static parts, which are represented by classes, components, objects, interfaces and also nodes. Structural diagrams are further sub-divided into four types of diagrams.

Class Diagram:

Class diagrams are what most diagrammers are used to, since they are the most common type when it comes to UML design. Class diagrams usually consist of interfaces, classes, associations and collaborations. These types of diagrams represent the object-oriented view of a system that is largely static in nature. Having said that, an active class is something that is used in a class diagram to illustrate the concurrency of a system. Generally, a class diagram highlights the object orientation of a system is the most widely used diagram when it comes to system construction.

Object Diagram:

Object diagrams are generally described as an instance of a class diagram. So object diagrams would be closer to real life scenarios when it comes to implementing a system. These diagrams consist of a set of objects and their relationships are like class diagrams and are representative of the static view of a system. The utilization of such object diagrams are similar to class diagrams, however, they are used to construct a model of a system from a perspective that is practical.

Component Diagram:

Component diagrams are representative of a set of components and their relationships. The components present in these types of diagrams consist of classes, interfaces or collaborations. So such diagrams offer the implementation view of the system. During the design phase, software artifacts of the system are placed in various groups based on their relationship to each other. These groups are called components and are basically used to visualize the implementation process.

Deployment Diagram:

Deployment diagrams would illustrate a set of nodes and their respective relationships. These nodes are described as being physical entities where the components are deployed. Deployment diagrams are used for visualizing the deployment view of a system.

So there you have it. As you can see, UML is a vast and detailed subject, which is why I’ve kept it deliberately short and simple. I hope you will tune into this space tomorrow as well for Part 2 of this series. We’ve got more exciting knowledge-based posts on diagramming coming your way next week. Please do reach out to us if you got any queries on UML or diagramming in general, the team at Creately will only be more than glad to help you out!

Posted via email from Creately | Comment »

Untitled

UML as a subject is extremely vast, which is why this particular post is divided into two different parts. While I won’t be getting into the very basic aspects of UML diagrams today, I thought it would be pertinent to elaborate on the different types of UML diagrams and what exactly they should be used for. As most diagrammers may be aware, UML diagrams are generally divided into two main categories, i.e. Structural Diagrams and Behavioural Diagrams. While this post will concentrate on the former, expect to read all about the latter tomorrow in Part 2 of this series. So if you’re a newbie when it comes to all things UML, this really is the perfect starting point for you.

All about Structural Diagrams

Basically, Structural Diagrams depict the structural elements composing a system or function. These diagrams reflect the static relationships of a structure. It is these static parts, which are represented by classes, components, objects, interfaces and also nodes. Structural diagrams are further sub-divided into four types of diagrams.

Class Diagram:

Class diagrams are what most diagrammers are used to, since they are the most common type when it comes to UML design. Class diagrams usually consist of interfaces, classes, associations and collaborations. These types of diagrams represent the object-oriented view of a system that is largely static in nature. Having said that, an active class is something that is used in a class diagram to illustrate the concurrency of a system. Generally, a class diagram highlights the object orientation of a system is the most widely used diagram when it comes to system construction.

Object Diagram:

Object diagrams are generally described as an instance of a class diagram. So object diagrams would be closer to real life scenarios when it comes to implementing a system. These diagrams consist of a set of objects and their relationships are like class diagrams and are representative of the static view of a system. The utilization of such object diagrams are similar to class diagrams, however, they are used to construct a model of a system from a perspective that is practical.

Component Diagram:

Component diagrams are representative of a set of components and their relationships. The components present in these types of diagrams consist of classes, interfaces or collaborations. So such diagrams offer the implementation view of the system. During the design phase, software artifacts of the system are placed in various groups based on their relationship to each other. These groups are called components and are basically used to visualize the implementation process.

Deployment Diagram:

Deployment diagrams would illustrate a set of nodes and their respective relationships. These nodes are described as being physical entities where the components are deployed. Deployment diagrams are used for visualizing the deployment view of a system.

So there you have it. As you can see, UML is a vast and detailed subject, which is why I’ve kept it deliberately short and simple. I hope you will tune into this space tomorrow as well for Part 2 of this series. We’ve got more exciting knowledge-based posts on diagramming coming your way next week. Please do reach out to us if you got any queries on UML or diagramming in general, the team at Creately will only be more than glad to help you out!

Posted via email from Creately | Comment »

10 common mistakes to avoid in Sequence Diagrams

When talking about UML diagrams and, in fact, sequence diagrams you will realize that attention-to-detail is mandatory. We’ve tapped the knowledge present in house to identify 10 of the most common mistakes that designers make when it comes to constructing sequence diagrams. We hope this knowledge helps you when it comes to making quality sequence diagrams. Have a run through and let us know what you think.

1. Get rid of unnecessary detail

A typical mistake that software diagrammers usually make is adding too much detail when working with sequence diagrams. Say your code has quite a few branches in a particular method; this does not mean that you should include each one within the same diagram using block or scenario elements. The issue is that adding too much detail ends up with too much clutter thereby making the diagrams more difficult to read and comprehend. The same could be said when it comes to sequence diagrams at the system level. Main thing is to keep all  your diagrams clutter-free, as shown below.

2. Messages should (more often than not) run from left to right

When it comes to sequence diagrams, the message flow should start from the top left corner. Since it’s a practice in western culture to read from the left to the right, all classifiers such as actors, classes, objects and use cases, should follow this route. However, there are certain exceptions when it comes to this logical flow, for example, when objects pairs invoke operations on each other.

3. Sequence diagrams that are obsolete and out of date

Outdated sequence diagrams that are not relevant when compared to the interfaces, actual architecture or behavior of the system, become a pain since they stop offering any documentation value. This is another reason why high-level sequence diagrams work much better than low-level diagrams. The former tends to remain appropriate even as the application details are changed. They may even need only a few modifications over time in order to remain current.

4. Avoid sequence diagrams if you are dealing with simple logic

One of the most common mistakes that most of us do is waste precious time doing too many sequence diagrams for every single use case, one for the basic course of action and one for each alternate course.  It is best to design a sequence diagram only when you have complex logic that you have to deal with. If the logic is simple and easy to assimilate, having a sequence diagram would not really add any value.

5. Provide a visual trace between the use case text and the message arrows

Each sentence within the use case text ideally should have some blank space around it. Each sentence should also be in visual harmony with the message that is in agreement with the particular behavior. This will enable people reading the diagram to easily see how the system will accomplish what the use case showcases.

6. Keep your sequence diagrams abstract without the need for plumbing

When it comes to robustness diagrams, there really is no need to show plumbing, since these diagrams reflect a design view that is preliminary. Having said that it is pertinent to highlight the real design in detail since sequence diagrams are the last stop before coding.

7.  Consider behavior allocation, seriously

As most diagrammers are aware, the sequence diagram is the main vehicle when it comes to making behavior allocation decisions. You use them to assign operations to your classes as you go. Behavior allocation especially when it comes to deciding what operations belong to what classes is very important in the ICONIX approach.

8. Include the use case text on the sequence diagram

Writing the text for the use case in the margin of the sequence diagram provides a trace from the design back to your requirements. In short, the diagram should match the narrative flow of the associated use case.

9. Follow the basics when it comes to allocating behavior by using message arrows

An object ideally should only possess a single personality. What this means is that a class should ideally focus on a set of behaviors that are strongly related. In other words, state objects need to be cohesive and coupled loosely. Other aspects that you need to concentrate on include things like reusability. What this means is that when you have objects and classes that are general, you could resuse then for other projects. Also remember that methods are assigned to objects, make sure you make it a habit to ask whether there is a decent fit between the method and object.

10. Consider the origins of the message arrows carefully

This is a no brainer. You do have to see which object is in control at whatever time so that it is easy to see the flow of control. While the arrows are certainly important when it comes to robustness diagrams, they are more important when it comes to sequence diagrams. Remember that the messages that are present between objects determines the operations on the associated classes.

Posted via email from Creately | Comment »

A comparison infographic on Visio, Smart Draw, Creately, Omnigraffle and Gliffy

Keeping in line with that proverbial cliche, “a picture is worth a thousand words”, we did a nifty infographic on five of the most well known diagramming tools out there. So find out what’s hot and what’s not below.

Tags: collaboration, competitors, diagrams, Features, Smart Draw, Visio

via creately.com

Posted via email from Creately | Comment »