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 and the consequences often devastating for the business. There has to be a better and more responsible way of developing and implementing these systems to realise the value to benefit the business.
Here are some important reasons why we would want to use a proven Formal System Methodology:
- Rationalize and streamline the current systems.
- Make it easier to operate.
- Add more desired features to it.
- Help address the problem with scarce skills and shortages thereof.
- Enhance the performance and capabilities of the system.
- Use it as a competitive weapon to reach the market sooner with new ideas, technologies and products.
- Dramatically increase information output and value from information systems.
- Create new opportunities for the business.
- Allow business maneuverability.
- Enlarge the business toolset.
- Ensure productivity.
- Ensure profitability for the Organization.
- Benefit all workers: Executives, Managers, Project Managers, Business Users, Analysts, System Architects and lastly Application Developers.
Get the Context Right
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.
System Engineering
Engineering, and the Scientific and Mathematical formalism it brings, ensures that the deliverables can be meticulously designed, architected, 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.
Work Methods and Techniques
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.
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 to be considered.
At Infomet it is not the Project Leader who is in charge, but in fact the Chief Engineer. The Project Manager is there to plan, organise, direct and control the execution of the project. 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 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
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.
Knowledge Management With QuTi
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 it's 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.
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, so 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
omplexity 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