ÉVALUATEUR
Evaluation of load
Negotiation of functionalities
Environment Optimisation
Jean-Pierre Vickoff, RAD.fr
English translation graciously realized by
&
ÉVALUATEUR - Evaluation de charge, négociation de fonctionnalités, optimisation d’environnement 1
1.Evaluation of multiple parameters
The productÉvaluateur takes into consideration the complete problem of a project based on its methodological, technological, organisational and human aspects, in order to:- Estimate the development load;
- Negotiate the execution of functionality;
- Evaluate the performance of the environment in order to optimise it.
- Determines a number of technical elements to be created (Measurement);
- Takes into account the balancing factors linked to the environment (Effort);
- Estimates the volume in days (Load) and the duration of the work to be executed (Time) as a function of the resources.
Basic evaluation principles
Évaluateur covers more than 60 parameters which have immediate contextual help and are divided into 12 groups (tabs). As soon as the application components are entered, the information regarding measurement, effort and load appear in the "immediate results bar (figure1).
Figure 1. — Évaluateur, immediate results bar
The concept of Measurement[2] is proportional to the number of elements and their complexity.
The concept of Effort[3] takes into account the parameters representative of the performance of the environment.
The number of Days represents a workload based on the effort and integrates the "proficiency of resources[4]" variable.
A "Threshold Effect" indicator is located between the effort and number of days. The change in its colour (from lightest to darkest) is a sign of significant increase in resources or time (thereby affecting the costs and risks).
The threshold effect is linked to the load as against the optimal productivity of a team within a fixed time.
Tab 1 – Application measurement
Figure 2. — Tab 1 : Measuring the application
The first and most important part of the work lies in taking a census and estimation (number, level of complexity) of the elements comprising the application. To fill the Measurement tab, it is necessary to have a minimum idea of the application size and its complexity. Following are the stages of this search:
- Start by looking for number of distinct elements which make up the user discourse. You will find "objects" (data and associated processes). This stage will lead to a first estimate of Tables and relations. By observing the supporting documents for this information, you will get a relative idea of their importance (simple, average, complex). Do not neglect the relations having N type cardinalities, they generate complexity and should be considered as simple tables.
- Always through the user discourse, determine the management or organisational rules, as well as the processes to be executed (if possible, as a hierarchy of functions). Then count a Screen (Windows or HTML) per element thus surveyed and a Process (Business Process) for each element whose application complexity (functional or technical) is obvious.
- The number of Reports and Interfaces is then generally easier to circumvent, usually by studying the flowmodel.
- For decision making applications or maintenance of applications, do not count the existing components but only those which will be added or modified. In this case, only evaluate the complexity of the modification.
Other than forgetting a known element, the main risk lies in the possible increase of the requirements during Framing or Design. The role of the experienced RAD leader is to get a reliable and stable initial estimate at the time for getting into the functional area; then refine the planning at the end of each phase.
1.1Tables and Relations (data layer)
- A simple (defined or modified) entity (table) comprises a maximum of a dozen attributes. Add the tables resulting from N type of cardinalities here.
- An entity (table) having average complexity comprises around over ten attributes, foreign keys and referential integrity management.
- A complex entity (table) comprises more than 10 attributes, many foreign keys and implies catalogued triggers and procedures.
- Windows type Screens (presentation layer)
- A Window screen comprises:
- 5 to 6 objects (over and above the standard controls),
- simple procedures (the kinematics of standard screen, search actions, reading, creation, update) and data access are included in the concept of screen.
To take into account an exceptional ergonomic complexity with few objects, use "average or complex" type of screen.
- A Windows screen with average complexity includes less than a dozen objects + standard controls + standard procedures.
Any form of actual application complexity should be listed in the layer "Processes/Rules of the Profession".
- A complex type of Windows screen includes more than 12 objects, "custom controls" and complex procedures.
- NET (D)HTML type of screens (presentation layer)
- A simple (D)HTML screen includes HTML code without access to data. The textual and ergonomic content are fixed.
- An average (D)HTML screen includes a dynamic visualisation of data or simple objects or an unstable content.
- A complex (D)HTML screen includes HTML code encapsulating various types of objects and access to data from various sources.
- Processes / Rules of the Profession (application layer)
- A simple process includes programming management rule or seemingly simple calculations (which corresponds to less than half days test coding and generally results in less than one page of code, that is approximately 50 lines including the comments).
- An average process includes programming management rule or seemingly average calculations (which corresponds to at least one day of test coding and generally results in 2-3 pages of code).
- A complex process includes programming management rule or seemingly complex calculations (which corresponds to more than one day of test coding and generally results in more than 3 pages of code). Divided into many elements if required.
- Conventional and various outside reports
- A simple report is in "list" style with simple restriction, sorting and one or two cumulated fields.
- A report with average complexity comprises many break levels and requires joins between various implied tables.
- A complex report comprises many breaks, joins, restrictions and calculations.
- Interfaces (other applications, directories, third parties, etc.)
- An interface (internal or external) with simple complexity has a repatriation style reference table (simple access). Process the conversions and data resumption tasks as interfaces.
- An interface with average complexity includes many fields (average complexity access). Here process standard directory management and third party access (certifiers, payers, etc.) or with average complexity.
- An complex interface (internal or external) includes many fields and requires verification of referential integrity. Here process complex management of directories and difficult access of third parties (certifiers, payers, etc.).
- Help for controlling work for a small NET project (or part of a project)
- Indicate the number of structurally different HTML pages (99 maximum) which you will assist in developing (with regards to content: text, graphics, ergonomics). Use this option to estimate a small NET project with simple WEB site presentation. Indicate the STRUCTURALLY different and manually programmed pages.
Tab 2 – Application, Organisation
Figure 3. — Tab 2 : Quality and organisation
2.1 Application Level (management rules, complexity)
The application difficulty either corresponds to the number and complexity of the management rules or to the sophistication of the request. For this parameter, take into account global complexity and not the presence of particularly complex management rules, but isolated one which are defined in tab -1- Measurements "processes, rules of trade, application layers".
This is a subjective evaluation of the complexity, in fact it corresponds to one's own way of seeing a problem. For some people a precise problem is complex whereas for a person having knowledge or experience to resolve the problem it is not so. For this reason, it is desirable that the computer expert in charge of evaluation considers the application complexity with regard to the reasonable farsight of the global nature of the team responsible for the development. RAD recommends within the SWAT framework that the evaluation should be carried out by the planning resource person or using a collegial approach to the execution obligations.
2.2 Required Standardisation (standards)
Some types of applications (isolated and with a short life span for example) demand a high level of standardisation which is a costly choice and without any economic returns. Standardisation, respect for standards has a considerable cost which must be modulated according to ROI and life-span of the application.
A developer accustomed to systematically respect development standards will be able to implement them without loss of time for any size of application. On the other hand, the work of a developer devoid of such natural reflexes has to undergo many checks and corrections.
2.3 Search for reusability (objects)
A choice has to be made between fast development by following strategic constraints of time or cost and investing in reusable objects.
The development of objects or components which ultimately have a reusable form is a technical as well as an economical choice. The downside of the modelling the upper layer which has to be defined, as well as the high level of abstraction which is necessary for design, is a prohibitive cost of development (except if it has been planned and justified generally as part of a long term strategy).
2.4 User documentation quality
Contextual documentation is the best. Paper should be conserved for general principles. The quality level of user documentation is a choice which has to be technically and economically justified. Quality and simplicity are indispensable if the user is a beginner. Brevity and thoroughness with respect to complex problems are essential if the user is an expert in the field.
Level and type of user documentation is the job of a specialist. Generally developers are bad "documentalists". Therefore it is desirable to use specialists in this field. Another option is to have the application specifications written from the view point of a user documentation by a task supervision reporter working in tandem with an experienced leader. In this case, the advantages in terms of budget are simultaneous and immediate validation of specifications and an adapted documentation.
2.5 Stability of specifications (or reliability)
Generally the operational applications have relatively stable specifications and decision making help applications have fluctuating specifications.
Stabilisation of specifications is one of the key elements for successful and working development. The proficiency of the leader at this point is crucial, specifically when the requirements are linked to difficult interpersonal relations. The role of the leader (neutral) therefore is to identify the change cost in terms of time and budget for each modification. Generally, the realisation of the interlocutors faced with regular and systematic figures, leads to a consensus rather quickly.
2.6 Organisational culture
- Large or administrative or "standardised" organisation
- Average or relatively flexible organisation
- Small company or evolving organisation or SSCI
- "High performance" or individual activity project mode
The organisational culture of the organisation in charge of development is the most important point in terms of evaluation. Many studies have shown varying development time from 1 to 50. This point alone represents the entire problem of evaluation.
2.7 Project administration (in %)
15 % to 20 % of the global effort is standard for transverse tasks (progress management, meetings, quality etc.). 5 % to 10 % RAD. The time spent for the administration of the project can vary with a ratio of 5% to over 30% based on the requirements of managing authorities. In the case of Évaluateur this aspect mainly covers the time spent on organisation, recruitment, planning, follow-up of resource usage, navigation, production of navigation reports and possible technical committees for follow up or navigation. The time spent on technical and functional aspects are excluded (for example, the preparation and execution of Focus).
The planning and layout of resource usage is the basis of an efficient project management. Even though the RAD projects lead to short cycles as against traditional development, follow up requires a lot of attention and the use of a specialised tool. It should allow for easy management right up to the finest detail (task/time). It automatically provides fairly complete progress reports to satisfy the management who has to learn to be satisfied with main points.
Tab 3 – Design / Screen
Figure 4. — Tab 3 : modelling and architecture
3.1 Modelling level
- Simple HTML non applicable modelling
- Entity-Relation data only
- E-R + Flux (SASD, Gane-Sarson, etc.)
- E-R + Flux + Detailed processes
- Total object modelling OMT/UML
The modelling level should be adapted to the type of application. For example it is useless and disproportionate to implement a Merisien modelling approach for simple decision making application requiring only the definition of a structuring level of formerly existing data.
A powerful environment[5] has tools such as AMC*Designor, Rose, etc. An average environment corresponds to ownership tools. RAD requires most powerful tools for optimal on line designing.
3.2 Modeller knows the functional environment
At the design level, and specifically for decision-making or strategic kind, the Merisian processing models are replaced with the principle of function hierarchy. (If the parameter is not applicable, choose the option "Perfectly").
When a computer scientist has functional expertise and when he has already modelled an application class, it is much easier for him to create a new model perfectly adaptable to the specific case making use of the strong points, details and exceptions based on his earlier experience.
3.3 Design architecture "with modification possibilities"
This architecture gives a permanent delivery status and allows execution of evolving applications. Its conception with modification possibility requires knowledge of many additional techniques which are generally found in surrounding objects. The design architecture with modification possibilities is based on technical objects: dissimulation, modular approach, abstraction, encapsulation, cohesion, coupling, hierarchy, inheritance, polymorphism, algorithmic, structuring (processes and data).
This development option represents the strictness and an investment which becomes profitable due to resulting ease of modification. The justification of this investment therefore implies a type of application with minimum life-span or a strategic type of application requiring high degree of immediate adaptation capability.
3.4 The technical documentation produced by AGL (design) is sufficient
The analytical documentation should be completely managed by the design AGL and should be considered as sufficient[6]. Reply:
- YES if automatic creation by AGL is sufficient for technical needs(generally for maintenance);
- NO if you need to manually create a design documentation to satisfy differing needs (which has to be justified ROI on selection).
The only objective of the technical documentation is to simplify the development and maintenance which is its natural extension. Many forms of technical documentation can be differentiated :
- Framing documentation (specification) generally includes the specifications and various documents in a textual format required to simplify the understanding of requirements.
- Design documentation (conception) includes the data, processes and communication models in a graphic format. This information should necessarily be managed in a specialised AGL which allows automatic generation of reports in textual format using the graphic expression of models.
- The Construction (coding) documentation should henceforth imperatively take care of the peculiarities of the "Windows" mode which distributes parts of the code in each event of each IHM object. To actually use this documentation, it should be completely integrated into the code it describes and structured at the application, module, object and event levels.
3.5 Reuse existing functional item (%)
This existing item can be an old application, a data model from another application or the contents of HTML pages in DOC format. ( In this case, if the contents of the pages are negotiated and composed, choose option "0" (zero) for this parameter).
During remodelling of an application, study the existing functional part. When it is satisfactory (quality, thoroughness) and updated, it allows an appreciable saving of time and avoids numerous trials or errors. In the case of a new application, it is desirable to benchmark.
3.6 Target application resolution
The TARGET resolution determines the development resolution. This aspect sets up the ergonomics of the application and the comfort level and productivity of the users. In terms of return on investments, it is the cornerstone of decision.
Figure 5. — Optimisation resolution / screen size
3.7 Development resolution
The development resolution allows for simultaneous display of target screen and tool box. This possibility governs the development performance. To develop an application professionally in VGA mode requires at least a 1024*768 resolution and a 17" screen. If the target application is SVGA, the development resolution should be XGA applicable to a 20" or 21" screen. Many research studies show the short term profitability (2-3 months) using high resolution and appropriate screen pair.
Tab 4 – Method, Quality, Focus
Figure 6. — Tab 4 : Method and organisational group
4.1 Method / efficiency
In this field, the Évaluateur references are:
- RAD (semi iterative cycle) or DSDM, RUP, Iteor (fully iterative cycle) with modelling form adapted to the problem (Object, Flux, Merise "light"),
- Merise with its usual life cycle and typical modelling,
- SDM/S (cascade cycle usually associated with a Merisian modelling in France).
To locate them on a standardised scale Évaluateur indexes the practices implemented by these methods based on the 5 CMM[7] levels or SPICE: