InFocus Modeling and Documentation Samples

This web page provides a glimpse of many different types of models and deliverables we have created. First, we'll start with some proprietary diagrams and models, a white paper and an electronic presentation.

Iterative Development Cycle (IterativeDevelopmentCycle.pdf): This diagram characterizes our iterative development philosophy. Using a principles-based approach we establish a shared vision and collaboratively define success criteria. Then we analyze, build, deliver and learn incrementally, delivering small, useful chunks of software functionality. By developing and delivering in small steps we are able to incorporate what we learn in each iteration. Knowledgeable users are afforded the opportunity to shape, test, kick and reshape at every step. We never deliver in behemoth-sized releases where financial constraints preclude effective quality control and assurance.

InFocus S.O.P. Version Control (SOPVersionControl.pdf): We created this model as a guide to help us keep application folders uncluttered by drafts and out-of-date documents, as a coordinated team effort. We also designed it to keep a pristine version of the application as delivered, while having an "in development" version with recent changes that have not yet been installed. We also created a folder of version releases.

White Paper

Access and SQL Server (ClientServerGeneric.pdf): This diagram and white paper were created to give our Controller client a better understanding of the issues (including pros and cons) about using Access and SQL Server.

Electronic Presentations

We frequently create electronic presentations for training courses and plenary sessions. Check this one out: http://users.techline.com/infocus/presentations.htm.

InFocus Client Documentation

Our application manuals are generally very "light" when it comes to narrative text. We find our clients are often unwilling to pay for user documentation. So, over the years, we have developed modeling methods which put the narrative on the diagrams.

