Archives

Someone will ask: why all this? The thing is that managing presentation graphics (model consistency, tracing, etc.) is practically impossible: any change requires interference with block diagrams and laborious reinsertion into the analysis report (I wrote about this in an article about CASE tools). Such graphics are not transferable between tools other than as uneditable bitmaps. However, if someone feels that block diagrams expressed in more ‘friendly’ symbols add value to the project, they can do so. The UML provides for this and many tools allow it (I used Visual-Paradigm).

Source: UML model and stereotypes as icons – Jarosław Żeliński IT-Consulting.

There are also simple and obvious conclusions:

• there is no point in designing an “information system” without fully understanding (i.e. also documenting) the “information system, “
• there is no point in placing the elements of the “information system” on “information system” models (e.g. There is no point in putting the “information system” elements on “information system” models (e.g. symbols representing software on BPMN models)
• the relationships between the “information system” elements and the “information system” elements are described with the help of the traceability matrix
• Developing the requirements for the “information system” is about identifying the “business needs” and developing the logic of operation and architecture of the “information system” on their basis (MBSE, MDD), and not on collecting mythical “user requirements”, who in fact have no idea about “information systems”, but know very well if and when they need help in the business processes being implemented  this is why methods based on designing an “information system” on the basis of interviews (workshops) with future users are doomed to failure from the outset (because even if something sensible is finally created, it will take a lot of trial-and-error work)
• One thing we have known for years: one of the most damaging theses in IT is the one saying that a document is a report from a database.

Source: Architektura informacji, system informacyjny a informatyczny w organizacji – Jarosław Żeliński IT-Consulting

UML diagrams and the way they are used, since the very beginning of this notation, have aroused emotions and waves of conflicting comments. The reason for this is the high level of abstraction of the analysis stage and modelling as a discipline, and the fairly widespread misunderstanding of the essence of this notation. This is compounded by the huge difference between what we call analysis and object-oriented design (OOAD) and object-oriented programming languages (OOP).UML notation is mistakenly treated by many people as just another set of symbols for creating illustrations. Most developers I know feel that these diagrams do nothing to help them, and they are generally right, because the quality and content of much of the documentation produced with UML, is poor, and such documentation is actually useless to the software vendor.

Source: Diagramy w notacji UML – Jarosław Żeliński IT-Consulting

The acronym VSM has also started to appear in software engineering for some time now, but it has an old pedigree of more than 30 years. Value-stream Mapping (VSM), known for 30 years, more recently also as material- and information-flow mapping. It is a method with its origins in Lean Management, used to analyse the current state and design the future state for the series of events that lead a product or service from order to delivery to the customer.

Source: Value-stream mapping czyli strumień wartości jaki wytwarza firma tworząc swój produkt – Jarosław Żeliński IT-Consulting

Testing is checking, and here we have (should have) a clear division between the checker and the checked. It is typical of the IT market to tell customers that they have no competence in analysis, testing, design, that all this will be done by the software supplier. Thus, the following are ordered from the same, single, software supplier: business analysis, requirements analysis, design, implementation, writing acceptance tests and testing. An entity like the Purchaser in essence just watches, and pays as much as the suppliers want (T&M projects are out of control). In effect, the checker and checked are the same entity. Does this make sense?

Source: Czym są testy oraz kto i co testuje – Jarosław Żeliński IT-Consulting