- We have to avoid making a new legacy software.
- We have to make collaborative software.
- We have to make responsive software.
- We have to make adaptive layout.
And now... We have to make a software with prognostic feature!
What is a prognostic feature ?
"Prognostic feature is the capability to analyze, discover and advise about a problem before it happen."
We have to learn lessons by automotive industry.
In car dashboard there are a lot of indicators. Most of them tell us information about something that we have to do before a problem occurs. For example an indicator appear before gasoline ends, an indicator appear before oil ends, and indicator appear before windshield wiper water ends. If something going wrong in car engine but car can go, an indicator appear to tell us that we have to drive to auto mechanic as soon as possible. If car revision's day is coming an indicator tell us that we have to go to the auto mechanic when we can.
Prognostic feature already exist in our car.
But now return to the software's world.
Today "unit tests" are part of modern development process, so you can think that I'm talking about them, but not, prognostic feature isn't the same think.
Unit tests are part of development process, on the other hand prognostic feature work when software is up and running in production.
Prognostic feature and unit test could seem similar but they aren't.
They cover different aspects and situations.
An example:
Unit tests cover "Domain Model" behavior and "Business Logic" expectation.
Unit tests run in development environment or continuous integration environment.
Prognostic feature verify if database services is running, if database bakup run correctly, if there is a problem try to solve them (for example trying to start database service service), send an alert to appropriate people and trace\log these information.
Prognostic feature run in production environment.
Prognostic feature is very useful when can recognize problem before it happen.
How is it possible ?
Prognostic feature must run in two different way:
Think about scenario of web site that has a "contact form".
Contact form use an email address to send you an email and another email address for the recipient.
Typically, if there is an error in contact form, a message will be display to the end user and perhaps will be wrote to the log file.
In this scenario you don't know about the problem until you look at the log\trace file (if tracing is active) and you will not receive contact messages.
In this scenario prognostic feature has to work in background and periodically send a specified email using the same sender email address of the contact form.
If an error occur sending email, prognostic feature must give warning to the system manager.
This scenario show that prognostic feature need another place where it must run.
Prognostic feature need a prognostic counterpart that could be another web site, service or mobile device application.
In the "contact form" scenario "prognostic feature counterpart" periodically check for "prognostic feature" email message, if the message does not arrive within a period of time, prognostic counterpart must give warning to the system manager.
For now we have seen three place where "prognostic feature" work.
We have to learn lessons by automotive industry.
In car dashboard there are a lot of indicators. Most of them tell us information about something that we have to do before a problem occurs. For example an indicator appear before gasoline ends, an indicator appear before oil ends, and indicator appear before windshield wiper water ends. If something going wrong in car engine but car can go, an indicator appear to tell us that we have to drive to auto mechanic as soon as possible. If car revision's day is coming an indicator tell us that we have to go to the auto mechanic when we can.
Prognostic feature already exist in our car.
But now return to the software's world.
Today "unit tests" are part of modern development process, so you can think that I'm talking about them, but not, prognostic feature isn't the same think.
Unit tests are part of development process, on the other hand prognostic feature work when software is up and running in production.
Prognostic feature and unit test could seem similar but they aren't.
They cover different aspects and situations.
An example:
Unit tests cover "Domain Model" behavior and "Business Logic" expectation.
Unit tests run in development environment or continuous integration environment.
Prognostic feature verify if database services is running, if database bakup run correctly, if there is a problem try to solve them (for example trying to start database service service), send an alert to appropriate people and trace\log these information.
Prognostic feature run in production environment.
Prognostic feature is very useful when can recognize problem before it happen.
How is it possible ?
Prognostic feature must run in two different way:
- First run inside your executable code, such as retry to open a connection more then one time if first open filed, try to resume valid connection state if connection state change.
- Second run periodically in background.
Think about scenario of web site that has a "contact form".
Contact form use an email address to send you an email and another email address for the recipient.
Typically, if there is an error in contact form, a message will be display to the end user and perhaps will be wrote to the log file.
In this scenario you don't know about the problem until you look at the log\trace file (if tracing is active) and you will not receive contact messages.
In this scenario prognostic feature has to work in background and periodically send a specified email using the same sender email address of the contact form.
If an error occur sending email, prognostic feature must give warning to the system manager.
This scenario show that prognostic feature need another place where it must run.
Prognostic feature need a prognostic counterpart that could be another web site, service or mobile device application.
In the "contact form" scenario "prognostic feature counterpart" periodically check for "prognostic feature" email message, if the message does not arrive within a period of time, prognostic counterpart must give warning to the system manager.
Where
For now we have seen three place where "prognostic feature" work.
- Inside
- Parallel
- Outer
Inside means that "prognostic feature" need to be injected into your code (as the example of connection management).
Parallel means that "prognostic feature" need to run in background or in separate service to do different check of your system (as the example of sending email by contact form).
Outer means that "prognostic feature" need a counterpart out of your main process that receive status message of your system (as the example of receiving email by contact form), if doesn't receive status messages means that there is a problem to notify.
What
After the place "where" prognostic feature work, now let's talk about "what" prognostic feature can look for.
Your software application or web site can have many feature and end-user doesn't use all of them immediately, at the same time or doesn't use at all. If we know which one will go in error we can early advise system manager and early disable that feature.
Here there are some example of what your "prognostic feature" can observe:
Database
File system
WebServices
After availability we can check status of a service, or device.
For example we can use DataBase Object model to query database status, we can use Database connection objects to know current connection state, we can use some API to know if file is opened or in use.
Use
We can use DataBase Connection object to try a connection to database.
We can use a webservice and check the response.
We can use SMTP service to send an email.
We can access into our application using a test account
Performance Monitor
This is the most complicated way but perhaps the most prophetic.
We have two way:
Using above table we can assign "how" to any "what".
For example we can use the "what" test of "File System" as the table below.
For example now we know that "access to path" chek is an Availability check.
By the first table above we know that Availability check place can is Outer (or parallel).
In this way we can complete the table for every check.
In the same way we can know the best place for any "prognostic feature".
Below the tables for Database, Web Service, Network, External Service, Printer and Device "prognostic feature".
Database Example
Database
- Check if database service is available.
- Check if is possible to connect to it.
- Check if there is sufficient disk space.
- Check if backup are running.
- Monitor the increase size of database and backup size
- Monitor time variation to establish a connection
- Monitor time variation to execute most used query
File system
- Check if your software can access to needed path, directory or files.
- Check if there is enough disk space.
- Monitor time variation accessing to file system.
WebServices
- If your software use some external webservice check if webservice is available.
- Check if signature or version are changed (not every people respect WS rules).
- Check result of one specified call to the webservice.
Network
- If your software access to the network check if network is available (prefer with the same user of your process)
- Check if your software can access to the network.
- Check time variation accessing to the network.
External Service (like SMTP server of the contact form example)
- Check if your software can use email service
- Check if email server really send email
- Check time variation receiving email
Printer
- Check if the printer is available.
- Check printer status.
- I think that printing test page is not a good idea.
Devices
If your software is connected to a device (such: bar-code reader, speakers) check:
- Availability
- Status
How
Next to "what" now let's talk about "how" prognostic feature can work.
The main ways to check the system are:
- Availability
- Status
- Use
- Performance Monitor
Availability
Availability check can be done:
- Checking if a service is running.
- Checking if network is available.
- "Pinging" webservice address.
- Checking if device is turned on.
- Checking if needed file exists.
Status
For example we can use DataBase Object model to query database status, we can use Database connection objects to know current connection state, we can use some API to know if file is opened or in use.
Use
We can use DataBase Connection object to try a connection to database.
We can use a webservice and check the response.
We can use SMTP service to send an email.
We can access into our application using a test account
Performance Monitor
This is the most complicated way but perhaps the most prophetic.
We have two way:
- We have to record the time spent by latest specific operations and if time spent by the last operation is too different from the others "prognostic feature" must tell to us.
- We have to set a maximum time that an operation can spend. If the last operation spent more than the maximum value "prognostic feature" must tell to us.
All Together
Table below link "how" with "where".
In this table:
"YES" is the best place (my personal opinion) where the "check type" can be.
"YES" is the place where the "check type" could be.
You can combine this table as you like.
In this table:
"YES" is the best place (my personal opinion) where the "check type" can be.
"YES" is the place where the "check type" could be.
You can combine this table as you like.
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
Using above table we can assign "how" to any "what".
For example we can use the "what" test of "File System" as the table below.
File System Example
We assign an "how" to the "prognostic feature check".
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Access to path | X | |||
| Disk space | X | |||
| Time accessing file | X |
For example now we know that "access to path" chek is an Availability check.
By the first table above we know that Availability check place can is Outer (or parallel).
In this way we can complete the table for every check.
What\Where
|
Inside
|
Parallel
|
Outer
|
|---|---|---|---|
Access to path
|
YES
|
YES
| |
Disk space
|
YES
|
YES
| |
Time accessing file
|
YES
|
YES
|
Below the tables for Database, Web Service, Network, External Service, Printer and Device "prognostic feature".
Database Example
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Service is available | X | |||
| Connect | X | X | ||
| Allocated Disk Space | X | |||
| Backup ok | X | |||
| Time to connect | X | |||
| Time for query | X |
| What\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Service is available | YES | YES | |
| Connect | YES | YES | YES |
| Allocated Disk Space | YES | YES | |
| Backup ok | YES | ||
| Time to connect | YES | YES | |
| Time for query | YES | YES |
WebService Example
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Webservice is available | X | |||
| Signature or version | X | |||
| Result of call | X |
What\Where
|
Inside
|
Parallel
|
Outer
|
|---|---|---|---|
Webservice is available
|
YES
|
YES
| |
Signature or version
|
YES
|
YES
|
YES
|
Result of call
|
YES
|
YES
|
YES
|
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Access to newtwork | X | |||
| Time accessing network | X |
What\Where
|
Inside
|
Parallel
|
Outer
|
|---|---|---|---|
Access to newtwork
|
YES
|
YES
| |
Time accessing network
|
YES
|
YES
|
External email service Example
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Can use email service | X | |||
| Server really send email | X | |||
| Time receiving email | X |
What\Where
|
Inside
|
Parallel
|
Outer
|
|---|---|---|---|
Can use email service
|
YES
|
YES
| |
Server really send email
|
YES
|
YES
| |
Time receiving email
|
YES
|
YES
|
| How\Where | Inside | Parallel | Outer |
|---|---|---|---|
| Availability | YES | YES | |
| Status | YES | YES | YES |
| Use | YES | YES | YES |
| Performance Monitor | YES | YES |
| What\How | Availability | Status | Use | Performance Monitor |
|---|---|---|---|---|
| Printer is available | X | |||
| Printer status | X |
What\Where
|
Inside
|
Parallel
|
Outer
|
|---|---|---|---|
Printer is available
|
YES
|
YES
| |
Printer status
|
YES
|
YES
|
YES
|
That's all
Your comments will be appreciated and if you have some check not included in above tables tell me so I can update or fix this document.
No comments:
Post a Comment