Why the need for a Methodology

Formal engineering methodologies are needed in the work place to produce systems of quality. The engineering approach standardises a common approach between all participants so that they can communicate the requirements better and focus on the task at hand.

Systems usually cost an enormous amount of money. And while many systems development workers often do not realise the necessity for a sense of urgency, it is always top of mind with executive level management to get quality systems at a price the business can afford. Many IT related projects go south - the consequences often devastating for the business, so there has to be a better and more responsible way of developing and implementing these systems to realize the value to benefit the business.

Here are some important reasons why we would want to use a proven formal system methodology:

  • To rationalize and streamline the current systems.
  • To make it easier to operate.
  • To add more desired features to it.
  • To help address the problem with scarce skills and shortages thereof.
  • To enhance the performance and capabilities of the system.
  • Use it as a competitive weapon to get to market sooner with new ideas, technologies or products.
  • To dramatically increase information output and value from information systems.
  • To create new opportunities for the business.
  • To allow business maneuverability.
  • To enlarge the business toolset.
  • To ensure productivity.
  • To ensure profitability for the Organization.
  • To benefit all workers: Executives, Managers, Project Managers, Business Users, Analysts, System Architects and lastly Application Developers.

Get the context right


Engineering Engineering

Disciplines required to Engineer Systems

Starting from the top, one has to decide what Business Enablement Approach would be most suitable for the programme / project: Business Engineering, Business Re-engineering, Business Transformation and lastly Business Process Improvement.

..more

Once the programme is under way, various subsystems will be required to execute the programme, they are the following:

From a Systems Engineering discipline point of view:

  • Business Engineering
  • Software and Data Engineering
  • Platform Engineering

From a Project Discipline point of view:

  • Programme and Project Management
  • Knowledge Representation System
  • Quality Assurance System

Systems Engineering

Systems Engineering

Engineering, and the scientific and mathematical formalism it brings, ensures that the deliverables can be meticulously designed, architected and then precisely crafted and well manufactured. All parts are designed to work together as one unit. Highly functional and extremely capable.

The fact of the matter is that most IT Systems today are not engineered. Engineering remains a buzzword, and in some "Business Engineering" books, there is not a single trace of a formal engineering model, or any formal graphical depiction of the operation of a system. This, of course is not acceptable, but it leaves the IT Industry at a disadvantage. Formal Representation of the various aspects of a system is highly desirable, and tremendously beneficial. Some of these points are stated below:

Principles:

  • Use formal provable engineering methods.
  • They consist of comprehensive modelling techniques.
  • Speed up specification by performing concurrent modelling even during the same session.
  • The paracentric approach implied working in parallel with models towards a concentric point.
  • Usage of appropriate building blocks for designs, parts of the application and solution modules.
  • Ensure there is some automatic code generation.
  • Ensure that there is support for various automated methods.

..more

It is vital to focus the System Engineering effort on three architectural levels so that one can deal more effectively
with the different audiences:

  • Business Engineering
  • Software Engineering
  • Platform Engineering

Work Methods and Techniques


Systems Engineering Systems Engineering

Formal Models and Specifications

The solution, represented as an engineered system, needs to be formally specified. This is done through formal Engineering Methods.

The models are stored not only in drawing format, but primarily in its underlying elements and the meta data thereof will be stored in a repository, from which a number of useful information outputs can be produced composing the specifications.

..more

To represent a system at different architectural levels:

  • Business Architecture Level
  • Application Architecture Level
  • Platform Architecture Level

For the various audiences. the following work methods are typically needed:

  • Strategy Work Method
  • Function Work Method
  • Organizational Work Method
  • Data Work Method
  • Locality Work Method
  • Time Work Method
  • Object Work Method
  • Operational Work Method

Project Engineering

Project Engineering

To deliver a Project on time, within the constraints of budget, resources and logistics is indeed always the objective of a project.

However, if a Project Approach is wrong and it is not executed in the correct manner, the project will simply not meet its requirements. Rather than the project management being an instrument of autocrats, it is virally important to execute a project in such a manner that both the business priorities are met as well as the Architectural Dependencies be considered.

In Infomet it is not the Project Leader who is in charge, it is the Chief Engineer. The Project Manager is there to plan, organise, direct and control the execution of the project, but it is the Chief Engineer - The Business Solution Architect which provides the business and technical leadership to ensure that the project is delivered successfully.

Work Methods and Techniques


Project Engineering Project Engineering

Project Approaches and Know-How

Some of the aspects highlighting a different approach:

  • Configurable Project and Systems Life Cycles.
  • Project Sizing and Estimations.
  • Ring Diagram of System Dependencies.
  • Function Effect Back Tracking.
  • Paracentric Modelling Approach.
  • Joint Application Development.
  • Joint Project Leadership.
  • Knowledge Management.
  • Quality Assurance.

