CorpIT has partnered with CRaG Systems (UK), which has successfully trained and mentored a large amount of analysts, architects, project managers and programmers from a number of Fortune 500 companies since 1992.
CorpIT provides extensive training in the UML notation together with a pragmatic approach to developing business process models, system requirements specifications and analysis and design models of complex object-oriented, distributed web, client-server, or real-time embedded, project management, component-based systems.
"We want people to have a practical application of UML and the case studies enable the students to gain that," says Wayne Hart, MD of CorpIT.
"UML is key to future software development and is as fundamental as knowing a programming language. Up to now, SA has lagged behind other countries in offering quality training on UML but our partnership with CRaG Systems (UK) will raise the availability as well as the standard of UML training," concludes Hart.
Why use UML?
Software construction needs a plan: There is a common perception among general management that software is both cheap to produce and easy to change. "It`s only a bit of software - it won`t take you long."
Developers know that this is not true. Software is extremely complex and, once a particular structure is in place, often a long-winded difficulty to change. An architect knows this and creates a drawing of the building from more than one direction, ensuring the structure is appropriate for the purpose of the building and the dimensions are all consistent. Only when this visual model of the proposed work has been approved is the job of laying bricks begun.
Visualise in multiple dimensions and levels of detail: Software is very abstract and hard to visualise. A visual modelling language, such as UML, allows software to be visualised in multiple dimension, so that a computer system can be completely understood before construction begins. Furthermore, UML can be used to produce several models at increasing levels of detail. The overall scope of the software can quickly and easily be defined at the start of the project with a high level model allowing for accurate estimation. Increasing levels of detail can then be added to each part of the software as it is constructed, until finally the software appears as code. The code can then be tested against a test model that is derived from the original model of requirements.
Inherent traceability: The use-case-driven nature of modelling with UML ensures all levels of model trace back to elements of the original functional requirements. This traceability between models comes without the extra effort creating and maintaining a `traceability matrix` which can be a complex and time-consuming job.
The result is that the impact of a requested change can quickly be estimated. A change in requirements can be traced though analysis and design models into those components affected and even lines of code. The code affected can then be traced back to the requirements and total regression testing effort calculated.
Document software assets: Undocumented or badly documented software has a reduced value as a company asset. With so much of the company`s business process embedded in obtuse software code, a company is vulnerable to losing an understanding of and control over the business rules by which it operates. Gradual re-engineering of the company`s bespoke computer software in a way that makes the functionality of the software transparent, brings those important assets back under control. It removes the company from dependence on key personnel who may leave at any time and improves understanding of the company`s critical business processes. It even improves the quality of software engineering staff because those who want to do a proper job will look for companies that model with UML.
Share