Category Archives: Implementation

SMOSLT Project/Modules Summary

You probably won’t understand SMOSLT as an app until you first read why SMOSLT is run within an IDE. It just won’t make sense.

SMOSLT.app

This is the main SMOSLT project, where all the important action happens.

 

These actions include

  • running the other modules
  • Taking the assumptions you give it, and coming up with a list of costs based on those assumptions.

SMOSTLT sequence of events within modules:

 

Orchestrated primarily from app module, but also manually from within IDE, given no UI

  • before firing, user has already
    • created a compliant PL file
    • created list of options and other assumptions in assume module
    • created SideEffect code that drives each option.
  • imports PL file
  • imports assumptions from assume module
  • sends each of these to the optaplanner options module
    • options
    • schedule binary
    • analytics
  • optaplanner options module then folows this sequence
    • toggles one option on or off at a time
    • sends that combination of options to stacker
      • which can be on separate threads or machines if required
      • which writes each score and binary to analytics module
      • which also then returns score back to options module
    • runs to some reasonable termination whatever that means
      • brute force if options list small enough
      • more elaborate search process if options list too big
  • user then reviews run in analytics module

 

SMOSLT.domain

Java classes consumed by other modules. Kept separate just for purposes of clarity.

SMOSLT.given

Assumptions are required for SMOSLT to do anything meaningful.

 

This is YOUR area, because you are responsible for all assumptions, even though you might start out with 100% default or partially customized assumptions provided by others. This is like what the cop tells you: “Ignorance is no excuse” the results you get will be no more satisfactory or correct than the assumptions you used to initiate a specific run.

 

Areas that assumptions cover:

  • Unit costs for include.
  • Beliefs about if-then consequences – if I have a java task with no testing, then I will get 30% more unanticipated work fixing bugs. That’s a belief. No one can know what really happens until it does.
  • Story templates. If every task is a story, per agile approaches, then the sum total of all tasks is a narrative arc that makes up a story template. No story template is truly representative of what really happens, but to anticipate costs you have to start somewhere.
  • Actual ProjectLibre files. Ease of use demands that you start with a ProjectLibre template, compliant to SMOSLT specifications.

SMOSLT.stacker

Stacker, or ScheduleStacker, creates a real schedule from a ProjectLibre specification template. Stacker knows nothing about SMOSLT or all the fancy stuff that SMOSLT does, it just stacks up tasks and allocates resources like it is told to do.

 

Stacker is designed to be as simple and fast as possible, because it might get called to re-stack a schedule thousands of different times in a single session.

 

Stacker could theoretically be used by anyone, without any SMOSLT usage. It is not anticipated that anyone would wish to do this, but it is welcomed if desired.

SMOSLT.mprtxprt

SMOSLT does it’s active work in SMOSLT code, and does not interact directly with ProjectLibre APIs. A ProjectLibre schedule is entirely converted into SMOSLT code, and then when done entirely converted back into ProjectLibre file. Ne’r does the twain meet.  This conversion happens in this module.

 

Only the brave should ever crack open this module. ProjectLibre APIs can be quite challenging to the uninitiated, and a giant black hole of time. As of Oct 2014, it is being rewritten ground up anyway.

SMOSLT.main

Someday SMOSLT may be runnable from a real GUI, like you would expect from any decent application.

That day has not yet come. So until then, it is run from a command line. This command line , or CLI code is maintained here.

 

SMOSLT.options

See separate document

 

SMOSLT.analytics

 

 

SMOSLT:generator – A Project Generator

This project is front ended in SMOSLT.webgen and is only now partially complete


 

The Project Generator generates up to an infinite number of [allegedly] representative software development projects of varying types, sizes, and base option levels.

 

Generated projects can be used by SMOSLT to operate on, giving it a wide array of situations to test various options and hypothesis against.

 

Representative Project Types

The following project types are provided for by the generator:

  1. Business API
  2. Mobile App
  3. Content Delivery
  4. Batch Transform
  5. Big Data ETL & Analysis
  6. Desktop Data Tool
  7. Corporate BI Rollout
  8. Streaming Data Input Service
  9. ETL and Analysis
  10. something else

 

Each of these project types is outlined below in Project Type Details. Each of these is also based on a Master Project Template which provides common tasks that all projects might need such as a project requirements task.

 

The Easiest Way To Consume SMOSLT Runs?

SMOSLT can be time consuming and detailed to set up, and there is very little or no benefit for getting it perfect.

 

This low payback for perfection is easy to understand. SMOSLT is for evaluating a wide array of options at the crude and approximate level, not for microscopic decisions based on having to get it right before you start. Just as you wouldn’t use SMOSLT to design perfect NASA space launch software, neither would you try to perfect NASA space launch project design without first deciding exactly what database, network, and operating system options you were going to deploy the new software on.

 