Our application manuals always include a Table of Contents, Context Diagram, complete screen diagrams with callouts (you'll find several examples below), reports, tables, and a technical reference section intended for our clients' IS staff. Several years ago, we started to include version release notes. We often include one or more Entity Relationship Diagrams. We generally only create models which are required to illustrate complex technical concepts - either for our development efforts, or to inform our client population.

This web page includes models for many projects; however, to protect our clients' confidentiality, we have renamed or otherwise revised the models to put them on the web site for your review.

Executive Reports

VCLS Executive Summary (VCLS_ExecutiveSummary.pdf): The VCLS application was written in PowerBuilder by our client's IS Department. Our client (the division Controller) wanted documentation to be written to permit temporary employees and vacation relief workers to perform tasks, including data entry, for this application. He was also troubled by extreme user dissatisfaction with the application.; We conducted user interviews over several weeks, and created an "executive summary". Janis had recorded so many individual comments about the application performance and problems, I decided to include them in the report. The IS Department used the document as their main guide in elaborating and proceeding forward with an additional $200,000 investment in changes and plans for the targeted system.

Ad Hoc Diagram (PeopleProbs.pdf): Another "set" of information collected during user interviews highlighted the myriad complaints employees at two locations had about each other. We wound up modeling this situation with our "Client Business System" diagram to illustrate cultural problems that would likely defeat any efforts to improve operations with software-based solutions.

Status Report (1999-01-04-email2fred.pdf): After working with a division Controller for more than six years, we had established a rapport which permitted a degree of informality in our communications. This is a status report which Fred referred to for many months by saying, "It's just like Janis said in her email", particularly regarding the warning about the upcoming conversion of a mainframe application, and the impact it would have on many desktop applications.

Overview Diagrams

PMIS - Old System Overview (PMIS_OLDSYS.pdf): On this project we upgraded a system that was a patchwork quilt of mainframe, Paradox and Access databases with spreadsheets. The system used Paradox tables to export data to a spreadsheet which was then used to generate Journal Voucher reports that were uploaded into a mainframe accounting application. Much of the Access portion of the system was developed by a power user. This portion lacked functionality that was beyond the power user's capabilities, notably the preventive maintenance calendaring. This diagram enabled us to communicate the complexity of the old system to identify what could be eliminated or simplified by enhancing the Access portion and eliminating the Paradox segments. Ultimately, we replaced the spreadsheets and macros and Paradox scripts with an MS Query option for export to the mainframe.

PIMS - PGD Spreadsheet Suite Overview (PGDSpreadsheets.pdf): This spreadsheet suite was a thorn in many users' sides. We incorporated the needed features they provided into the new PIMS integrated application (originally printed on 11 x 17 or Tabloid size paper).

PIMS - 9' Stud Modifications (PIMS_9footStudMods.pdf): Our client added a unique new product that impacted three applications and ancillary spreadsheets. We analyzed and modeled the repercussions of the revisions in advance, to minimize the risk of overlooking any, and to coordinate the implementation and installation sequence.

Code Management for Analyze Items Sold System (AISS_BLPSCodeMgmt.pdf): We based a group of applications on a single shared set of product codes. Therefore, if the "keeper of the codes" was not alert, s/he could wreak temporary havoc for several users of each of these applications. We created this diagram as a guide for the "keeper" to maintain the codes correctly.

Context Diagram

Context Diagram (PIMS_ContextBig.pdf): This is a large, comprehensive context diagram for a project requiring us to integrate five existing applications into an integrated suite providing selected functionality from the original systems and new features only capable after the newly created integration was accomplished (originally printed on 11 x 17 or Tabloid size paper).

Screen Diagram with Callouts

Consolidation & Export Management Screen (PTISUserScreens.pdf): This application has date- and time-sensitive transactions which are critical to coordinate accurately. We created this screen to enable users to see the status of various data sources and manipulate application parameters as needed. This is an example of the kind of user screen documentation we routinely provide in our applications manuals.

Report Models

PIMS - Planer Reports Menu Screen (PIMS_Screens.pdf): The load data tab on this screen allows users to create specific data sets for finite time periods with a choice of annual production standards (calculated benchmark projections). Once the data set is created (load data button), the user selects one or more reports for one or more production centers on the display/print tab. This module uses one data table and one master report form with embedded subreport forms.

Report Model and Supporting Technical Diagrams

Daily Production Summary Report Summary (PIMS - Daily Production Summary.pdf): This key report provides critical production data for production managers as well as shipments and sales information for financial analysts. While on the surface it looks like a simple data dump, it is actually comprised of nearly 40 individual calculations (see calculations in report model below). The bold items in the left column are production centers, each with their own set of data. It also is a mix of actual production data and planned production, and the calculations sometimes cross temporal boundaries.

Daily Production Summary Report Data Model (PIMS_DailySummPie.pdf): This report overview shows how we extract and accumulate data to create the TmpA_DailyProdSummFinal table that populates the final report. We developed a table naming convention that vastly improved our ability to relate to the data sets, e.g., LU = LookUp, UD = UpDate (adjustment factors that tended to get updated daily, weekly or monthly), TmpD = temporary tables that get deleted and then recreated during processing, TmpA = temporary tables that get emptied out and then reloaded or appended to during processing. These temporary tables were used as mini datamarts for power users to query for specific ad hoc analysis and management purposes (see page 1 of 2). They are expendable (safe for users to play with) as they are recreated each time reports are printed.; Because the calculations on the Daily Production Summary Report sometimes cross time boundaries (the column sections of the report), this diagram is helpful to communicate how calculations are handled (see page 2 of 2).

Daily Production Summary Report Calculation Model (PIMSDailySummReportCalcs_Gross.pdf): It was critical to model the sometimes complex calculations for this report because there. are some labeling translations between source data and report labels and headers. This set of models became the bible for the financial analysts, and provided a method for business knowledge experts to verify the accuracy of programmed calculations.

Process Flow Diagram

Forecast Process Steps (CSSForecastProcess.pdf): We constructed this informative diagram to model an application that turned out to be a collection of automated tools to assist a highly-skilled and knowledgeable user to perform a complex forecasting process. We designed this diagram format to illustrate the business processes (marked "essence" in in the gray guide on the left side), and the associated tools from multiple systems (marked "implementation" in gray on the left-hand side) required to perform this complicated forecast. The existence of this model enabled a new user to take over this process in a small fraction of the time that would have been required without it. (We have included three pages from the original sixteen-page document.)

Forecast Calendar (CSSForecastCalendar.pdf): Another model created to assist the user in the complex Forecast process was the "CSS - Calendar of Forecast Cycle". It identifies a "week" from the standpoints of various production and management operation cycles.