Kun analyysisovelluksen ensimmäisiä versioita toteutettiin, halutunlaisia analyysiin soveltuvia kaupallisia ohjelmistoja ei juuri ollut. Nykyisin tilanne saattaa olla toinen. Toisaalta yleiskäyttöisten ohjelmistojen ongelma on usein se, että niillä rutiinianalyysin tekeminen voi olla kohtuuttoman hankalaa. Esimerkiksi amplitudi/nousuaika -analyysiä varten voidaan yhden päivän kokeessa rekisteröidä satoja vasteita. Vasteille halutaan mahdollisimman vaivattomasti tehdä signaalin ryöminnän poisto ja maksimipoikkeaman ja nousuajan määritys. Tämän tyyliset toiminnot saattaisivat löytyä yleiskäyttöisestä analyysiohjelmistosta, mutta toimintojen suorittaminen satoja kertoja peräkkäin voisi viedä aivan liian paljon aikaa. Kaupallisten ohjelmistojen käyttöön tulisi kuitenkin pyrkiä mahdollisuuksien mukaan. Tätä varten analyysiohjelmiston liitynnät datan saattamiseksi jatkoanalyysille sopivaan muotoon ovat erityisen tärkeitä.
Nykyisen analyysisovelluksen käyttöliittymä ei ole täysin tyypillisen Windows-ohjelmiston käyttöliittymän kaltainen. Tämä johtuu osittain siitä, että käyttöliittymä on laadittu Turbo Pascalin ensimmäisellä Windows-versiolla, joka ei tukenut voimakkaasti käyttöliittymän standardimuotoisuutta kuten useat nykyiset Windows-työkalut (esim. Microsoft Developer Studio). Nykyisillä työkaluilla sovelluksen käyttöliittymän toteuttaminen kävisi huomattavan nopeasti ja esim. tulostusominaisuuksia voitaisiin merkittävästi parantaa. Voidaan myös sanoa, että Pascal on huono valinta toteutuskieleksi. Borland Pascalin OO-laajennuksia voidaan perustellusti pitää vajaina (esim. konstruktoreja ja destruktoreja tulee kutsua eksplisiittisesti). C++ olisi tällä hetkellä huomattavasti parempi valinta jo kielen laajan käytön ja sen seurauksena syntyneiden ohjelmoinnin aputyökalujen, kaupallisten ja vapaasti levitettävien kirjastojen sekä runsaan kääntäjävalikoiman vuoksi. C tai C++ ei myöskään sitoisi toteutusta yhtä tiukasti Windows-ympäristöön kuin Borland Pascal.
Kuten analyysiohjelmiston oliomallista nähdään, ohjelmiston tulisi kyetä esittämään useanlaisia näkymiä mittaus- ja analyysidatasta. Jos ohjelmistoa nykyisestään merkittävästi laajennetaan, tulisikin harkita ohjelmiston pilkkomista useaksi sovellukseksi ja Windows-ympäristössä esim. OLE-kommunikaatiota prosessien välille. Tällöin esimerkiksi histogrammisovitus ja Fourier-suodatus voitaisiin toteuttaa erillisinä OLE-automaatioservereinä.
Usein toistuvien rutiinitöiden hankaluus on yleinen ongelma monoliittisille sovelluksille, joiden ainoa käyttörajapinta on interaktiivinen (graafinen) käyttöliittymä. Edellä esitetty sovelluksen pilkkominen voisi auttaa myös tähän ongelmaan. Tällöin makrotoimintoja voitaisiin koodata nopeasti esim. Visual Basicin tyylisellä työkalulla yhdistelemällä eri OLE-automaatioservereiden tarjoamia palveluja.
Analyysisovelluksessa on tälläkin hetkellä joitakin tunnettuja vikoja. Tämä on tyypillinen seuraus ohjelmistonkehityksestä, jossa määrittelyyn ja osakokonaisuuksien testaukseen ei kiinnitetä tarpeeksi huomiota. Tässä diplomityössä esitettyjen analyysiohjelmiston vaatimusmäärittelyn ja oliomallin tarkoitus on toimia ohjelmiston määrittelydokumentteina, joiden pohjalta nykyisen toteutuksen selkeyttämisen ja testattavuuden parantamisen tulisi olla mahdollista.