Skip to content
Related Articles

Related Articles

Pragmatic Artifacts
  • Last Updated : 27 Jul, 2020

Pragmatic Artifacts is the conventional document-driven approach that generally squandered unbelievable amounts of engineering time simply given on development, polish, format, review, update, modify and distribute documents. It is an approach that redirects this effort of documentation to simply improve rigor and easily understanding of source of data or information. With use of smart browsing and navigation tools, it also allows an on-line review of source of the native information. This idea increases various cultural issues.

Some of them are given below.

  1. People simply want to review data or information but sometimes don’t be able to understand language of artifacts.
    Some of reviewers of a specific artifact will oppose to learn and know about engineering language in which artifact is usually written. You will find that many of people like veteran software engineers, veteran quality assurance, etc. will deny to learn language and will only say that “ I don’t want to learn and know about Unified Modeling Language (UML), but I will rather review software design, so just give me a separate description like flowcharts and text that I can understand in an easy way.”
  2. People who want to review data or information don’t have any access to tools required.
    Unavailability of tools is very common in development organization. These organizations are not fully completed with tools. It is very rare and sometimes nearly impossible to find out stakeholders that have potential and ability to review engineering artifacts on-line. Even though, these organizations are also forced to exchange and share paper documents with each other. Nowadays, it is very convenient and easy for all stakeholders to exchange and share information electronically using standardized formats like Unified Modeling Language (UML), spreadsheets, C++, etc. visualization tools, and Web.

  3. Human-readable engineering artifacts must take use of rigorous notations that are fully complete, consistent, and are used in a self-documenting manner.
    • For all identifies and descriptions, we should use Good grammar, correct English words that are spelled properly.
    • Usage of abbreviations and acronyms should be avoided and it should be used only when they are acceptable in context of usage of components.
    • The code should be self-documenting.
    • The main emphasis should be on readability even proper grammar words should be used in all engineering artifacts.

    All these practices will allow representations to be easy and understandable, browsable formats, more-rigorous notations, and also minimize rate of errors occurring.

  4. Documentation that is useful is self-defining.
    These are the documents that generally are very useful and get used.

  5. Paper is tangible.
    It is very easy to change to electronic artifacts. Even it is very easy and simple to change on-line and web-based artifacts. They are also viewed with high skepticism. This is due to their inherent volatility.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

My Personal Notes arrow_drop_up
Recommended Articles
Page :