Training Programmes

Training Programmes

Without formal training, there is no telling what is going on in the head of a student of the hyperlink generation.

Inspired by the training approaches of the Khan Academy, Infomet re-engineered their training programmes to be more accessible, more interesting, more systematic and more effective. These on-line programmes track the student's progress through the material and reports can be extracted to monitor progress against a programme of interdependent course modules.

..more about learning and following the Khan approach.

We know that people learn differently. Critical thinkers needs to have a reason, purpose and context before they can be convinced of following the training programme with commitment. Inductive thinkers can work from theoretical models, formulae and algorithms, and proliferate the usage of knowledge in so much more than just what they have been taught. Learn-by-example students have more deductive reasoning abilities. How good they are, remains to be seen, but they need practical and worked examples to make it more tangible. Finally, Trial-and-Error learners are simply disastrous in most Engineering Programmes. The programmes need to consider the learner audience.

Some of the Khan principles are universal, yet profound, self-paced training. Mastery of parts, rather than good-enough. Progression through a logical sequence of dependent knowledge modules. Monitoring of progress, attitude and knowledge and skills development is vital to accurately ascertain where the student is in the programme.

In Infomet, we have a number of Training Programmes. They traverse through lesson sets in a particular planned order - appropriate to the requirements of the task at hand. The lessons can be taken on different levels of intensity: Novice, Intermediate and Advanced Level. In this manner, a Training Programme can be configured to cover the material at an appropriate level for the particular learner following a particular program. No need to waste more time on the detail of say for instance a Data Modelling module, if you are training a Project Manager, and just want a rudimentary coverage of the Data Modelling topics for the purpose of developing an understanding background.

..more about training programmes

The various Training Programmes cover the following:

Make reservations to attend these training programmes.

Knowledge Management With QuTi


Knowledge Management Knowledge Management

Quick Training with QuTi

In order to provide the learner a real-time training experience, the QuTi software can be downloaded to the learners desktop, laptop, or smart device. All the Reference Manuals are Available together with the related Training Material. In order to use the material, the learner must be a registered subscriber, and can then utilize the paid modules. It is not possible to download the material, but it can be viewed at anytime following a valid logon to the knowledge portal.



Totally Integrated Approach

Infomet Methodology is differentiated by the fact that it is a totally integrated Methodology which is then applied to deliver more consistent and architectural integrated solutions to the design problem.

Since its inception, Infomet noticed the discrepancies and the lack of formal and theoretical bases between the various methods and techniques that were being used in the IT industry.

Integration

Coming from an engineering and specifically an electronics engineering background, this was found to be grossly inadequate to challenge the design complexities of the Information and Application Software solutions of the time. Initially Infomet started out as a training company and because of the need to have a clear, comprehensive, easy to understand and consistent set of notations across the Methodology, the creation of the new methods and techniques of the Methodology was inevitable.

The first version of the Infomet Methodology was an astounding success, and immediately had great market acceptance. Subsequently Infomet Methodology was expanded to ensure the whole framework, Project and System Engineering became the complete package in which Infomet approached the solutions. The Metodology can be scaled to be used at a small departmental or individual user lever right up to the largest systems in corporations.

Advice From The Experts


“Architecture enables you to accommodate complexity and change. If you don't have Enterprise Architecture, your enterprise is not going to be viable in an increasingly complex and changing external environment.”
John Zackman


“The traditional mathematician recognizes and appreciates mathematical elegance when he sees it. I propose to go one step further, and to consider elegance an essential ingredient of mathematics: if it is clumsy, it is not mathematics. The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.”
Edsger Dijkstra


“Complexity has and will maintain a strong fascination for many people. It is true that we live in a complex world and strive to solve inherently complex problems, which often do require complex mechanisms. However, this should not diminish our desire for elegant solutions, which convinced by their clarity and effectiveness. Simple, elegant solutions are more effective, but they are harder to find than complex ones, and they require more time, which we too often believe to be unaffordable”
Niklaus Wirth


“Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little. “Worse yet is the rejection of upfront requirements. The basic observation is correct: requirements will change, and are hard anyway to capture at the beginning. In no way, however, does it imply the dramatic conclusion that upfront requirements are useless! What it does imply is that requirements should be subject to change, like all other artifacts on the software process”
Bertrand Meyer



Notice: Website is best viewed with browser fully supporting HTML5 (such as Chrome)
Back to Top

Infomet © 1986,1995,1997,2001,2004,2009,2011,2015    :    Intellectual Property Policy