You have probably heard the term embedded systems before or read about them somewhere. Embedded systems are pretty much everywhere including the microwave you use to cook your food; the digital indicators in the dash of your car; inside video gaming consoles, vending machines, aircraft navigation systems and inside the smart phone or tablet you may be using to read this article. Embedded systems are everywhere we go and in everything we do.

An embedded system is a computer system with a dedicated function that operates under Real Time Computing (RTC) constraints which impose specific response needs on the system. Not only are they subject to response constraints, but also often subject to memory, throughput and other technical limitations. Very specialized and intensive embedded systems are sometimes referred to as Mission Critical Embedded Systems (for example, medical laser control used in eye surgeries). An embedded system is typically implemented using a microcontroller or general purpose microprocessor, supported by the necessary electronic and mechanical hardware to perform the specific function. Embedded systems can range anywhere from a small heart rate monitor to a complex avionics system. Still, they share some common characteristics and differ from typical applications in the fact that the latter have been designed to meet more general purpose user needs.

Due to their popularity, estimating the effort and schedule and other measurements requiring size of embedded systems is a rapidly growing need. As a result, the function point community has a need for guidance and examples to help size this type of software. As with any other type of application, specific challenges are encountered along the way.

Embedded systems often deal with extensive calculations. A common concern towards acceptance of function point analysis in the embedded systems community is “function points will not take into account all my internal calculations because they do not cross the boundary.” Function point analysts need to really understand what those “internal” calculations are and what is triggering them. Where is the generated data or control information coming from or going to? What seems to be an internal process, likely has an action crossing the application boundary triggering it in a way that may not be obvious. It is always important to have a strong two-way communication between the subject matter expert and the function point analyst to provide a full understanding of the functionality of the embedded system. (If truly not crossing the boundary, sizing the internal functionality would likely be a good candidate to be counted under the Software Non-functional Assessment Process or SNAP.)

Login as a member to access this resource.

Non-Members: $20.00, purchase the publication here: https://ifpug.memberclicks.net/fpaelementary