Instead, you might wish to start with a surrogate schedule provided by SMOSLT generated projects. Start with the closest surrogate to your own project, then either use it instead, or use it as a starter for your own schedule.

 

SMOSLT Generated Project Schedules Are Still Not Complete Finished Schedules

A project schedule is never flushed out until AFTER the final SMOSLT options run. This can be confusing. To make it even more confusing, here is the sequence of project schedules as created in SMOSLT. All are designed to be automated as much as possible, since the main objective is not a real schedule, but to know how the options would play out in this schedule.

 

  • Master Template Schedule
  • [Project Type] Template Schedule
  • [Your] Project Schedule Before Options
  • [Your] Project Schedule After Selected Options

 

A project starts off by being copied and pasted from a Master Template, that gives you the basic structure and common elements.

 

This is then given tasks specific to a Project Type. You may now run this through the SMOSLT.stacker, but you probably want to take a couple more steps first…

 

If you copypaste this generic [Project Type] Template Schedule and customize it to be more representative of your own project, such as increasing or decreasing team size, number of repeat tasks, it is nos [Your] Project Schedule

 

Now, apply the options you wish to consider, and you have a meaningful data dump that may be representative of the kind of options available to you

Task Names as 4 Field Array

 

Generated projects start with a template created in ProjectLibre.

 

 

Project Type Details

Master Template

Master Template is an almost empty ProjectLibre schedule with 3 tasks borrowed quite artificially from Disciplined Agile Delivery. These tasks are not regarded as representative of most organizations, nor is this an endorsement of that approach. Something had to be used as a placeholder.

For more on the Disciplined Agile Delivery, see

 

 

 

Please add any tasks which are common to your organization’s

Business API

Business API Project

Exposes a wide array of business data to a common persistence store, exposing it as an external REST API

Mobile App Project

Allows customers to explore current special in-store sales for each store location, to encourage customer visits.

Content Delivery Project

Maintains server updates and pumps latest content releases to each of website, facebook, linked-in, twitter, and instagram.

Executive Dashboard Project

Integrates data from multiple sources into a data warehouse and builds an executive dashboard.

Big Data ETL & Analysis Project

Takes in a wide array of business data into an infinitely expandable persistence store, runs transforms as required, and performs analytics to maximize product pricing opportunities.

Desktop Data Tool Project

Manufacturing line management tool brings in information from production line sensors and databases to graphing and tabular reporting UI.

Corporate BI Rollout Project

Rollout of BI tool to mid level production managers for access to real time and historical production and sales data.

Streaming Data Input Service Project

Integration project bringing in both real time and historical production data, presenting as a single real time data set.

Batch Transform Project

Uses external computing resources to transform massive quantities of website and sales traffic data into usable structured files for other downstream data consumers.

SMOSLT code setup

SMOSLT is an application that is designed to only work from within an IDE, by someone who is modestly capable as a Java developer.

If you need more rationale on why this is the case, see this page.

How to set up a SMOSLT in Eclipse IDE

assumes an eclipse Luna IDE with current 1.7 JRE

 

put this in a shell script and run it:

git clone git@bitbucket.org:datafundamentals/smoslt.analytics.git

git clone git@bitbucket.org:datafundamentals/smoslt.app.git

git clone git@bitbucket.org:datafundamentals/smoslt.domain.git

git clone git@bitbucket.org:datafundamentals/smoslt.given.git

git clone git@bitbucket.org:datafundamentals/smoslt.main.git

git clone git@bitbucket.org:datafundamentals/smoslt.mprtxprt.git

git clone git@bitbucket.org:datafundamentals/smoslt.options.git

git clone git@bitbucket.org:datafundamentals/smoslt.optionsapi.git

git clone git@bitbucket.org:datafundamentals/smoslt.poms.git
git clone git@bitbucket.org:datafundamentals/smoslt.stacker.git

git clone git@bitbucket.org:datafundamentals/smoslt.util.git

git clone git@bitbucket.org:datafundamentals/smoslt.workspace_root.git

git clone git@bitbucket.org:betterology/org.btrg.uti.git

 

checklist

open up luna in [smoslt] workspace

import all projects

set up poms project as maven

run poms project in maven clean install skip tests

run org.btrg.uti in maven …

run workspace_root maven clean install skip tests

[all of the git connections say petecarapetyan in poms that is broken]

SMOSLT.given Module

The SMOSLT given module holds the information that is “given”, as used in the following sentence: “Given these assumptions and this ProjectLibre project file, the SMOSLT app runs the various options and stacks up a schedule of tasks”

 

Parts:

  • SideEffects (Options) – written in Java

 

How SideEffect Classes Are Written

  • Must be placed in the smoslt.given.sideeffect package
  • Must implement the SideEffect interface
  • Operates usually by having one of these effects
    • modify task duration
    • create a new task of a new duration
  • Typically filters task based on
    • Name of task starts with ….

 

see separate document on Saturation vs MoreIsBetter scoring options