At some point in time, in every software project we are involved in, there might be a need to create architectural diagrams. Whether we are following a formal architectural model (e.g. Kruchten 4+1, Rozanski & Woods, etc) or not, there is a need to document some parts of the application by creating diagrams. In software architecture, such diagrams are created in compliance with views which are related to a specific viewpoint that could be part of a model, but in the current article I prefer to stick to the term architectural diagram and not be very formal; all the other aspects are not intended to be covered here.
Every year Bucharest plays host to one of the most important IT&C events in Eastern Europe. Internet & Mobile World aims to build an important framework in Romanian industry for learning, networking and new business generation that reunites a B2B audience in an environment designed for sharing digital, mobile or IT software & infrastructure solutions for their businesses.
In the first part of our article we talked about goals and how to divide them based on whether we want an eventual outcome or a permanent result or effect. Now we will look at goal decomposition.
Weíve already discussed in a previous article how you can make up a list of your goals and why it is necessary. Now let us see how you can further handle that list. The first thing we have to consider is that we canít just start working in accordance with such high-level list of goals, moving from one goal to next. If you were making your list by using and combining different methods of defining goals, then it would probably become rather eclectic; the points of such a plan could (and should) be very different from one another.
A new business analyst certification system of the International Institute of Business Analysis became effective on September 30, 2016 (IIBA, International Institute of Business Analysis). In this article I would like to give an overview of the 3 existing levels.
This article goes into details of the first stage of Agile Life Planning Ė making a list of high-level life goals. We shall, step by step, consider how to define and put your aspirations, dreams and ideas on paper and then transform them into a set of clear goals which you can work with.
Agile is not only a catchword and or just a set of software development principles. I believe that agile development methods, among other things, provide a wide range of tools and excellent capabilities for managing your personal goals, personal growth and success.
In this article we will continue our analysis of the Testing Manifesto written by Samantha Laing and Karen Greaves with the next principle:
In the first part of our article we looked at the various stakeholders in the testing process as well as how each of them views the concept of quality. In this second part we will be looking at how the QA interacts with other stakeholders in the software development process.
In this article, letís consider who could be the potential stakeholders and consumers of testing services. To do that, we need to answer the following questions: