Applications, OEM Software, and How Software Gets Built
Understand the basic principles of application development, and the real differences between an app, OEM software, and a web application.
By the end of this lesson you can
- Describe the stages of the software development lifecycle
- Distinguish native apps, web apps, and OEM software
- Explain why software requires updates throughout its life
- Evaluate an application before recommending it for workplace use
Lesson Notes
Read through the key concepts before you try the challenge.
What 'an app' actually is
You are asked to evaluate software at Lakeside Medical Associates.
A vendor demonstrates a scheduling app. It looks excellent. Before the practice commits, someone needs to ask where the data is stored, who supports it, what happens when the vendor is acquired, and whether it will still work after the next operating system update. Nobody at the practice currently asks those questions.
Your task: Understand how software is built and maintained well enough to evaluate it responsibly.
An application is a program written to do a specific job for a user, as distinct from system software, which runs the machine itself. The word 'app' usually implies something smaller and installed from a store, but the distinction is one of convention rather than kind.
| Type | Runs | Trade-off |
|---|---|---|
| Native app | Installed on the device, written for its operating system | Fast, works offline, full device access — but must be built per platform and updated on each |
| Web app | In a browser, on a remote server | Any device, always current, nothing to install — but needs a connection |
| OEM software | Shipped with hardware by its manufacturer | Guaranteed to work with that hardware; often cannot be removed and may be neglected after release |
| Enterprise software | On organizational servers or a vendor's cloud | Built for scale and compliance; expensive and slow to change |
OEM stands for original equipment manufacturer. OEM software is what arrives on a device from whoever made it — the printer utility, the manufacturer's support tool, the preloaded trial suites. It is written for that specific hardware, which is its advantage, and it is frequently abandoned once the hardware generation is superseded, which is its risk.
How software is made, and why it is never finished
| Stage | What happens |
|---|---|
| Requirements | Establish what the software must do, and for whom |
| Design | Decide how it will be structured and how it will look |
| Development | Write the code |
| Testing | Verify it does what was specified and fails safely when it does not |
| Deployment | Release it to the people who will use it |
| Maintenance | Fix defects, patch security holes, adapt to platform changes |
Maintenance is where most of a program's life is spent, and it is the stage people forget when evaluating software. Operating systems change, security vulnerabilities are discovered, and regulations shift. Software that is not actively maintained does not stay still — it decays, because the world around it moves.
A practice is choosing between a native app installed on each workstation and a web app used in a browser. Staff need to work during brief internet outages. Which factor matters most?
Challenge
Apply what you've learned in this lesson.
Evaluate real software the way a practice should.
- List five applications you use regularly and classify each as native, web, OEM, or enterprise.
- Choose one and research: who maintains it, how often it is updated, and where it stores your data. Note anything you could not find out — that gap is itself a finding.
- Write five questions you would put to a vendor before your practice adopted software handling patient information.
- Find one piece of OEM software on a computer you use. Determine whether it is still supported, and write two sentences on the risk if it is not.
Finished this lesson?
Progress is saved in this browser only. It is not a grade — official progress lives in Brightspace.