When it comes to generating more traffic for your site there is no formula as such. If you design a site that is competent and consistent, your visitors will atleast stick around and may be tell others about your site. Using Creately, we’ve done a colorful mockup along with 10 mandatory points, which can be found after the mockup, of what a good site should have.
We have a series of tutorial videos, but with the continuous developments and feature upgrades to Creately these tutorials look a tad bit outdated. So we thought of coming up with new tutorial videos to highlight some of the predominant updated features. Starting from this week, you can expect a series of video tutorials demonstrating how-to draw different kinds of diagrams with Creately.
Today, lets take a look at a simple 2-min how-to video on drawing professional Org Charts with Creately. With this, you will agree that creating Org Charts is seriously a simple affair.
We did this to help you understand some of the basic features. You can hit us back if you got any queries. We’re listening to you as always!
Today, we continue from where we left off on the topic Guidelines for UML class diagrams ~ part 1. We spoke about the relevant guidelines for General issues, Classes and Interfaces; in this post we will discuss the remaining 3.
4. Aggregation and Composition Guidelines
As it is known an object is made up of other objects. If you were to consider as examples where an airplane consists of wings, a fuselage, engines, flaps, landing gear and so on. A delivery shipment would contain one or more packages and a team consists of two or more employees. These are all examples of the concept of aggregation that illustrates “is part of” relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, highlighting an entire-part relationship that exists between two objects. Composition is a much potent form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. If you were to consider a stylistic point of view, aggregation and composition are both specializations of association where the guidelines for associations do apply.
2. Depict the whole to the left of the part
3. Apply composition to aggregates of physical items
5. Inheritance Guidelines
Inheritance models “is a” and “is like” relationships, enabling you to rather conveniently reuse data and code that already exist. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.” In addition to this, we have “pure inheritance” when “A” inherits all of the attributes and methods of “B”. The UML modeling notation for inheritance is usually depicted as a line that has a closed arrowhead, which points from the subclass right down to the superclass.
1. Plus in the sentence rule for inheritance
2. Put subclasses below superclasses
3. Ensure that you are aware of data-based inheritance
4. A subclass must inherit everything
6. Relationship GuidelinesAt this particular juncture, the term “relationships” will encompass all UML concepts such as aggregation, associations, dependencies, composition, realizations, and inheritance. In other words, if it’s a line on a UML class diagram, it can be considered as a relationship. The following guidelines could be considered as “best practices” and and effort should be made to adhere to them at all times. Figure A Figure B Figure C 1. Ensure that you model relationships horizontally 2. Collaboration means a need for a relationship 3. Model a dependency when a relationship is in transition 4. Depict similar relationships involving a common class as a tree. In Figure A you see that both Delivery and Order have a dependency on OIDGenerator. Note how the two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to reduce clutter in the diagram. 5. As a rule it is best to always indicate the multiplicity 6. Avoid a multiplicity of “*” to avoid confusion 7. Replace relationships by indicating attribute types. In Figure C you see that the customer has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects. 8. Never model implied relationships 9. Never model every single dependency 10. Center names on associations 11. Write concise association names in active voice 12. Indicate directionality to clarify an association name 13. Name unidirectional associations in the same direction 14. Word association names left-to-right 15. Indicate role names when multiple associations between two classes exist 16. Indicate role names on recursive associations 17. Make associations bi-directional only when collaboration occurs in both directions. The lives atassociation of Figure B is uni-directional. 18. Redraw inherited associations only when something changes 19. Question multiplicities involving minimums and maximums So while we have made a dent in the interesting subject that is UML design, you can surely expect more blog posts that are both interesting and compelling on the same subject. We do offer a great deal of information on UML design and would love to field in any questions or doubts that you may have.
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.
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
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…
A few months back, we gave you a heap of informative articles on UML design that started with this. If you have not read it, we do urge you to do so since it does offer a nice introduction to class diagrams, which is the focus of this post. When it comes to system construction, a class diagram is the most widely used diagram. A class diagram generally consists of interfaces, classes, associations and collaborations. Such a diagram would illustrate the object-oriented view of a system, which is static in nature. The object orientation of a system is indicated by a class diagram.
In this post we’ll discuss the numerous guidelines that are present when it comes to class diagrams. But before we dig into the details of the guidelines, it makes sense to begin by highlighting the points that are going to be covered:
Due to the extensive nature of the subject, we thought it would be apt to break this down into two parts. In this specific post, we will indicate the guidelines that will relate to the areas of General Issues, Classes and Interfaces as has been mentioned above.
Since class diagrams are used for many different purposes, such as making stakeholders aware of requirements to highlighting your detailed design, you need to apply a different style in each circumstance. This section describes style guidelines that are relevant to various types of class diagrams.
1. Show visibility only on design models
2. Assess responsibilities on domain class diagrams
3. Highlight language-dependent visibility with property strings
4. Highlight types only on design models
5. Highlight types on analysis models only when the type is an actual requirement
1. Design class diagrams should reflect language naming conventions. In the “Analysis and design version of a class” image you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDateand calculateTaxes().
1. Model association classes on analysis diagrams. The image that shows the “Modelling association classes” indicates the association classes that are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML.
2. Do not name associations that have association classes.
3. Center the dashed line of an association class.
A class is basically a template from which objects are created. Classes define attributes, information that are relevant to their instances, operations, and functionality that the objects support. Some of the more important guidelines pertinent to classes are listed down below.
2. Choose complete singular nouns over class names
3. Name operations with a strong verb
4. Name attributes with a domain-based noun
5. Do not model scaffolding code. Scaffolding code refers to the attributes and operations required to use basic functionality within your classes, such as the code required to implement relationships with other classes. The image above depicts the difference between the OrderItem class without scaffolding code
6. Never show classes with just two compartments
7. Label uncommon class compartments
8. Include an ellipsis ( … ) at the end of incomplete lists
9. List static operations/attributes before instance operations/attributes
10. List operations/attributes in decreasing visibility
11. For parameters that are objects, only list their type
12. Develop consistent method signatures
13. Avoid stereotypes implied by language naming conventions
14. Indicate exceptions in an operation’s property string. Exceptions can be indicated with a UML property string, an example of which is shown in the above image.
An interface can be defined as collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors. Interfaces are implemented, “realized” in UML parlance, by classes and components. In order to realize an interface, a class or component should use the operations and attributes that are defined by the interface. Any given class or component may use zero or more interfaces and one or more classes or components can use the same interface.
1. Interface definitions must reflect implementation language constraints. In the above image, you see that a standard class box has been used to define the interface PersistentObject (note the use of the «interface» stereotype).
2. Name interfaces according to language naming conventions
3. Apply “Lollipop” notation to indicate that a class realizes an interface
4. Define interfaces separately from your classes
5. Do not model the operations and attributes of an interface in your classes. In the above image, you’ll notice that the shipment class does not include the attributes or operations defined by the two interfaces that it realizes
6. Consider an interface to be a contract
It’s true that UML design is a vast and complicated subject that needs quite a bit of respect. While this whole subject may seem rather complex in nature, we have tried out best to simplify it, so that both professional software engineers and those who are just getting into UML design will find this whole post useful. As always, we are more than happy to field in any questions or doubts you may have. Till our concluding post, which we will release this week, keep those UML diagrams coming!
A vertical organizational structure denotes a strict top down or bottom up structure. Typically, a rigid top down vertical organizational structure has been favored for businesses and other organization types. On the other hand, a horizontal organizational structure means a flat or semi- flat organizational structure, like a meritocracy. While many do design their Org Charts with their direct reports being positioned horizontally, the right thing to do is to be aware of what your company structure is all about, i.e. vertical or horizontal before actually attempting an Org Chart. A vertical Org Chart is shown below.
Including images of staff in your Org Chart can help humanize your company intranet site, assist new employees get better acquainted, and help virtual teams that are not in close proximity to get a sense of who their co-workers are. But you really need not limit yourself to just staff pictures. If you do have an Org Chart that is rather mundane and abstract, you could infuse some liveliness and color to it but plugging in some images to highlight the type of operations as well. For instance, if you have a department called Division of Finance & Management, you could have a dollar sign image next to it. Check out how big a difference, having a picture and not having one makes below.
While Org Charts are conventionally used by HR to show the basic structure that is present in an organization, why not use such a diagram type to illustrate other types of information? For instance, you could use Color to showcase the gender balance or the different age groups present in an organization. Don’t stop there though, you could even use a colorful Org Chart to allocate staff members into different teams in the Sports Committee, to assess the number of Senior Executives present as opposed to Junior Executives or even. There really is no limit as to what you can do with organigrams, all it takes is some intuition and creativity.
Stick to these 3 tips to make your designs clear, sharp, clutter-free and offer more information. Try out these smart 3 tips on Creately for free and see how creating Org Charts is as easy as peanuts.
A while back, Indu did three amazing posts on the different types of org charts. While org charts has been the topic of focus this week, we ruminated a bit on how we could use organigrams like never before. True, we did talk about how we could use org charts in an unorthodox manner in our last post, but we wanted to push the envelope a bit further.
You see, there are various tools that are used for project management, which have had varying degrees of success but we thought – Why not form your own customized project management tool using Creately? Confused? Let’s shed some light on this compelling topic.
As our first example, consider two teams of web designers who all report to separate project managers. As a project manager, you would call/phone/email your web designer and divvy up the workload (e.g. to design a wireframe). Make sure you agree on a delivery date and a WIP date as well. Once this is done, using the collaborative features of Creately you can easily see if the tasks are being done. This way you get rid of time wastage and keep track of each team member’s progress without having to invest is a PM tool that is both expensive and is good for just one particular use. Use an organigram (as shown below) to create a customized version of a PM tool relevant to your department alone.
When inside Creately you would click on the blue icon to open up the wireframe / mockup below.
Think that this is probably just a one-off example we cracked our brains at? Think again. Let’s consider a marketing department where you are the boss. You have two executives working for you on various research projects. That big presentation is coming up soon and boy, do you need that Ansoff Matrix and PEST analysis in a hurry. Why not get your executives onto Creately and then collaborate with them. This way you would be aware of who has done what and when. Peruse the example below.
Again clicking on the blue icon, when inside Creately, will open up the PEST diagram.
The aim of this post is to help you think and use Creately from a totally different angle. All it takes is intuitiveness and some innovative thinking to use this smart app anyway you want. We’d be more than glad to offer you more exciting tips on how to use Creately. Plus we’re all eager to know what you think of how we have offered a new spin on things in this post, so please do go ahead and comment. In the meanwhile, stay tuned for some exciting posts from the rest of the Creately team soon!
Most organizations today spend thousands of dollars on business solutions to manage their business assets, but they sometimes fail to manage the most important asset – the workforce. Understanding the structure of the organization is important, understanding the roles people play, how they interact through formal and informal processes and the relationships they build are crucial to the success of any strategy.
Electrolux Home Products (EHP) as you may know is a global leader in household appliances. They are manufacturers of refrigerators, dishwashers, washing machines, vacuum cleaners, cookers and air-conditioners. It’s a Swedish multinational company that has grown through acquisitions to become a dominant player in Europe. But the European market is highly competitive and the company had to find ways to cut down on costs and improve product standards to stay ahead of fierce competition.
This is a case study of how Electrolux Home Products Europe used a functional organizational structure to compete in the European market.
Their solution was quite simple yet very strategic in nature. They introduced a Europe-wide functional structure to replace the geographical structure (resulting from its acquisitions).
The new organizational structure had four functions/departments. You can see the org chart below, which will help you visualize the breakdown of EHP’s company structure.
2. Supply Chain Management and Logistics – This function was responsible for getting the products to the customer and created the association between sales forecasts and factory production.
3. Product Businesses, Brand Management and Key Account Management – This function was involved in all the marketing activities to support products and brands. Also included key account management, service and spare parts functions.
4. Sales clusters – The different sales divisions grouped geographically.
Functional structures always allow for greater operational control at a senior level with clear definition of roles and tasks. This structure is best suited for organizations producing standardized goods and services at large volumes and low cost. Having introduced functional structures, EHP was able to improve operational efficiencies where employees became specialists within their own realm of expertise. The realignment was also helped to ensure profitable growth as the organization brought in more clarity and uniformity into business by creating more focus on areas where increased effort is required to meet the tougher challenges of the market-place.
This is a demonstration of how a functional structure has helped EHP. If you’ve been part of a functional structure or have any interesting stories to share, drop a comment here or contact us.
Source – Exploring Corporate Strategy, 7th Ed – G Johnson K Scholes R
Original Source – Adapted from The Electrolux Executive, December 2000
HR managers in companies have been using organizational charts for decades to fulfil a very basic but significant function. These managers have used org charts to form the modus operandi of a company, where questions of “Who is Who?” and “Who does What?” are answered. Organizational behavioral experts are aware of the issues that arise when lines are vague when it comes to job roles and responsibilities. Org charts need to be properly used to define the function and role of every single individual in a company so that there is room for accountability.
Additionally, you may also be aware of how org charts are used in collaboration with appraisals and job descriptions. To break it down simply, an org chart is a map as to where exactly you are in an organization. The truth here is that every company has a hierarchy of sorts, even those that claim to be a meritocracy. Paying heed to the following reasons as to why HR Managers love their org charts could help you understand your job role better.1. Delineate work responsibilities
One of the chief functions of an organigram is to clearly show the allocation of work responsibilities. As any HR Manager who is worth his salt is aware, this is one of his chief responsibilities, which if properly executed leads to the efficient functioning of the company as a whole.
Technically this point may be interlinked with the very first point. One of the many advantages of org charts is that you can break down job responsibilities into specific tasks as well. For instance, if one of your responsibilities is to conduct quarterly recruitment for executive positions, then one of the specific tasks would be to conduct an initial selection interview in keeping with the company guidelines.
Another important function of an org chart is that it helps to clarify the working relationships that exist between an Executive and a Manager. The corporate culture has evolved in varying degrees where traditional reporting lines are not adhered to anymore. For instance, you may have an HR Executive whose job responsibilities include recruitment and training, which are two separate departments. However, in this case, one executive may report to two separate managers as shown below.
Contrary to popular belief, org charts are not relevant to only the lower rung of management (think Executives and Staff Officers) but also to middle or higher management (think Managers, GMs, DCEOs and CEOs) as well. Not to sound melodramatic but using org charts for the sake of transparency could lead to less misunderstandings and friction when it comes to the sharing of power.
Whatever your position may be in a company, you are sure to have third-party interactions. Just to highlight a very basic example, if you are a new Management Trainee, you’d probably want to know who you request stationery from, who you would call if your salary gets delayed, where administration is located etc.
Considering all that has been highlighted thus far, you could get quite creative with org charts. There is no reason why you should give into a “cookie cutter” mentality and be orthodox in your ways. Coming up with innovative uses of org charts could very well help you as a HR Manager to create a better roadmap for the company, in terms of roles, responsibilities and staff interaction. Stay tuned for more goodness on org charts. Till then – Keep those diagrams beautiful!