Information Technology II Kuppi (IS +costX tutorial).pdf

by: Dulshan Costa 1 Information Technology II  What is information System? A system that converts Data into Information. Data Information System Information  Content of the information System...

by: Dulshan Costa 1 Information Technology II  What is information System? A system that converts Data into Information. Data Information System Information  Content of the information System User Interface Program Information System by: Dulshan Costa 2  Why QS/FM need knowledge IT specifically for system development? QS/FM are acted as Clients (Owners) & Users of information system.  As specialists QS/FM know what exact we want.  So we need to supply information to system developers in order to help to develop the system  To understand what developers are doing in developing stages.  To effectively play a supportive role with system developers.  As the Client QS/FM has power to control the System development.  Why build information system? As a solution for problem. Ex:  To convert manual works to automatic works.  To reduce repetitive works in order to save time and reduce errors.  Who is System Analyst (SA) and what does he do?  Building project Architect = System development project System Analyst  System analyst is the person do brain surgery of the client. (To get a better idea of what is actually in the mind of the client).  SA determines what client really need (identify Scope of the project).  Identify needs for new system.  Supports to come up with new information system.  Makes solution for existing problem.  SA takes great responsibility since system development is complex and cost same as a building project. by: Dulshan Costa 3  Types of customers who needs information system Companies that don’t have information Companies that have information system system development corporate plan. development corporate plan.  Fire Fighting type people.  Bigger corporate companies which have  Customers with current problems 3-5 year system corporate development (Failed in manual or existing system) plan.  Majority of customers are like this.  They have internal information system  Not have enough resources to have and development department within the operate information system development company. corporate plan.  Have integrated systems.  They are panicked and need immediate solution from SA.  Need isolated solution.  Benefits of having a Systematic approach to system Analysis  Ensure Quality.  Better Management control of the Information System Development. Better communication with = Better management control of the information system Other sub systems development If don’t have system development corporate plan [Fire-fighting]  Computer hardware is not shared. Sub X Sub system 1  Data is not shared. Isolated system 1  Sub-systems will developed separately, (No communication) may be by different developers as 2 separate systems. If have a system development corporate plan  Computer hardware is shared. Sub  Sub system 1  Data is shared. Integrated system 1  Integrated sub-systems. (Interconnected (All sub-systems will be interconnected). Communication) by: Dulshan Costa 4 Ex: Enterprise Resource Planning Systems. (ERP) If Mr. Ezio is the PM of a Tendering project. (1 year project) Tender HR System System Salary PM’s Salary Ezio’s Salary 200,000 x 12 200,000 x 12 Mr. Ezio promoted recently and increased monthly salary up to 240,000/= It will be updated in HR system. Since 2 sub-systems are integrated the tender system will automatically updated. Tender HR System System Salary PM’s Salary Ezio’s Salary 200,000 x 12 240,000 x 12 240,000 x 12  Ensures better User Satisfaction.  by: Dulshan Costa 5 Traditional method of developing Information System (Steps of System Analysis) 1. System project selection. Software Development Life 2. Feasibility study. 3. Project planning. 4. Definition phase. Important of knowing this 5. Design phase. as QS/FM to be corporate Cycle (SDLC) 6. Build/buy analysis. with system developers, especially for discussions. 7. Implementation phase. 8. Post-implementation review & Evaluation. 9. Maintenance & Enhancement.  The study will Outline and Define the Range of Skills needed by the System Analyst.  Will know when and what Expertise to acquire based on Project Needs.  Why system strategy is needed?(Appraches) To be successful one should have a Systems Strategy in Developing an Information System. A good Systems Strategy should fulfil following requirements:  Should be approached as a Whole [Organization’s System Development]. Ex: If a company has many departments. Company Department Department Department Department Department Department Department 01 02 03 04 05 06 07 Technical Technical Technical Technical Technical Technical Technical Division Division Division Division Division Division Division The information Financial Financial Financial Financial Financial Financial Financial Division Division Division Division Division Division Division system must cater information needs of HR Division HR Division HR Division HR Division HR Division HR Division HR Division all departments. Procurement Procurement Procurement Procurement Procurement Procurement Procurement Division Division Division Division Division Division Division Marketing Marketing Marketing Marketing Marketing Marketing Marketing Division Division Division Division Division Division Division එන්නෙ හැම Department එකටම sub-system එක ගානන් හදල නදන්ෙ. ඒත් priority එක අනුව වරකට sub-system එක ගානන් develop කරෙවා.  Helps to Avoid ……….! : Duplication/Over stretching of Resources /Incompatibility Between data.  Development should take place within the framework of the of an overall system strategy.  Integral part of the overall system development. by: Dulshan Costa 6  Elements of Good System Strategy. A. User Priorities B. Systems integration C. Resource availability Why? Why?  Determines what can be  Balancing priorities is  Different Information done to meet established difficult. systems using same data / user priorities.  Many Users and complex Common Data.  Parallel development of requirements.  Data Sharing / several information  Rational approach is to Application systems may be costly, relate user requirements Convergence and complex and project to goals of the company. Common Databases. management very  Reach agreement on  IF one adheres to the difficult. (Resource priorities among various concept during system planning) users. development payoffs  Complexity of the tasks Ex: come when integrated increases with number of  Developing which with other systems or dependencies between sub-system will give when new systems are information systems. the highest return on designed with existing (Resource smoothing investment. data. (Separate  Which sub-system development is awful) will enhance the customer Things need to be done under satisfaction. System integration. එක එක aspect එක අනුව  Use Consistent data මුලින් develop කරන්ෙ ඕෙෑ definitions. sub-system එකට priority එක  Consideration of all නදෙවා. possible users.  Checks during analysis  Failing, involve senior and design if local data management to reflect has implications on other real needs of the information systems. organization and avoid  Technical environment Skillful user pressures. should be able to support  Can be for various and sustain it. purposes.  Hardware / Software  A personnel [Databases]/ Data pension scheme. Communication  Stock Control. Facilities Should allow  Sales Statistics. the Integration.  Technical Environment to be planned in relation to necessary applications allowing a systems architecture.(pipeline) by: Dulshan Costa 7  Facilitate Open systems which enables to connect different types of hardware and software based on standard interfaces and functions specifically at the operating system level.(Plugins/VGA acceleration) System Strategy should ensure that separate developments today will bring strategic benefits in the long run and not problems to the organization when integrated together in future. (Should be incorporated in long term and medium term plans too.) To Implement the Strategy One should come up with System Plans for the Total Company. Benefits of System Planning  Forces System  Provides a  Acts as reference Developers and rational basis for framework for users to the budgeting and progress as well project to think human resource as for new beyond planning. proposals. immediate actions, needs and priorities. (Think outside the Box)  A long-term System Plan must be do for 3-5 years.  Beyond 5 year uncertain to do a realistic plan.  The period up to 3 years is operation planning –Rolling plan [Updated on a regular basis].  Contents of long-term system plan [ 3-5 year]: o An Executive Summary. o A review of the current status and progress. o Objectives to be achieved in the coming 5 years. o Strategic principles to be followed. o The main line of actions identifying main projects and activities. by: Dulshan Costa 8  The 5 year plan can be break into 3 year plan for further clarifications. (What will be done within first 3 years of the 5 year plan). o Translates the 3-5 long term plan into Blue print of actions immediately ahead. o Contents of 3 year plan for 5 year plan:  How it relates to the five year plan.  Combined plan of projects.  Project by project summaries.  Resource allocations required.  Operational system plan. (It is the basis for management control of ongoing and new system development in the year ahead.) System planning summary 5 Year Plan 3 Year Plan Operational System Plan by: Dulshan Costa 9 Development Approaches (Methodologies) to System Analysis in Building Information Systems  Objectives of System analysis  Providing a solution to a business problem.  Achievement of a business goal.  Improvement of a business process by creation of a series of interdependent procedures which may be regarded as a functional set or system. Approach Known as a Methodology: ordered set of ideas or procedures or guidelines that have been used to go about developing an Information System. Early 1. Accurately Defined systems (ADS): Output of a system: Methodologies 2. Study Organization Plan (SOP): Documentation Intensive risk minimizing Plan :IBM 3. Business Information Systems Analysis and Design [BISAD]: Early top down approach to the study of information needs of an organization Honeywell: 1970’s. 4. Computer manufactures sponsored approaches : [Entire Org / Specific Application Systems] o NCC National Computing Centre o Philips ARDI Approach Traditional Multi phased Approach Methodologies  Formalized check list of tasks for the phase. Approach  Each phase has one or more techniques [Flow charting].  Formal reviews in between.  Extensive documentation [Separately after the work has been done].  Generally approach has survived [Design is top down rather than Sequential]. Modern i. Structured Approach. ii. Data Centered Approach. Approaches iii. Prototype Approach.  by: Dulshan Costa 10 Modern Approaches i. Structured Approach.  Relates to Disciplines and transactions from the field of data processing  Initially applied to programming aspects only  Extended to whole field of system development  Major Characteristics: Top down Functional Decomposition Analysis takes place from macro level to a micro level in a series of iterations which progressively study ever smaller parts of the whole in increasing detail.  Having a Big Problem  If the problem is too big to handle, break it into small tasks. 1 Big More Problem Smaller Problems Because finding solution for smaller problem is easy. Finding solutions for small problems and connect the solutions together (Integrate Solutions) = Solution for the Big Problem  Separation of Logical aspects from Physical Implementation.  Documentation is an integral part of the systems development process [Immediate and Kept more up to date rigorously].  Process Centered Approach [What the system has to achieve].  by: Dulshan Costa 11 ii. Data Centered Approach. (database)  Third General Family of system Development.  James Martin Principal Advocate.  Builds on Basic premise that Data within an organization is stable and procedures which it is subjected to.  Data: Things about which an organization keeps information called entities.  Data and relationships between them are given the central Importance.  Data is treated as a separate resource and process becomes means of transferring data.  Design of the database become very critical in this approach.  Should be to the complete organization not a single application. iii. Prototyping Approach.  Construction of a Prototype system.  User and Systems designer users interactive computing.  Assumptions: o Users do not know what they want. o If they do, they do not describe it to the system developers. o With a proto type users can see it grow and recommend changes to which are incorporated with minimum fuss or formality.  User and Analyst satisfied with the prototype.  Becomes working specification [Final system / Upgraded to production status].  High level programming languages.  Where all databases are designed and created during the prototyping.  Construction of prototype system.  Very very innovative information system  We come up with prototype model & show it to the users whether it is good.  Users suggests changes & interact with users.  Made changes to prototype. by: Dulshan Costa 12  Selecting a suitable approach to system analysis Based on characteristics Traditional Approach Structured Approach Data Centered Approach  Rigid /Time consuming/  Documentation.  Heavy front end loading Documentation.  Can be used across a [Cost and Time]. complete organization.  Long period of study.  Systems with low risk.  Same Apparent  Once front end is done  State of the art but not emphasis given to Major more rapid new pioneering systems. and minor processes. developments than in the structured approach.  Central and big computer orientation. Considering all the characteristics of different approaches, it can be concluded that Hybrid Approach is the best.  Joining [Coherent]: linking: Hybrid.  Structured/ Data Centered / Prototype: Not easy: To be successful: o Modify some of the conventions usually employed in Structured Approach. o Rethink the scope in Data centered. o Prototype as a technique in the system definition phase. Development Approach High Volume Data Processing Structured Batch / On-line new or re-development Dev of Centralized suite of integrated Data Driven applications Dev of data retrieval-type App Data Driven New Dev No Previous Computerization Proto type User Requirements unclear  by: Dulshan Costa 13 09 broad steps of system analysis (Traditional Approach) 1. System project selection. (Company එකට software එකක් ඕෙෑමද? ඒ ඇයි?) 2. Feasibility study. (ඒ විදිනහේ software එකක් හදන්ෙ පුළුවන්ද?) 3. Project planning. ( Deciding Milestones, Risk & Resources Planning) 4. Definition phase. (Break main objectives to Sub & Sub-sub objectives) 5. Design phase. (design software according to system design principles) 6. Build/buy analysis. (decide whether build the software or buy available software) 7. Implementation phase. (actually making software) 8. Post-implementation review & Evaluation. (Feedback for software) 9. Maintenance & Enhancement. (Update & Upgrade software) 1. System project selection.  Sometimes the SA is not involved or does not take a significant part in this stage.  Gets involved when the decision has been made by the system owners.  Every system has gone through.  System Analysis function begins when an area is identified for study. Reasons for initiating system project Selection I. Best for one Dept. May not be the best for another Dept.  Avoid Conflicts and Duplications.  Confusion and Extra work. o Accounts / purchasing/ production. II. Results from previous studies.  End of the day better ideas of the just completed job.  Possibilities of new developments that came up during the current development. o Eg: Production personnel Schedule jobs to run on machines And Machine Maintenance Dept. [Record and do it when machines are not scheduled to use]. III. Possibilities for linking or integrating with other systems  Logical linkages when implemented becomes valuable to the organization. o Eg: Missing system that facilitates linking of two other important systems. IV. Opportunities created by new hardware, software or techniques  New development has made way for a new easy Approach to an existing business problem.  System analyst should be careful of not selecting “Clever Systems”.  Remember that other technical advances are coming.  by: Dulshan Costa 14 V. Outside Sources  Think outside the box: Systems based on their experience and needs within the own organization: Mistake.  Organization needs are rarely unique and exchange of ideas with outside leads to new ideas and solutions. Desired project list maintained. Factors to be considered in System Project Selection (SPS) SPS Selection Criteria Experience counts and the Judgment needs to be Confirmed. 1. Potential return on investment.  Consider Benefits and Costs:  Strong guide for desirability of implementation. 2. Critical Company Need?  Urgent need in a particular area.  Financial justification may be unclear.  Need felt strongly.  Financial terms may be measured ultimately. o Eg: New plant and new Integrated Computerized information system  Promoting Senior Management Involvement. 3. Technical Feasibility Project may appear useful / is it technically possible? Eg : Multi National Company o OCR Hand written text o System may not be capable of handling although in local context is possible (similar characters in different languages). 4. Consistency with the system development Strategy (3-5 year Plan)  Fall within organizations systems development strategy.  Do it simply because other projects cannot Start or finish unless the project in question is implemented. 5. Capability of the systems Department to do the project.  Work Load: Allocated / Accepted.  Capable of doing the job required?  Is it a case of fitting the work into overloaded work schedule of SA’s.  Lack of technical know-how  use External Supplier. by: Dulshan Costa 15 2. Feasibility study. Overall Feasibility i. Can it be done? [Planned Dev. Technically possible] ii. Can we do it? Within Qualitative and quantitative resource capabilities of the organization iii. Is it worth doing? Commercially sensible to make the System Development investment.  Catch 22 situation. o Level of Detail planned Vs How much it is going to cost.  Locked into one approach / too early in the development cycle / Fails to consider other alternatives.  Ex: To get a job need experience, but in order to get experience need a job.  නේ stage එනක්දි Detailed Design වලට එන්නන් ෙෑ. ඒත් available design options බලෙවා (Alternatives). ඒ Design options වලින් වඩා නහාඳ ගැලනෙෙ most feasible design option එක න ෝරගන්ෙවා. Eg: Structural Design alternative for constructing single storey building. Design Alternatives Concrete Framed Load bearing Load bearing Load bearing Load bearing Pre-cast Columns Structure brick work block work Timber Steel & Beams Activities of Feasibility Study Activity -1 1. Determining the main user requirements, including timing  User needs – major determinant what is to be developed. o Wants – “Users are so close to the trees that they cannot see the woods” – True Needs.  Needs Active Support of users to the Dev. Process to be a success.  Sell the identified user needs. Needs Wants  In feasibility study N1  W1   Try to fulfill all Needs N2  W2  And fulfill some Wants if they N3 W3  can be done without additional N4 W4 cost.  N5 W5 N6  N7  by: Dulshan Costa 16 Activity -2 2. Determining the data to be used, their sources and estimated volumes. (Type of Data) Personal Data,  Volume – Nature and Scale of the system is determined by data and their volume. Medical Data,  Look at statistical reports / Existing files.  Check for Historic volumes – Growth/ Decline trends: What happened in festival Sports Data, Months? Sales Data,  Genuinely New System Difficult check data volumes. Use Estimates or Actual systems outside the organizations. Production Data. Activity-3 3. Analyzing the organization chart, Geographical distribution  Geographical Dispersion has a Major Impact on System Design and Economics  Impact on: o Data Communication o Number of Terminals: Hardware o Data Security Activity -4 4. Identifying the main characteristics of the system.  Define the logical system o What the system is? Not how it is done. o Has to be well established and formally ratified with user management before the ideas of how the new physical system begins to develop. Activity -5 5. Examination of other systems meeting similar requirements.  Check if similar systems has been done before : o Within organization. o Outside the organization. o Associated companies.  Talk to Computer user groups or hardware and software vendors: Help in locating one. by: Dulshan Costa 17 Activity -6 6. Determine that the requirements of the system are consistent with the objectives of the organization.  Prevention of Deviations helps to save Time and Money.  Sometimes the company Objectives: may not be formally published. Activity -7 7. Consideration of alternative design scenarios [DS]  Requirements of the new system is familiar by now.  What others has done in similar situations also established.  Brain storming Sessions with Small groups of users would help.  DS which is familiar to the Analysts may be the best approach.  For each identified design Scenarios prepare a list of major adds and disadvantages addressing if it is: o Quick/Cheap /Very Sophisticated / Expensive o Is it going to be?  PC/ Mini / Mainframe.  Standalone / Fully integrated systems.  Activity -8 8. Consideration of alternative Development scenarios  Covert the Design  Development  Which methodology to use Activity -9 9. Determine the proposed system is consistent with the organization's architecture and strategy  All developments must fit into the master plan.  SA needs to check proposals against the standard.  If some Design Scenarios do not fit, drop them. Activity -10 10. Preparing gross estimates of probable overall direct and indirect benefits for each practical alternative: Value based  Estimating benefits: Difficult task for SA since system is not developed.  Harder to quantify.  Sometimes the SA may have to get the users to place a value. by: Dulshan Costa 18 Activity -11 11. Preparing gross estimates of probable overall implementation and operation costs for each practical alternative  Get some handle of the likely costs associated.  To decide which alternative is economically most attractive.  Consider Initial Basic cost, Running Cost, Life cycle Cost. o Radically change cost benefits of the alternatives. Activity -12 12. Documenting the feasibility study in a report for the user and systems management  Findings on a Single report.  Facilitate whether to proceed with the system or not.  Identify Preferred Design scenarios for it and the Cost Benefit Analysis for Alternative Design Scenarios.  Documentation Should include: o Work done during the study. o Identified User Requirements. o View of the complete systems development process. o Break it or make it decision? o State Elapsed time, amount of manpower employed. Generally Feasibility Study take 6-13 Weeks depending on the Initial Study. by: Dulshan Costa 19 3. Project Planning.  GO / No Go  Decision to go ahead with the system development taken Main Activities in Project Planning. a. Form a Project Team b. Start Project Planning c. Start Project Monitoring and Control The Project Team (PT) Preparation of The Project  Project plan acts as the  Main task is to make clear Plan main monitoring and decisions.  This will act as the Master control process tool.  Clear allocation of Document for the project  Set up right channels for responsibility for the team team. feedback and Progress By PM with respect to :  This will also provide monitoring. o Budget. summary of information for  Revisions to the schedules. o Role of user depts. And the senior management. system Dept. Progress Reporting o Reporting to senior Content of the project plan:  PM  Senior Management. management.  Project Scope and objectives  Focus on major milestones. o Informing all relevant  Analysis of user needs.  Report Exceptional parties and other  Breakdown of the project into situations : departments affected. component activities. o Cost overruns. The Project Manager Should  Resource allocations for each o Slippage of final Provide the Project Team major group of activities. completion date. with :  Main milestones and dates.  Establish a Steering  Admin support. o Identification of  Budget spending procedures. Milestones [Identify committee to monitor  Procedure to hire Experts. Problems sufficiently progress.  Office space and equipment. early to avoid delays o Reps from user dept. and to recover lost / system Dept. / The Project Team (PT) : time]. Quality Control]. Primary Task  Project team responsibilities.  References to relevant Project File Maintenance [Record documentation. of the project ] : Includes : Objectives of using a planning Project Specification. technique Budget breakdown and  Identification of all activities expenditure analysis. which collectively form the Correspondence file. project. Name and address list of o Enables better contacts. understanding of project needs. Security rules for the project  Estimation of the time needed Contracts. for each activity. Work schedule and progress  Use of a Visual representation reports. technique [Project planning Minutes of steering committee and Management tool]. meetings. by: Dulshan Costa 20 Available Planning Techniques  Gantt Charts.  Network Diagrams [Interdependence/Critical path/ Float time].  GASP Techniques [Gantt with relationship between activities shown]: Resource Scheduling. Outcomes of Project Planning  Delays avoided.  Effective use of resources.  Acceptance of the operational system by the users. Precautions for Project The Project Plan needs to be Uncertainty Realistic  SA or PM Experience: Counts……!  Plan should allow for < Σ (Uncertainty Project of activities) = Good Plan activities not within project Uncertainty managers control: o Senior management review and control.  Pump in additional resources o Staff training on non-project activities. where uncertainty is very o Contract approval high. procedures. o Outside contractors own planning skills. ******* Realistic Planning  High uncertain items out of the  Avoid joint estimates.  A contingency of 10% built critical path to the greatest extent  Individual estimates first. into activities on the critical where possible.  Each estimate should be made path.  Time estimates should be checked without any reference to the effect  Interactive Process: with experienced persons outside it may make on the total project. Reviewed and revised when the project. o [Strong pressure to more information becomes reduce estimates for available. more favorable project target dates]. by: Dulshan Costa 21 4. Project Definition Phase. (Define to well defined)(Sculpturing)  Reflecting upon the work done in feasibility study.  Specifying objectives of System.  Breaking down objectives to Sub-Objectives.  Objective of the Phase: Get a system Definition [SD].  If accepted it will be the basis for all subsequent work.  Builds on the work done in the feasibility study. Detailed Rework of System recommended design Definitive System Analysis in Development = Scenario developed during + the Definition Phase feasibility study The relationship between System analysis and User:  More closer than FS [Finer Levels of detail].  Good working relationship must be built: Success?  SA will have to work with many different levels of users [Data Recording].  System Analyst should take a similar approach like Doctor Treating the Sick. Core of the Problem Symptoms of the Problem (Messy & Difficult to Implement) by: Dulshan Costa 22 Major Activities in Definition Phase 1. Specifying the objectives of the present system. 2. Studying the present system to determine the extent to which it meets the objectives. 3. Analyzing requirements to develop new objectives. 4. Identifying constraints imposed by the user’s environment. 5. Identifying responsibilities of the data capture. 6. Examining systems interfaces. 7. Preparing detailed user requirements. 8. Preparing design specification. 9. Planning for design and implementation phases. 10. Updating the cost benefit analysis. 11. Preparing a report for user and system management. System Objectives Ex:  To maintain the company’s share of the market.  To increase net profits over an extended period.  To increase the return on capital employed.  To maintain the current staff levels in face of an increasing workload.  To increase company’s product range.  To expand the geographical area in which the company operates. Sub- Sub-Sub Objective Objectives Objectives by: Dulshan Costa 23 System vs. Sub system Level Objectives Main Sub Reduce Average Delivery Times. A,B,C 10% D,E 15% Improve Customer Service Immediate Response to 90% Reduce Stocks F,G 30% A,D 45%, C,H 25% Data Capture: Inputs of the System:  Identify the Existing Procedure already there to capture the required data elements.  How to capture in the new system: ID New ways.  Rules o Closer to the original source.  Relationships between data elements should also be recorded. by: Dulshan Costa 24 5. Design. How the system should be designed according to system design principals. What System Vs How the System   Agreed Definition of system objectives to detailed system design which is to be implemented.  Entire system to be defined in terms of: Information Flow, Data volumes, Screen Layouts, Printed output design, procedures for computer operations, program specifications.  End of Day: Revised estimate of the operational cost of system + revised plan for Implementation. System Design  System design is not easy.  Skill and experience: Creative elements are there.  Cannot be taught….! Learned process.  Conscious and Unconscious design principals are followed by the designers to achieve a successful system Design. (Instincs). System Design Principles 1. Data should be entered into the system once and only once. 2. Data should be captured as close to the source as possible [Captured as a byproduct of the process creates that data: Avoids delays and Introduction of errors. Ex: In a Super Market.  X Scan Barcode Rate will come Have to input the Quantity Automatically Original Transaction Data is captured by Scanning. Same Data is used for invoice and Stock Control. by: Dulshan Costa 25 But the Data was entered to the system once & once only. Originally Captured Data Rate X Quantity = Amount (To the Invoice) Available Quantity = 150 When one is Sold = 150 – 1 Available Quantity = 149 3. Computer systems should be fully integrated into general work procedures. [Number, Position and accessibility of terminals: detailed aspect of design]. by: Dulshan Costa 26 4. The Design should be user friendly Man machine interface – easy use Screen displays – User vs machine dialog should be Consistent:  Same layout.  Move about without getting lost.  Minimize key in.  Use menus.  No complex code.  Provide help information: Online: Regular and Non regular user transaction paths. 5. Each Single element of data should be part of the coherent data base: (logical/whole)  Limits data redundancy and eliminates problem of same data derived from different sources.  Avoid ill- thought-out collection of files or a data base design. 6. Data should be structured to facilitate efficient retrieval:  Response to ad hoc enquires. (when needed)  Also should facilitate answering questions and queries which were either not considered when structuring the database. 7. Data should be available to everyone “with a need to know”  Freely available to all users whose work needs it: “Complete unrestricted access”  Different level of restrictions for different level users. Ex: Customer – Normal Access (View) Cashier – Medium Access (Comment) Manager – Full Access (Editor) by: Dulshan Costa 27 8. System should be designed for maximum flexibility:  It can be changed and it will be changed.  User Dept. Declares “needs never change”: But fails to survive the first month of operation:  Provide a Most Flexible Design o Modular design – redeveloped without complete rework. o Keep Data storage and processing separate: Enables data changes. 9. Systems should be designed to facilitate maintenance.  Maintenance is inevitable. o Eg: Legislative changes to tax in payroll.  Eliminate bugs in original system.  Minor changes to facilitate changed user needs.  Good documentation – Requirement for easy maintenance. 10. Systems performance should be satisfactory for the users.  Inadequate hardware.  Communication links.  Inefficient software.  Slow response times. o 3 second / 10 second / 5 minutes.  Poor response times. Will have a severe negative impact on acceptance of the entire system by the user community. 11. The ability to perform each transaction and access to all data should be controlled by security measure, and it must be possible to trace the execution of each transactions. (Data Access & Security).  Manipulate data – Main Issue??  Access to the system and data accessed should be protected.  Internal Controls: Accidental and deliberate threats: Internal dept. Manager and staff holds responsibility.  External risk: Total security is never achievable: Insurance: contingency plans in the event of a security breach.  Security Measures: Physical / Systems control / Audit and legislative controls: Depends on the systems sensitivity. by: Dulshan Costa 28 12. Back up Recovery procedures: Restore Acceptable time limits  Needs to be well documented and staff trained.  System Crash could be due to: o External factors: Fire, Food, accidents, acts of terrorism, other disasters. o They come at the most important, busiest time of the day. 13. System output should be provided directly to the person requiring it in a format suited to his / her needs.  Visual Display Unit (VDU) (Softcopy) / Hardcopy.  To the direct user – not through supervisory staff [Delay].  Should be part of the regular work schedule.  Format should be what the recipient needs.  To meet specific requirements [Avoid inches thick computer prints. Or hunts within the report to find required data]. 6. Build/ Buy Analysis. System එකක් inside නවෙම develop ෙැත්ෙේ දැෙටම outside තිනෙෙ කරෙවාද? software එකක් buy කරෙවද? (Use more Resources) Time, Cost, labour Cheap, time saving Innovative, Tailor made OR Build Buy by: Dulshan Costa 29 Disadvantages:  Common Solutions may be there.  Package Software: Never lived up to o Payroll, Taxation Table. expectations: Rework Expensive. o Purchases, Sales, General Ledger. Advantages: o Early Days – Unique set of programs.  Check the Common solution for:  Why reinvent the wheel.  Cut down on Application Development o Size. times. o Transaction Volumes.  Scare Human resources to: Unique o Organizational structure. applications: Competitive Edge.  Reduces Risk Factor: Time Tested product. o Management style.  Foundation for Application Package Industry. Package Selection (Buy)  Why it is less used? : o Absence of a simple practical approach o Systems “Sold” rather than “Bought”: discussion: Needs not met: Dissatisfied. Needs Package 01 Package 02 Package 03 Package 04 N1 N1 N1 N1 N2 N2 N2 N2 N3 N3 N3 N3 N4 N4 N4 N4 N5 N5 N5 AF 1 AF1 AF1 AF1 AF2 AF2 AF2  Packaged Vs In-house Development:  How to Determine?  Go through Buy or Build Analysis: 9- Tasks ………! Bought – ලාබ නිසා, නේසිවට, තිනෙෙවට මිලදී ගැනීම. ඒත් ඇත් ටම needs fulfil නවන්ෙෑ! (Buyer) Sold – ඒනක් තිනෙෙ features වලින් ඇත් ටම advantage එකක් තිනෙෙ නිසාම හා needs fulfil නවෙ නිසාම price එක main concern නොකර මිලදී ගැනීම. (Customer) by: Dulshan Costa 30 Build/ Buy Analysis Tasks 1. Preparation of a logical 2. Preparation of Request for Quotation (RFQ) for Potential design specification: Vendors: Systematic analysis of user  Proposals – compares and evaluate requirements [System Definition  Areas to cover: phase] o Summary of general business environment / System requirements/Technical Environment/ Evaluation procedures Acts as the template / Degree to & Time table which it meets functional o Evaluation Criteria First requirements  Points Weighting Scheme [Best Buy] System Functionality: Technical Factors: Commercial Considerations: 6:2:2 / Go: No Go  Scoring Packages [1-10] 3. Preparation of Potential 4. Development of cost and 5. Conduct Initial Vendor Vendor List: timing estimates for the build Evaluation  List to seek Proposals. in solution or in house solution  Make the list of  Number within Manageable  Be realistic / Other Submissions. proportions. Developments  Check for responsiveness.  Good to identify package.  Exclude from detail evaluations. 6. Evaluation of the functional fit: 7. Determination of the Technical feasibility:  Increasing detail-user requirements.  Existing hardware/ Software Environment: Staff  Confirmed with detailed discussions Training. with vendors.  Systems Architecture : Modular package  Hands in use- Trail Installations 90  Data structures: can we use Data elements already in use Days Vs Better Existing customers. [Time/ Expensive/ Modify].  Quantitative assessment of the  Package Interfaces –Building Bridges: cost +Time. functional fit and qualitative  Documentation: User manuals / Quality Online help. assessment of the user friendliness.  Details for Cost Benefit Analysis of the package. 8. Review of user references 9. Evaluation of commercial Considerations:  Limitations: Use software, payment  Existing users. requirements/warranties/options for extensions.  Independent of the vendor.  Life cycle cost: Initial cost / Cost of modification/ maintenance/  Quality of vendor support. licensing cost.  Flaws.  Discounted cash flow [Time Phased].  Confirm potential purchaser’s judgment. Buy at All???  System functionality and technical factors V: Important.  Close Run: Shortest payback period.  “Earliest date showing a surplus of cumulative benefits over cumulative costs. by: Dulshan Costa 31 7. Project Implementation Phase.  Doing the work actually.  User interface Design  Coding  Testing & Debugging  Finalizing User interface  Frontend & Backend  Testing &  Finalizing Design Development. Debugging (Coding)  Make sure user requirements has been fulfilled.  All the things done in previous phases starts to come to a reality. In here the senior system analyst get to know whether he had done a good job or bad job in previous phases. Like self-evaluation of analyst. Outcome of this phase  Fully Operational System.  Fully Documented System.  Accepted by users the system owners and users for their needs.  Needs foreseen in the System Definition Phase has become a reality??? Operation of this phase Design Convert Working SYSTEM ***Make the System Operational & Error Free. *** by: Dulshan Costa 32 Possible failures of the Project. 1. To many Errors. 2. Too Complicated Use. 3. Lack of Confidence In the system implemented. 4. Permanent damage against the system Future systems too. Project control necessary.  PM/SA will have to be Responsible.  Project Leader SA: Implement the project plan set up during Project Planning stage.  With Lot of Changes to it. Everyone has to know.  Make sure Every Individual knows and understands his/her role towards objectives.  Be Precise: Because some activities are very vaguely defined: o Checking data. o Monitoring user reaction. o Decide on the Time factors- Max Allowable time. Standards.  Implement Standards and work methods which apply for the project: To all parties involved.  Once Implementation starts any design changes should go through Change Control Procedure. Considers when doing Changes.  Changes enhance system?? : Value Added to the system?  Study Impact….!  Time Vs Cost  Does it meet system objectives? Need for Documentation  Formal review a must…….!  Well documented too.  Helps in Subsequent testing.  Gives an exact record of what the system actually does.  by: Dulshan Costa 33 Major Activities in this phase 1. System Construction 2. System Acceptance 1. Creative work of System Definition and Design  It is the Final Declaration of Commitment to the phases are brought into reality: Typical Activities include: new system. o Write Debug All Programs.  System Acceptance procedure: Very Important if o Create Master file: Populate Data bases. bought from outside. o Documentation: Online + EDP Staff use.  Includes : o Acquire all Equipment and supplies. o Provisional [Released for live running].  Train Electronic Data Processing (EDP) and User o Final Acceptance[ 3 months error free – Staff :Training: SA’s Responsibility Routine operational status]  Areas :  Bench Marks: Performance: Creation of a wider 1. Input preparation. task and see how the system performs it. 2. Error correction. o Data retrieval. 3. Distribution of output [HC]. o File transfer. Test and approve all parts of the system o Validation of test Data.  Technical skill: SA + Specialists to set up Testing: Objective: Error Free system: reasonable Bench marks. Fulfills all planned functions: Before going to Real life:  Guidelines will include : 1. Test each module separately. 2. Integrate whole: Use Test and Live Data 3. Get Users to test: When error free. 4. Test all procedural cycles: Month, year End, year beginning. 5. Peak load – Extreme conditions.  Parallel Run before going solo : SA to go on duty with users  Supervise phasing in different parts of the system  Tune the system for improved performance  Security Procedures o Use Video films & presentations to explain.  User / Operating manuals : o Distribute well in advance by: Dulshan Costa 34 8. Post Implementation Review & Evaluation. [Feedback for the System] When does SA Job End?  When the system is in operation and running Error-free……………. ++.  Many SA move on to new projects.  System review and evaluation needs to be complete to complete the System Analyst’s work. Why Post Implementation Review & Evaluation is done?  Check Achievement of the operational system vs. objectives originally set during system definition.  Efficiency of the system: identify where there is room for improvement.  Feedback for System Analyst’s professional development. When Post Implementation Review & Evaluation is done: (Timing)?  After completion of several cycles o Once a month – 6 Cycles o Once a week -2 months  Why wait? o EDP staff are thoroughly familiar with the system. Key areas to address in Post Implementation Review & Evaluation.  User Reactions.  Systems performance.  Errors and problems.  Checking that the system is functioning as foreseen in the system definition. o Document the findings- Users and system management. o Recommendations for action according to priority and cost. by: Dulshan Costa 35 Bi Annual Review of the System.  Start it approximately after 2 years.  Amendments/ Modifications Due to change in user needs.  Does it fulfill original purpose? o Run smoothly now but may be obsolete?  Need for periodical reviews of operational systems. Bi Annual Review: What Areas Target 1. Does the system meet the needs of user management? 2. Are the benefits and the costs of the system acceptable and do they show major differences from the estimated: original 3. Is the system is adequately secure? 4. Is the documentation up to date 5. What improvements are desirable and at what cost? Mapping the system’s future Feed back to the systems strategy and planning process If expected benefits are not realized Phase out? Will the system be able to cater for new user requirements and to what extent? Bi-Annual review needed to check Achievements of the system and for mapping the future of the system. by: Dulshan Costa 36 9. Maintenance & Enhancement. What to Expect From an Information System Development  Obsolescent the day become operational.  But still valuable to the organizations.  Changes from the start.  SA vs “Completed system”: Rare.  Information System dynamic and subject to change. Reasons for System Obsolescence (Outdate) 1. Oversight on the part of SA at design stage. 2. Misunderstanding of requirements of the user department. 3. Insufficient testing of systems before operational usage. 4. Desire to improve system performance. 5. Change in user department procedures. 6. Company policy change [pricing structures, Credit policies]. 7. Change in legal requirements (Tax Laws). 8. Desire to take advantage of technical developments. Need for System Maintenance  Unnecessary changes without adequate analysis of their implications should be avoided. o Many cannot be avoided. o Permanent work load for Systems department.  Need to make an allowance even for new systems installed. by: Dulshan Costa 37 Need for System Maintenance New Development Cost Implications Essential and Nonessential vs. maintenance System Amendment  Maintenance: Workload  Direct Cost of staff ++.  User needs –System Heavy.  Space + Resources for Definition phase –  Only a Finite number of testing. minimize subsequent systems installed can be changes to the system.  Drain on Electronic Data managed with a given limit  Some changes might bring Processing (EDP) budget of manpower. significant benefits: will keep rising.  Mature installations 60% of Enhance performance, easy  Control on maintenance Systems department's staff use, and better help.  System department : Slow : good on organization.  Essential vs not so essential More effort to keep the maintenance Decision. system going:  Control it so that the o Redesign Vs Amend resources are better utilized  Need for more staff: rather than constantly Resource Allocation. consumed.  by: Dulshan Costa 38 Types of System Maintenance 1. Corrective Maintenance 3. Ongoing Maintenance.  Put right to meet original system (Periodic Maintenance)  Not practical. definition: urgent/ occurs in the early  Environment change: Continuous System operational life. change not practical: Periodic.  Prevent it do a thorough check of the  Orderly way: Genuinely in line with the design and the preoperational system interests of the organization. against the system definition.  Formal procedure for handling  Problems: Check to see if they are errors modifications. or new user needs.  Implement agreed modifications on a plan  Error correction: test: rest of the system is as amendments: Large system group of not affected. amendments as a periodic release: Back  Record of change and update of track/test / documentation. documentation.  Inform all that who needs to know. 2. Enhancing Maintenance. (Enhancement)/Upgrade  Fall short becoming a project ongoing maintenance Vs new project.  Normally originated by System department.  Why Enhance? o Non urgent but beneficial changes. o Basic software changes (DBM) o Other system development open new possibilities. o New requirements of security. o Improved ease of use of the system.  Decide on a cost benefit analysis.  Improvement Vs too many changes. o Irritate the user. o Introduce them as a batch.  Remember Stability has a high value on the system. by: Dulshan Costa 39 System Modification Procedure Go Ahead….. Make One More Change  Formal procedure to change control  Many do not understand the consequences.  Time: SA/Programmer / operations department and computer resources.  Cost of making the change.  Request in writing –signed by head of Dept.: SA to evaluate [Cost, Effects of change on system, system performance]: Approval of cost by user dept. [Direct Saving]. Modification Documentation: Special Document  Name / Description. Of modification. / Reason and justification/ estimated cost/ Implication of the modification [Less running costs / doing things better].  Minimize maintenance but ensures efficient system development which adopts to evolving user needs. Introduction of change  Physical Introduction and control. Why Needed? :  Changes are correctly made and to satisfy audit requirements of the organizations. Documentation in Place:  Use Software aids for Change control, releasing new versions, reverse engineering. by: Dulshan Costa 40 EXPERT SYSTEMS & ARTIFICIAL INTELLIGENCE  What is AI?  One of the pioneers of AI, Dr. Marvin Minsky defined AI as: "The field of study which is attempting to build systems which if attempted by people would be considered intelligent”  AI Applications Expert Speech Systems Gaming Synthesis Vision Theorem Systems proving AI Natural Robotics Applications Language by: Dulshan Costa 41  Who are Experts  We all depend on expert assistance-from o Doctors o Attorneys o Automobile Mechanics, o Computer Repairmen  Own experts? Right now, only large institutions like medical schools or oil companies can afford to purchase expertise.  Expert System Pioneers  Try to construct an artificial expert.  Dendral, the first expert system, in 1965 at Stanford University.  What are Expert Systems?  An expert system is a program, which attempts to mimic/imitate human expertise.  They use inference methods to a specific body of knowledge called the domain.  They infer new information from what is already known about a problem.  Domain knowledge is frequently represented as rules. Knight Industries Two Thousand  by: Dulshan Costa 42  Building blocks of Expert System  Expert System Characteristics Vs Conventional System Characteristic Expert System (K.I.T.T) Conventional System Underlying Paradigm  Heuristic. (Learn by themselves).  Algorithmic. (Use given procedure by Conditioning/  Solution steps not directly expressed. programmer). pattern)  Solution cannot be guaranteed as  Solution steps explicitly given by correct. programmer.  Declarative problem solving paradigm.  Correct answers given.  Programmer is not required to specify  Procedural problem solving paradigm. exact procedure to solve problem.  Ai use their own procedures. Method of Operation  Reasons with symbols.  Predominantly manipulates numeric  Ex: get conclusions from known data. premises to diagnose a patient illness.  Ex: sorting, calculating and sorting  Inference engine is used to decide the data processed to produce information order in which premises are evaluated. such as pay slips for a company payroll system. Processing Unit  Knowledge.  Data.  Represent in form of rules.  Represented in form of Arrays/ records  Knowledge is Active in system. in languages like C or COBOL.  Can interfere with available knowledge  Data is Passive in system. with reasons to gain new knowledge  Does not give rise to further generation from given Data. of Data. Control Mechanism Inference (thinking) engine usually separate Data/information and control usually from domain knowledge. integrated. Fundamental Expert = Inference + Knowledge Conventional= Algorithm + Data Components System (thinking) System Explanation Yes. No. capability An explicit trace of the chain of steps underlying the reasoning processes. Enable a user to find out how the system arrived at its conclusion or perhaps why system is asking for an answer to a particular question. by: Dulshan Costa 43 Knowledge Engineering  Knowledge Engineering is the art of designing and Building Expert Systems.  The Knowledge Engineers are its practitioners.  Knowledge Engineer is a computer scientist who knows how to design and implement programs that incorporate artificial intelligence techniques. Tools, Shells, and Skeletons Building an Expert System: Ways. 1. From scratch. 2. Build using a piece of development software known as a "tool" or a "shell“.  Fast / Easy? / Cost /general-purpose shells to shells custom-tailored.  Knowledge acquisition Still a problem.  Accumulation of high-quality knowledge into the Shell.  Done by Knowledge Engineers.  The power of an expert system lies in its storage of knowledge about the task domain. by: Dulshan Costa 44 Experts’ knowledge Pre-Problems  Expert System Programming Languages  The most prominent is called LISP (LISt Processing). 50’s.  PROLOG (PROgramming in LOGic). 70’s: France. by: Dulshan Costa 45 General Application Areas for Expert Systems 1. Interpretation 2. Prediction Forming high level conclusions from collections of Projecting probable consequences of given situations. raw data  Predicting trends, and controlling.  Foreign exchange trading. 3. Diagnosis  Medical Diagnosis  Diagnosis of Engineered Systems: 4. Financial Decision Making o Determining the cause of malfunctions in complex situations based on observable  Insurance. symptoms.  Loans for businesses and individuals. o Failure correction: real-time systems that actively monitor processes can be found in the steel making and oil refining industries. 5. Instruction o Diagnosis and Troubleshooting of Devices  Assisting in the education process in technical and Systems of All Kinds. domains. 6. Design and Manufacturing 7. Process Monitoring and Control  Finding a configuration of system  Monitoring: Comparing a systems observed components that meets performance goals behavior to its expected behavior. while satisfying a set of design constraints.  Control – governing the behavior of a  Design of physical devices and processes. complex environment.  Factory floor configuration of manufacturing processes. 8. Planning and Scheduling  Configuration of Manufactured Objects from  Planning: devising a sequence of actions that will Subassemblies: modular home building. achieve a set of goals given certain starting  Manufacturing, and other problems conditions and run-time constraints. involving complex engineering design.  Planning airline scheduling of flights.  Manufacturing process planning. When Selecting an Expert System; Need For Careful Selection  Ill selection: Costly embarrassing failures since implementation needs Considerable investment in Money and Human Effort.  Too complex, poorly understood, unsuited for technology available. by: Dulshan Costa 46 Guideline for Expert System Selection. 1. The need for the solution justifies the cost and effort of developing an expert system: Where a large potential exists for savings in terms of money, time and human life. 2. Human Expertise is not always available where it is needed. : Example.  Remote Mining and drilling sites: Expert visit Vs Placing an expert system at the Remote site: Time and cost savings on Travel. 3. The problem may be solved using symbolic reasoning.  Does need Sophistication and flexibility of humans.  Does need human dexterity (use of hands) and perceptual skill (Different Viewpoints using five senses: Mind and sight). 4. The Problem domain is not well structured and does require commonsense reasoning  Highly Technical: Well thought of and well defined terms and scopes.  Clear conceptual models.  Commonsense reasoning is very difficult to automate. 5. The problem may not be solved using traditional computing methods.  If traditional can be used successfully why not?  No misuses of Expert systems.  May end up with a more satisfactory solution. 6. Cooperative and articulate experts exist  The knowledge to be used by the expert system comes from experience and judgment of humans working in the domain.  Expert is willing and able to share his knowledge. 7. The problem is proper size and Scope.  Expert System to capture knowledge of a medical doctor would not be feasible.  Only for a particular set of Diagnosis more appropriate.  Knowledge Engineer Vs Application Domain. by: Dulshan Costa 47  Benefits of having Expert system for End Users.  Speed: 10: More.  Cost Savings.  Improved Quality of Decision Making.  Preservation of Scarce Expertise.  Introduction of new products.  Problems with Current Generation Knowledge based system (KBS) Technology. 1. Knowledge Acquisition: General/ Specific / Experts. 2. Knowledge Maintenance: Need to update when changes occur. 3. Lack of Transferability: hard to transfer: Local Vs Global. 4. Little Reuse of Knowledge: primary stages. 5. No CASE Methodology: standards for creating? 6. Expected Programmer Productivity: 1st Vs Nth. 7. High Cost of Producing User Interface: 60 to 70% of Cost 8. Poor Performance: Large / slow/substantial computing resources 9. Programmer Education: little familiarity with LISP: KBS products are being rewritten in C: FORTRAN/KR and COBOL/KR  Future of Expert Systems  KBS as a business has not been successful.  Require continuous updating.  Often a hit or miss process.  Areas for Development : o Easier knowledge acquisition. o Reuse of the KB. o Ability to fully and directly express more of the model of the domain. o Need for a mature CASE-like methodology. o Easier development of the user interface.  Cost and skill requirements of developing a new application could be brought down.  Explore new areas of applicability.  Enormous potential of KBS technology. by: Dulshan Costa 48  Why QS’s FM’s should know about AI and Expert Systems?  To become an Expert a considerable amount of Experience is essential.  It takes decades to become an actual expert.  When people become expert they are mostly at their old age.  To preserve the Expert knowledge & Skills of those experts, Expert Systems are being used.  Therefore, when experts donate their knowledge & skills to develop an Expert System their knowledge & Skills can be used by new comers who has no expert knowledge or skills.  Hence, Expert Systems helps to the development of the profession (QS/FM).  If not, Experts long gathered knowledge & practiced skills will vanish with their deaths. Expert System “A collection of Knowledge & Skills Of The different types of Experts”.  by: Dulshan Costa 49 costX Content 1. New Building 10. Custom Quantities 2. Re-Adjust Building Properties later. ( Error 11. Doors & Windows correction) 3. Add Drawing 12. Create “Dimension Group” using existing “Dimension Group” 4. Calibrate Drawing Scale 13. Auto Count 5. Creating Dimension Group (Horizontal 14. Reinforcement measurement) 6. Measure Vertical Items 15. Getting Report -Drawing Output 7. 3D View 16. BoQ Preparation 8 Concrete Works 17. Print BoQ 9. Pile Cap by: Dulshan Costa 50 1. New Building i. Click “ New Building” ii. Fill “Name, Building Code, Project, Building Type, Base UOM, Default Height” and Click “Insert”. by: Dulshan Costa 51 2. Re-Adjust Building Properties later. ( Error correction) i. Click “File”. ii. Click “Properties”. iii. Change necessary items and Click “Update”. by: Dulshan Costa 52 3. Add Drawing i. Under the “Drawings” Tab  “Add”  “Add Drawing”. ii. Select the Drawing and Click “Open”. iii. Fill Drawing Properties and Click “Insert”. (When inserting structured Drawing Changer “Folder Name” to STRUCTURAL DRAWING”) by: Dulshan Costa 53 4. Calibrate Drawing Scale i. Follow “2. Re-Adjust Building Properties later. (Error correction)” procedure and Change “Base UOM” & “Default Height” for Millimeters. Then, Click “ Update”. ii. “Calibrate X Axis”  Click on known distance in Drawing. iii. Enter the Actual Measurement in “mm” and Untick Apply Factor for Y Axis then Click “OK” iv. Follow same process to Calibrate Y Axis v. If needed to recalibrate Click “Reset Calibration” and follow the above process again. by: Dulshan Costa 54 5. Creating Dimension Group (Horizontal measurement) i. Under the “Dimensions” Tab Click “Add”  “Add Dimension Group” ii. Fill “Name, Folder” according to NRM2 (Method of Measurement). And others according to measurement type. Then Click “Insert”. iii. Follow “2. Re-Adjust Building Properties later. (Error correction)” procedure and Change “Base UOM” & “Default Height” for Metres. Then, Click “Update”. Can Measure Line or Point wise With “Ctrl” key can get continuous line. (+) Dimensions Change Dimension Decimal Places (-) Dimensions File  Options  Drawings  Both Dimensions Dimension Groups  Decimal Places  2 (Default)  When we need to Deduct  By Deleting all Dimensions in Group we can  Select that measurement needed change Measurement Type. to Ddt   We can Rename Dimension Labels.  Can Add “New Dimension Group” with Same Only for Area Measurements “Folder” but with different “Name”. If you are using Right Click  Complete Area by: Dulshan Costa 55 6. Measure Vertical Items Follow procedure “5. Creating Dimension Group (Horizontal measurement)” to add Dimension group. But in “Dimension Group Properties” Change “Default Height” according to the height of the element. Eg: Change measured heights for Negative Dimensions.  Right Click on  Modify  Change Negative Line Dimensions Height  We can Select in Area to Select Dimension and do for Selected Dimensions. 7. 3D View Under the “Drawings Tab” Click. by: Dulshan Costa 56 8. Concrete Works Follow procedure “5. Creating Dimension Group (Horizontal measurement)” to add Dimension group. Eg: Name: 5.1.1_200mm thk wall Folder: 11. Insitu Concrete Work Measurement Type: Area Default Display: Volume Default Height: “Set Height of the element” In “Measured Dimensions” Set Proper formula with {} brackets. After setting Click “Insert”. by: Dulshan Costa 57 9. Pile Cap Name: 2.0.2_PC12_PILE CAP Change the Formula: Folder: 11. Insitu Concrete Works Volume: Measurement Type: Length {length}*{width}*{height} Default Display: Volume Default Multiplier: “number of piles in pile cap” Default Width: “width of the pile” Default Height: “height of the pile” 10.Custom Quantities + insert Change the Formula: Name UOM Formwork for pile cap: 2 Formwork for pile cap m {length}*{height}*2 + {width}*{height}*2 11.Doors & Windows Name: 1.1.1_D05_Door Folder: 24. Doors, shutters and hatches. Measurement Type: Count by: Dulshan Costa 58 12. Create “Dimension Group” using existing “Dimension Group” Copy and Paste “Dimension Group”. Then Rename it. The Quantities will same. 13. Auto Count 3. “Capture” and Select the symbol to be counted 2. Set meters accordingly. 1. Click “Search”. by: Dulshan Costa 59 14. Reinforcement Name: 34.1.1_32mm dia in pile cap_straight Change the Formula: Folder: 11. Insitu Concrete Works Weight: {length}*6.32 Measurement Type: Length Default Display: Weight Default Multiplier: “number of pile caps” Kg/m Weight UOM: kg According to Bar dia  Switch on “Rebar Mode”  Using Point Mode 1. Select “Distance” 2. Select “Bar Length” from the Drawing  Right Click on the Distance line  “Set Spacing”  Enter Spacing  “Update”  Repeat the whole process per bar size to measure the other R/F bars like 25mm & 30mm.  Set different weight factors for different bar dia s. by: Dulshan Costa 60 15. Getting Report -Drawing Output i. Select all the Dimension Groups that to be Printed. by: Dulshan Costa 61 Method I i. Go to “Drawings” Tab  “Reports””Print Drawing Window to Report” ii. Fill the Details and Click “Preview”. (Most details comes automatically, Changing Print Title is enough) iii. Get the Printout by clicking Print Icon. by: Dulshan Costa 62 Method II (Better output) i. Go to “Drawings” Tab  “Reports””Print Drawing Window to PDF” ii. Fill the Details and Click “Publish”. (Most details comes automatically, Changing Print Title is enough) iii. Give “File Name” and then “Save”. by: Dulshan Costa 63 16. BoQ Preparation Method I i. Under “Workbooks” Tab  “Add” ”Add Workbook” ii. Fill Workbook Information and Click “Insert” iii. Double Click on a Row Number to go Sub-division. iv. Double Click on a Quantity Cel