Archive for the ‘Software Development’ category

2014 Distance C# Development Classes

January 1, 2014

Once again Lonestar College will be offering distance-only C# development classes in the Spring of 2014.

Classes to be taught this semester are:

Introduction to C# (COSC1420) The course will instruct the student to basic programming constructs using C# and Microsoft Visual Studio 2012 / 2013. The student will learn the basics of the C# language and develop a basic Windows application. Language, Class, and Object fundamentals will be taught. A brief introduction to database interfaces may be included.

Advanced C# (ITSE 1492) The course will instruct the student to advanced programming constructs using C# and Microsoft Visual Studio 2012 / 2013. Successful course completion will require the development of a deployed Windows application (including the creation of a setup file). Other topics include multi-threading, user-controls, reflection, SQL and ADO (introductory), event handling, and Office 2007 Look and Feel.

Web Applications (ITSE 2472) The course will instruct the student in the development of a simple Web Application using an array of web application tools: HTML, CSS, JavaScript, C#, and SQL. Successful course completion will require the development of an Internet (Browser-based) application including rudimentary SQL interfaces.

Contact me at Mark.E.Reynolds@Lonestar.edu for additional information. Or visit my college blog at http://lonestar.edu/blogs/markreynolds.

(If you have not had all of the prerequisites for a course, contact me and we will discuss your options. Or you may contact counselor Erma Walker at Erma.M.Walker@Lonestar.edu.)

Advertisements

Agile and The Grand Parkway (around Houston)

September 20, 2013

While attending a meeting about the Grand Parkway (http://www.grandpky.com/home/) a comment was made about how the overall design of the parkway was set but the details were being worked so that construction could begin without the detailed design set in stone.

What a cool way to demonstrate the concept of agile software development!

As we all know, the Kanban approach to Agile Development has its roots in the 1940s at the Toyota plant. In effect, Toyota implemented Just-In-Time principals to improve efficiencies, reduce down time, and reduce inventory storage space. Kanban has been applied to the software development process with elegant Kanban Boards – both physically and virtually. However, non-developers do not understand the concept so I’ll try, today and in the future, to provide non-software examples to the Kanban approach.

Business Driven Software Development

February 12, 2012

A repost of my son’s blog – July 2009
http://blog.intentdriven.com/2009/07/characteristics-of-quality-software.html

As a software engineer, project proposals are available in spades. Learning how to evaluate business needs and technical needs is a basic job prerequisite (Parkinson, 2000). Parkinson explains that there is a significant difference between a technical requirement and a business requirement. An example of a technical requirement would be needing a new printer. A similar business process requirement would be needing a more efficient printing algorithm that cuts down the time spent spooling a project to the printers.Business drivers can be broken down into “chunks”. For instance, an “Expense Reduction” driver may be broken into Customer Service expenses, customer acquisition\retention, efficiency, and other expenses (Machavarapu, 2006). Once the drivers are broken down, Machavarapu recommends assigning weights to the “chunks”, such that new projects can be evaluated for priority.

Finally, there is an array of reasons for beginning an IT project which should serve as red flags for engineers and developers. Reasons such as “Wanting to stay abreast of the latest technology advances” frequently translate into “Spend money on shiny new buttons”. Unfortunately, if this desire to advance technology isn’t tempered by legitimate business needs, the project may fail, or worse, prevent legitimate projects from receiving adequate funding.

References
Bernard, A. (December 26, 2003). Why Implementations Fail: The Human Factor.

Boehm, B. W. Quantitative Evaluation of Software Quality. In R. W. Selby, Ed. Software Engineering (p. 27). IEEE. Retrieved July 11, 2009, from
http://books.google.com/books?hl=en&lr =lang_en&id=ttaMIFv8bv8C&oi=fnd&pg=PA5&
dq=characteristics+of+quality+software& ots=yWkqT2mRFl&sig=Mj9mpFfLpWk4BkLvp4cz
M8ZhGU4
Google Books.

Machavarapu, S. (2006). Prioritizing IT Projects Based on Business Strategy – CIO.com. Retrieved July 15, 2009, from http://www.cio.com/article/22976/Prioritizing_IT_Projects_Based_on_Business_S trategy/1

Parkinson, D. (2000). Recognizing business needs can lead to new and repeat clients. Retrieved
July 15, 2009, from http://articles.techrepublic.com.com/5 100-10878_11-5027153.html

Pfleeger, S. L. & Atlee, J. M. (2006). Why Software Engineering. Software Engineering Theory and Practice (3rd ed. pp. 9-11). Upper Saddle River, NJ: Pearson Prentice Hall.

Characteristics of quality software

February 12, 2012

A repost of my son’s blog – July 2009
http://blog.intentdriven.com/2009/07/characteristics-of-quality-software.html

Software Quality

Software Quality is a concept has been discussed and defined in a number of excellent books and articles. Granular-Level specific characteristics are numerous, and the weight placed on one aspect may differ from company to company, or even from project to project. However, with the assistance of the Pfleeger and Atlee text (2006) and a text from Selby and Boehm (2009), we can examine several generic properties which are relatively universal.

  • Portability
    This is a measure of how the degree of coupling with other software or hardware. Can the software be easily installed and transferred, or is there a complicated integration with 3rd-parties (eg. SQL Server, or a special hardware key-dongle)?
  • “AS-IS” utility
    Does the software require heavy customization once it is deployed to the customer?
    (ie. Reliability, Efficiency, Human Engineering)
  • Maintainability
    In 2 years, will we be able to fix a problem or add new functionality?
    (ie. Testability, Understandability, Modifiability)

Human Factors

Bernard suggests that the most basic reason for an implementation to fail is due to inadequate training and preparation of the operators of the system. Having been involved in several different implementations of new software, I have seen both well-prepared and inadequately-prepared staff try to deal with new software. I would venture to say that Bernard is exactly right in saying that improper training is a huge reason why software does not succeed. It is my experience that users with a stake in the company don’t WANT to see software fail, but they will unintentionally sabotage the new initiative with “Well we always did it the other way” attitudes, if they don’t have a good reason to make the change.

References

Bernard, A. (December 26, 2003). Why Implementations Fail: The Human Factor.

Boehm, B. W. Quantitative Evaluation of Software Quality. In R. W. Selby, Ed. Software Engineering (p. 27). IEEE. Retrieved July 11, 2009, from Google Books.

Pfleeger, S. L. & Atlee, J. M. (2006). Why Software Engineering. Software Engineering Theory and Practice (3rd ed. pp. 9-11). Upper Saddle River, NJ: Pearson Prentice Hall.

Penny Rounding Problem

February 10, 2012

A computer rounding problem that I like to call “The Penny Rounding Problem” has been around for many, many years. At least two movies have been made with this problem a core element: The Office, and Superman III. The basic problem is that a column of numbers should add up to the total at the bottom. But they do not.

Mark Reynolds is currently at Southwestern Energy where he works in the Fayetteville Shale Drilling group as a Staff Drilling Data Analyst. In this position, he pulls his experiences in data processing, data analysis, and data presentation to improve Southwestern Energy’s work in the natural gas production and mid-stream market.

Recently, Mark has been working toward improved data collection, retention, and utilization in the real-time drilling environment.

www.ProfReynolds.com

For example: 1/3 is represented as .33, or even .333. But if you add .33 together 3 times, you get .99, not 1.00 – a penny off. This is why your final mortgage payment (if you ever actually paid it off) is never exactly the same as the monthly amount. Even worse, take 2/3 or .67. Multiple .66666… by 3 and you get 2.00; multiply .67 by 3 and you get 2.01.

Solving the problem is relatively simple, but requires diligence. Individual calculations must be individually rounded to the correct number of decimal places.

When I teach Excel at the college, I require the student to explicitly ROUND the answer to any mathematical operation involving

  1. possible sub-penny answers (divide by three, multiply by .0475, etc.)
  2. currency
  3. down-stream use of the answer.

Taken individually — addition of two numbers will never generate sub-penny digits, non-currency measurements (weight, speed, etc) do not bother people when the totals are off by small decimal fractions, and if the result to the mathematical calculation is never to be used then no one cares.

So when an interest equation is entered into Excel
= A3 * A4 / 12,
you should change it to be
= ROUND( A3 * A4 / 12, 2 ) so that the answer is rounded to 2 decimal places.

So can Richard Pryor get rich by taking all of the rounded, fractional pennies and putting them in his account? This is called Salami Slicing and snopes calls it a legend. But do gas stations do it with your pump price? read here for the answer

Artificial Intelligence vs Algorithms

February 9, 2012

I first considered aspects of artificial intelligence (AI) in the 1980s while working for General Dynamics as an Avionics Systems Engineer on the F-16. Over the following 3 decades, I continued to follow the concept until I made a realization – AI is just an algorithm. Certainly the goals of AI will one day be reached, but the manifestation metric of AI is not well defined.

Mark Reynolds is currently at Southwestern Energy where he works in the Fayetteville Shale Drilling group as a Staff Drilling Data Analyst. In this position, he pulls his experiences in data processing, data analysis, and data presentation to improve Southwestern Energy’s work in the natural gas production and mid-stream market.

Recently, Mark has been working toward improved data collection, retention, and utilization in the real-time drilling environment.

www.ProfReynolds.com

Consider the Denver International Airport. The baggage handling system was state of the art, touted as AI based and caused the delay of the opening by 16 months and cost $560M to fix. (more – click here) In the end, the entire system was replaced with a more stable system based not on a learning or deductive system, but upon much more basic routing and planning algorithms which may be deterministically designed and tested.

Consider the Houston traffic light system. Mayors have been elected on the promise to apply state of the art computer intelligence. Interconnected traffic lights, traffic prediction, automatic traffic redirection. Yet the AI desired results in identifiable computer algorithms with definitive behavior and expectations. Certainly an improvement, but not a thinking machine. The closest thing to automation is the remote triggering features used by the commuter rail and emergency vehicles.

So algorithms form the basis for computer advancement. And these algorithms may be applied with human interaction to learn the new lessons so necessary to achieving behavioral improvement with the computers. Toward this objective, distinct fields of study are untangling interrelated elements – clustering, neural networks, case based reasoning, and predictive analytics are just a few.

When AI can be achieved, it will be revolutionary. But until that time, deterministic algorithms, data mining, and predictive analytics will be at the core of qualitative and quantitative advancement.

Making new IT work for the business

September 23, 2011

I found an EXCELLENT article in the Digital Energy Journal by Dutch Holland. In this article he explore different strategies for transforming operational requirements into successful initiatives.

Without stealing too much of his well articulated article, the five approaches normally used are:

  • The by-the-book business analyst
  • The business-experienced analyst”
  • The businessman CIO
  • The IT expert Inside the business
  • The operations-led interface

I encourage anyone attempting to implement a operations-centric technological solution to read his article.

http://www.findingpetroleum.com/n/Making_new_IT_work_for_the_business/d1a1861b.aspx

“When trying to connect technology innovation with business, an intelligent interface between the two is required. It must be able to translate business opportunity into technical requirements; innovate, test and evaluate; and seamlessly implement new technology into the business.” ~Dutch Holland


%d bloggers like this: